Understanding Secure Software Supply Chain Legislations Around the World

The rash of ransomware attacks, zero-day exploits, IT infrastructure attacks, and so on that occurred over the course of the pandemic finally prompted governments worldwide to effectively declare war on the software supply chain. 

But this explosion in supply chain attacks is just a symptom. The actual root causes are many and varied, including:

• Vulnerabilities – typically a coding flaw in a module of an application that compromises the security of the software, thereby offering hackers a vector of attack (i.e., log4j).
• Compromised Ecosystems – open source public repositories can be compromised in a number of different ways:
  • Typosquatting – compromised open source packages in public repositories that are named similar to popular packages (i.e., matplatlib instead of matplotlib).
  • Dependency Confusion – similar to typosquatting, compromised packages are named similar to proprietary packages a target company may use internally. The confusion arises when a build tool prioritizes dependencies in public repositories over private ones (i.e., AWS-requests).
  • Author Impersonation – the process of compromising a public repository that has poor identity and access management controls.
  • Malware – an open source package that contains malicious code.
• Compromised Build Systems – artifact build systems created without strict security and integrity controls can allow hackers to inject compromised code.
• Compromised Delivery Systems – artifact delivery systems created without strict security and integrity controls can allow hackers to compromise updates, patches, new releases, and so on.

In other words, the software supply chain extends across the entire software development lifecycle, from:

• Import – the process of importing third-party tools, libraries, code snippets, packages and other software resources in order to streamline development efforts.
• Build – the process of compiling, building and/or packaging code, usually via an automated system that also executes tests on built artifacts.
• Delivery – the process of distributing and running built artifacts in dev/test/production, as well as on customer systems.

This complexity has stymied a comprehensive software supply chain security initiative for the better part of three decades. No longer. Where the market has failed to act, multiple governments worldwide are now enacting legislation to impose a solution, whether the software industry is prepared for it or not. 

National Secure Software Supply Chain Legislation

Governments typically have thousands of software vendors that supply, maintain and update solutions that keep public services running. They have long dealt with the threat of vulnerabilities, but when a trusted government software vendor is itself compromised (as happened with Solarwinds) the risk becomes exponentially more dangerous.

As a result, governments across the globe are drafting legislation to mandate that software vendors secure their software supply chain. But even if only one large government manages to enact their law, all software vendors worldwide that want to do business in that country will need to get on board. The European Union’s (EU) General Data Protection Regulation (GDPR) is a good example, impacting not only European organizations, but all companies that do business in the EU.

With that in mind, here is a list of current initiatives we should all be keeping an eye on.

US Secure Software Supply Chain Requirements and Legislation

While the US’s proposed legislation has yet to pass, it is the country that is perhaps furthest ahead in clarifying exactly what they mean when they expect software vendors to secure their software supply chain. These requirements have been explained in numerous missives, including:

• U.S. Presidential Executive Order on Improving the Nation’s Cybersecurity (EO 14028), which kickstarted the US initiative following the Solarwinds attack.
• Memorandum M-22-18 – which spells out specific requirements for software vendors that want to sell to US government departments and agencies, along with some alarmingly fast-approaching deadlines. 
• Secure Software Development Framework (SSDF), which provides an overview of what the US government considers to be secure software development. 
• NIST Software Supply Chain Security Guidance, which spells out recommended processes and procedures software vendors can implement to realize a secure software development practice.

With these communications, the US government has effectively given the software industry a heads up on pending legislation, namely:

• H.R.4611 – a proposed bill from the Department of Homeland Security known as the “DHS Software Supply Chain Risk Management Act of 2021” that directs US government software vendors to provide an SBOM, certification of vulnerability status, as well as notifications/plan to remediate vulnerabilities as they become known.
• Securing Open Source Software Act of 2022 – a bill that directs the Cybersecurity and Infrastructure Security Agency (CISA) to strengthen the security of open source software.

Learn more about the US government’s specific requirements:

• SBOMs – provide an “ingredients list” of all the components that make up a software application. Learn how to use SBOMs to support secure software development.
• Software Attestations – provide metadata that can be used to independently validate the security and integrity of an application. Learn how to generate attestations for open source libraries.
• Secure Software Development – specifically, adoption of the secure software development frameworks published by the US National Institute of Standards and Technology (NIST). Learn about the US Government’s Secure Software Supply Chain Best Practices.

EU Secure Software Supply Chain Requirements and Legislation

The EU has recognized that weaknesses in the software supply chain pose a significant threat to all users of software, and has responded with studies, recommendations and a bill currently working its way through the EU parliament:

• ENISA Threat Landscape for Supply Chain Attacks – provides an overview of incidents and trends that have characterized software supply chain attacks around the world, and makes some basic recommendations for software vendors:
  • Ensure that software development infrastructure follows cybersecurity best practices.
  • Ensure development, maintenance and support processes follow best practices.
  • Monitor security vulnerabilities.
  • Maintain an inventory of assets that includes patch-relevant information.
• Cyber Resilience Act – proposes cybersecurity rules and regulations for all products with digital elements in order to ensure:
  • Vendors improve security from design to development, as well as throughout the entire lifecycle of a product.
  • Vendors put in place a coherent cybersecurity framework, as outlined in Annex I of the Act.
  • Transparency of security properties.
  • Businesses and consumers can use products securely.

The Act introduces the concept of “cybersecurity certification” which is meant to reflect the cybersecurity risk of a product based on conformity to the Act’s requirements. Vendors are expected to: 

• Self-assess their security risk against the Act’s requirements.
• Include the risk assessment in their documentation.
• Update the level of security risk for at least five years.
• Notify ENISA of any security event or vulnerability within 24 hours of becoming aware of it, as well as notify customers and the author(s) of the vulnerable component(s).
• Withdraw or recall products if they are unable to resolve issues that result in an elevated cybersecurity risk.

Failure to comply with these requirements will result in revocation of the cybersecurity certification, thereby restricting market access, as well as fines of up to 15M Euros. 

Global Government Secure Software Supply Chain Initiatives

In comparison to the proposed US and EU legislation, other countries continue to lag behind in addressing the wider range of emerging software supply chain risks (beyond just vulnerabilities) with requirements and legislation. For example: 

• Canada – Bill C-26 addresses only the threat to the Telecom industry and currently fails to address the fact that all creators of software, regardless of industry, are subject to supply chain threats.
• United Kingdom – while the UK recognizes the growing threat of software supply chain attacks, they last updated their Network and Information Systems Regulations in 2020 prior to the new wave of supply chain attacks. 
• Germany – The Law on the Federal Office for Information Security (BSIG) was updated in 2021 and aligns closely with the EU’s Cyber Resiliency Act.
• ASEAN – the Association of Southeast Asian Nations (ASEAN) ten members are only in planning mode at this point, with a target of 2025 before a set of regulations addressing cybersecurity will be made available. 
• Japan – While the Draft Law Concerning Promotion of Ensuring Security through Integrated Economic Measures allows for the government to regulate and vet the way security-sensitive sectors (energy, water supply, information technology, finance, transportation, etc) procure overseas software, it is narrowly focused on specific industries rather than broadly applicable to all businesses at this point.

Conclusions – Legislating Software Supply Chain Security

It should be clear that as software vendors we have the choice of waiting for governments to force us to comply with software supply chain security regulations, or we can take steps to secure it on our own.

The good news is that there are a number of market-driven initiatives (rather than government-imposed rules) that are already addressing the cybersecurity issues inherent in the software supply chain:

• Supply chain Levels for Software Artifacts (SLSA) is a security framework originally proposed by Google that can help software vendors fast track their software supply chain security projects. 
  • Learn more about How To Secure Your Software Builds With SLSA
• ActiveState Platform provides a zero-config, cross-platform build service for open source language runtimes. The ActiveState Platform’s secure build service provides controls to meet SLSA Level 4 standards, while delivering SBOMs and software attestations to address government requirements. 
  

Read Similar Stories