Software Supply Chain Security Turns to Risk Mitigation

iStock photo

2021 was a wild year for cybersecurity, memorable for a slew of data breaches, including cloud provider outages, ransomware attacks and software supply chain compromises.

The software supply chain has become a notable concern due to the explosive growth of open source software use and the cascading impact of software supply chain incidents, whether from open source software or vendor proprietary software.

The SolarWinds compromise and the Log4j panic, two high-profile software supply chain incidents, garnered the most headlines as organizations associated with these attacks scrambled to address their impact.

The attacks on the software supply chain keep coming. In its “2021 State of the Software Supply Chain” report, security provider Sonatype recorded 12,000 incidents this past year, a 650 percent increase over the previous year. Despite this surge, supply chain compromises are not new: the Cloud Native Computing Foundation has documented a repository of notable supply chain attacks dating back to 2003.

Supply chain attacks are not limited to the private sector. They also affect the public sector and federal agencies, including the Defense Department and its industry partners, who are some of the biggest consumers of proprietary and open source software.

Countless organizations — including in the federal community — continue to adopt open source software for its myriad benefits, such as expediting timelines, providing readily available code, improving functionality and offering transparency.

Sonatype in the report noted 73 percent year-over-year growth in development downloads of open source components. Unfortunately, open source developers may not be dedicating enough time to securing their code. According to the Linux Foundation’s “Report on the 2020 FOSS Contributor Survey,” the average amount of time an open source developer spends on securing code is less than 3 percent.

The benefits of open source software adoption come with risks. Nowhere is this more apparent than with the Log4j security incident, which included the identification of a vulnerability in Log4j, an open source Apache logging framework. The incident left thousands of organizations worldwide, including many federal agencies in the United States, scrambling to determine if they were directly using the vulnerable version of Log4j and whether the vendor software they consume was also impacted. The latter fear was accompanied by a barrage of vendor advisories and bulletins.

The SolarWinds cyberattack highlighted the potential for malicious actors to compromise a vendor’s build environment and insert malicious software that could then be distributed broadly across the ecosystem.

In late 2020, as the fallout from the SolarWinds cyberattack escalated, the Cybersecurity and Infrastructure Security Agency released a set of emergency directives documenting mitigations that federal agencies should take to avoid the exploitation of their systems using SolarWinds.

Building on this incident and others, the cybersecurity executive order highlighted the need for guidance around validating vendors’ secure software development environments and practices, as well as instruction for monitoring and reporting cybersecurity incidents.

The Cybersecurity and Infrastructure Security Agency also created a dedicated page in its emergency directives for Log4j vulnerability guidance. CISA’s guidance applied to both vendors using the component in their software and affected organizations using it internally or through vendor software consumption.

This event also highlighted an alarming reality: most organizations lack effective methods to identify the software and associated components they are using.

Palo Alto’s Cloud Threat Research Group also released research highlighting software supply chain concerns, noting that supply chain flaws are difficult to detect and that third-party costs pose hidden risk. It pointed out several relevant software supply chain attacks. Its report laid out how attackers are poisoning continuous integration pipelines and causing cascading impacts on downstream software consumers.

It also highlighted concerns associated with infrastructure-as-code and container templates, which are increasingly being used by organizations in support of pushes for cloud adoption and digital transformation initiatives.

The software supply chain, from both proprietary and open source perspectives, is fragile and warrants more security rigor, yet most organizations aren’t quite sure where to begin.

Thankfully, public and private organizations are releasing guidelines and best practices that companies can leverage to improve their software supply chain security hygiene and mitigate risk to their organizations and customers.

The National Institute of Standards and Technology, for example, released Cybersecurity Supply Chain Risk Management Practices, or 800-161, a framework to evaluate supply chain security. It was updated in October in draft form and is now undergoing comment reviews.

Appendix F of this document responds specifically to the cybersecurity executive order and strives to provide guidelines for enhancing software supply chain security.

NIST recommends that federal agencies — and the private sector, as well — incorporate C-SCRM practices into key activities such as enterprise-wide risk management and acquisition. NIST also defines “critical software” and provides associated security measures. The document offers guidelines for software verification to help developers supply secure products and services to organizations within the federal government.

These recommendations address critical activities such as threat modeling, static and dynamic application scanning, and the identification of hard-coded secrets, all of which can locate vulnerabilities and risks that may impact software consumers.

Generally, the NIST guidelines recommend that federal agencies ensure these practices be performed by their software suppliers. That will include baking these requirements into acquisition language in the future.

The 800-161 recommendations also carry language associated with emerging software supply chain concepts, notably the often talked about concept of a “software bill of materials,” which acts as a method of increased transparency and provenance to help organizations identify what software they are consuming, where it exists and, potentially, the vulnerabilities associated with it. These recommendations have been championed by the National Telecommunications and Information Administration and CISA, each releasing best practices. Think back to the Log4j vulnerability. A poor software asset inventory meant many organizations were left scrambling to even identify if they were impacted.

Shifting attention to open source software, 800-161 includes sections dedicated to open source software controls, with an eye on varying levels of maturity such as “foundational, sustaining and enhancing.” These cover a range of issues, from controls such as software composition analysis to binary software composition analysis to setting up a centralized repository of open source components that have been catalogued and approved for organizational use.

On the industry side, Cloud Native Computing Foundation’s white paper, “Best Practices for Supply Chain Security,” outlines four principles for supply chain security: trust, automation, clarity and mutual authentication. Each of these categories is critical at every step of the supply chain ecosystem to ensure a resilient software supply chain and mitigate many of the incidents we’ve seen.

What makes the guidance unique is the distinctions it makes among assurance requirements. It notes that not all software and enterprises share the same security requirements and risk tolerances, and it identifies low-, moderate- and high-assurance products/environments. Like the NIST guidance, the white paper recognizes that best practices carry different decisions and activities depending on whether the users are software producers or consumers.

These practices help producers ensure they provide a product that matches their customers’ requirements. And they help software consumers ensure vendors are offering them software aligned with their risk tolerance. While the Cloud Native Computing Foundation guidance provides specific actions at various stages of the software supply chain, it carries some overlap with NIST guidance, such as requiring a software bill of material from third-party suppliers, utilizing trusted repositories, and performing security control assessment on ingested software.

So, what’s next?

Software supply chain concerns are here to stay. Organizations are realizing just how brittle their software supply chain security practices are; and malicious actors take advantage of this reality.

The federal government and defense community have made clear statements highlighting how critical software is to national security and international competitiveness.

Software brings innovations and promise, but it comes with an exorbitant amount of relevant peril, particularly when fundamental security practices and processes are not implemented throughout the software supply chain.

This is a reality for both software producers and consumers across all industries and verticals. The implementation of secure software supply chain practices across the industry is no easy feat. However, the new guidance from NIST, the Cloud Native Computing Foundation and other security watchers is a great step toward what should be a strategic imperative for our national security and for a well-functioning society in today’s digital world.

Chris Hughes is an adjunct professor in the School of Cybersecurity and Information Technology at the University of Maryland Global Campus.

Topics: Cybersecurity