Supply chain security continues to receive critical focus in the realm of cybersecurity, and with good reason: incidents such as SolarWinds, Log4j, Microsoft, and Okta software supply chain attacks continue to impact both leading proprietary software vendors as well as widely used open-source software components.
The concern is global. Regulations and requirements are evolving around the world as governments look to mitigate risks from software supply chain attacks, and topics such as secure-by-design, secure software development, software liability and self-attestations, and third-party certifications are dominating the dialogue.
Software suppliers will increasingly need to be familiar with the requirements as the landscape evolves. With attackers looking to exploit widely used software suppliers, these requirements are intended to help mitigate the risk to governments and nations around the world from software supply chain attacks.
From nations producing domestic secure software requirements to global efforts aimed at blunting the dangers of representing an international focus, below are some of the most notable initiatives and programs aimed at protecting the software supply chain.
United States
The Cyber Executive Order
Much of the US software supply chain security guidance and requirements can be traced back to Executive Order (EO) 14028 “Executive Order on Improving the Nation’s Cybersecurity“. While the EO itself didn’t create many of the associated requirements it set the guidelines behind most of them. Section 4 in particular focuses on “enhancing software supply chain security” and lays out requirements for the National Institute of Standards and Technology (NIST), the Office of Management and Budget (OMB), the Cybersecurity and Infrastructure Security Agency (CISA) and others.
OMB 22-18 and 23-16
Per the Cyber EO, the Office of Management and Budget (OMB) issued two memos, 22-18 and 23-16 each of which focuses on software supply chain security and begins pushing for requirements such as for all software suppliers selling to the US Federal government to start to self-attest to following secure software development practices, such as NIST’s Secure Software Development Framework (SSDF). It also calls for the use of SBOMs in some cases and even the use of a third-party assessment organization if an agency warrants the risk is significant enough.
FDA Ensuring Cybersecurity of Medical Devices/Section 524B
One notable area getting a specific focus in the US is medical devices. The latest effort came in the emerging requirement from the US Food and Drug Administration (FDA) in Section 524B of the Federal Food, Drug and Cosmetic Act (FD&C) Act. It deals with premarket submissions of medical devices and requires documenting the security risk management activities for medical device systems and calls out the need for an SBOM, in addition to activities such as vulnerability assessments and threat modeling.
It also specifically calls out the role of open-source software components incorporated into medical devices and the potential risks that should be considered from a risk-management perspective.
SSDF
While not a regulatory or contractual requirement itself, no US discussion of software supply chain security would be complete without touching on the NIST Secure Software Development Framework (SSDF).
Another item that came out of the Cyber EO requirements was the production of an updated SSDF and OMB from NIST, which has now listed it as a key aspect of the self-attestation requirements for software suppliers selling to the US federal government. SSDF leverages several existing secure software development frameworks such as OWASP’s Secure Application Maturity Model (SAMM) and the Synopsys Building Security In Maturity Model (BSIMM) to cross-reference to practices that should be observed to produce secure software.
National Cyber Strategy – Software Liability
The latest US National Cyber Strategy (NCS), published in 2023 has a significant software supply chain security focus, including calling for a need to “rebalance the responsibility to defend cyberspace.”
Shifting the focus from customers and consumers to software suppliers has been a key theme for not only the strategy but also agencies and leaders such as CISA in their “secure-by-design” initiative. Pillar Three of the NCS focuses on shaping market forces to drive security and resilience and calls out activities such as holding the stewards of data accountable and driving the development of secure devices and even introduces the hotly debated topic of “software liability”.
Securing Open-Source Software Act of 2023
The US Federal government increasingly, like the rest of society, depends on open-source software. This was publicly recognized with the “Securing Open-Source Software Act” in 2022. The act recognized the importance of OSS and called on agencies such as CISA to directly engage the OSS community. It laid out responsibilities for the CISA Director with regard to the outreach and engagement and to help facilitate improving the security of the OSS ecosystem.
European Union
Cyber Resilience Act
On the EU front, one piece of legislation that made worldwide headlines was the EU Cyber Resilience Act. It is a far-reaching and comprehensive piece of legislation that lays out common cybersecurity rules and requirements for suppliers and developers of products that include digital elements.
The act encompasses both hardware and software and any product with “digital elements”. Much like GDPR, despite being designed in the EU it has far-reaching implications by virtue of being applicable to products across the EU market, which may not actually be built originally in the EU but are sold in the EU market.
The act requires cybersecurity to be a key factor in the design and development of products with digital elements and non-compliance can lead to the restriction of product availability in the EU market in addition to administrative fines.
The Artificial Intelligence Act
Hot on the heels of the Cyber Resilience Act is the EU AI Act, which focuses on ensuring conditions for the development and use of trustworthy AI systems is implemented in the EU market. The AI Act lays out various levels of acceptable risk, from low and minimal to flat-out prohibiting some uses such as those that result in the violation of human dignity or the manipulation of human behavior.
The act is applicable to AI systems placed on the market or into services used in the EU, again, demonstrating a broad reach. Producers of systems deemed high risk will need to perform various risk-management and governance activities and self-certify their conformity with the act and failing to comply with the act can lead to up to 4% of global turnover or tens of millions of euros.
Canada
Protecting organizations from software supply chain threats is also a key priority for Canada. Canada’s Centre for Cyber Security (CCCS) contributed to the publication of “Shifting the Balance of Cybersecurity Risk: Principles and Approaches for Security-by-Design and Default.
It has also identified software supply chain attacks as a key concern in the CCCS 2023-2024 National Cyber Threat Assessment. The CCCS also published “Protecting your organization from software supply chain threats” in 2023 to give guidance to companies using the SSC.
Australia
In March 2023, the Australian Cyber Security Centre (ACSC) released the “Guidelines for Software Development” which focused on a variety of security controls across software development lifecycles and environments. It also emphasized the need for application security controls and testing to address vulnerabilities and cited the use case for SBOMs as well. Australia also participated in the international “Quad Cybersecurity Partnership: Joint Principles for Secure Software.”
Global
While each nation is pushing their own domestic agenda on software security, there are also global efforts afoot. One is dubbed the “Quad Cybersecurity Partnership: Joint Principles for Secure Software“, which was published in May 2023 and produced in collaboration between the US, India, Japan and Australia.
It focuses on adopting secure software development practices into government policy and software acquisition for suppliers. It aligns with the four phases in NIST’s SSDF and talks about the intent to require self-attestation from software producers and even third-party certifications when warranted.