In a world where software is an integral part of everyday life, ensuring the security and transparency of these products has become a top priority. With the rise of software-based products, regulators have quickly implemented new standards to help manage the complexities of the software supply chain. One tool that has been gaining traction in this effort is the software bill of materials (SBOM).
An SBOM is a comprehensive list of all the components that make up a software product. This list includes information about the version and source of each component, providing a clear understanding of the product's makeup. SBOMs are essential for ensuring software security and transparency because they enable organizations to easily track and manage their software supply chain and identify potential vulnerabilities or malicious code. SBOMs are becoming increasingly mandatory in various industries and are considered a critical component of any organization's regulatory compliance strategy. The regulations and standards that require or recommend using SBOMs include:
- The US Cybersecurity and Infrastructure Security Agency (CISA) recommends using SBOMs as part of its guidelines for secure software development.1 Executive Order 14028 directs the US National Institute of Standards and Technology (NIST) to develop guidelines for creating and publishing SBOMs and establish criteria for using SBOMs in federal procurement processes.2, 3 The US National Telecommunications and Information Administration SBOM defines a set of minimum elements that should be included in an SBOM. These minimum elements are package name, version, unique identifier, licensing information, dependencies, known security vulnerabilities and software hash.4
- The EU Agency for Cybersecurity (ENISA) Guidelines for Securing the Supply Chain for the Internet of Things provides a valuable resource for organizations seeking to enhance their cybersecurity posture and manage supply chain risk associated with software.5
- The UK National Cyber Security Centre (NCSC) recommends that organizations use SBOMs to understand the risk associated with the software components they use and to identify and manage vulnerabilities in those components.6
- The Australian Cyber Security Centre (ACSC) Information Security Manual: Guidelines for Software Development recommends the use of SBOM as it “can assist in providing greater cyber supply chain transparency for consumers by allowing for easier identification and management of security risks associated with individual software components used by applications.”7
- The Canadian Communications Security Establishment (CSE) Recommendations to Improve the Resilience of Canada’s Digital Supply Chain recommends the use of SBOM to improve transparency and ability to address software supply chain attacks.8
- International Organization for Standardization (ISO)/ International Electrotechnical Commission (IEC) 29147:2018 Information technology—Security techniques—Vulnerability disclosure is an international standard that provides guidelines for vulnerability disclosure.9 The standard provides guidance for all stakeholders involved in the vulnerability disclosure process, including vendors, vulnerability researchers and users. It outlines best practices for identifying and reporting vulnerabilities and responding to vulnerability reports in a timely and effective manner. The standard does not specifically address SBOMs, but it does provide guidance on vulnerability disclosure that can be used in conjunction with SBOMs to improve the security of software products. By following the best practices and principles outlined and using an SBOM to manage software supply chain risk, organizations can improve the security and resilience of their software products and better protect against cyberthreats.
- NIST Special Publication (SP) 800-218 Secure Software Development Framework (SSDF) Version 1.1: Recommendations for Mitigating the Risk of Software Vulnerabilities provides guidelines for using SBOMs as part of secure software development.10
It is worth noting that these regulations and standards are subject to change and may vary by jurisdiction. Security auditors should stay up to date on the latest developments in their region to ensure that they are aware of the most current requirements and best practices.
The need for SBOM regulations arises from the increasing reliance on software in critical systems and the increasing number of security incidents involving software. With the growth of software, it is becoming challenging to manage the security and integrity of these products. Software products often rely on complex networks of components and libraries, many of which are developed and maintained by third-party organizations. A vulnerability in one of these components can quickly spread to other products that use the same component, potentially affecting millions of systems.
For example, in December 2021, a severe security vulnerability called Log4Shell was discovered in a popular software library, Apache Log4j.11 This vulnerability risked millions of systems using the vulnerable version of the Log4j library. To make matters worse, fixing the vulnerability required updating the Log4j library, but doing so can be complicated and time-consuming, especially for large and complex systems. In the case of the Log4Shell vulnerability, the lack of an SBOM for the affected versions of the library made it difficult for organizations to quickly determine whether the vulnerability impacted them, and which specific components needed to be updated.
Another example is the SolarWinds hack, a major cyberattack discovered in December 2020 that affected many US government agencies and private enterprises. A group of hackers, believed to be from Russia infiltrated SolarWinds, a software enterprise that provides network management tools, to carry out the attack. They inserted malware into an update for the enterprise’s Orion software, which was then downloaded and installed by many of its customers. The malware allowed the hackers to access sensitive information and conduct espionage activities. The incident highlighted the vulnerability of software supply chains and the need for improved cybersecurity measures.12 In the case of the SolarWinds hack, one of the critical issues was the lack of an SBOM for the affected version of the Orion software. The lack of an SBOM made it difficult for organizations to quickly determine which specific components needed to be updated or removed to mitigate the hack's impact.
Regulators have called for SBOM regulations that require software vendors to furnish complete and accurate information about the components and libraries used in their products. Organizations then use this information to assess the security of and risk posed by the software they use and make informed decisions about what products to use and how to secure them. In short, the need for SBOM regulations stems from the need to ensure the software security and integrity and help organizations make informed decisions about the software they use.
Incorporating an SBOM into an information system audit allows auditors to understand the software used within the organization and identify any security risk that needs addressing. The risk includes issues such as:
- Outdated components—The SBOM can highlight any components that are no longer supported or have known security vulnerabilities.
- Unauthorized components—The SBOM reveals any components the organization did not approve, potentially posing security risk.
- Noncompliance with regulations—The SBOM ensures that the software complies with relevant security regulations and standards.
By combining an SBOM with an information system audit, organizations ensure their software's security and protect their data from cyberthreats. Thus, using SBOMs builds trust in the security of the organization's systems and helps reduce the risk of a security breach.
Incorporating an SBOM into an information system audit allows auditors to understand the software used within the organization and identify any security risk that needs addressing.An SBOM is a valuable tool for ensuring the security and transparency of software products. As regulators continue to mandate SBOMs, organizations must invest in tools and processes to create and maintain SBOMs accurately. The future of software development and supply chain management is sure to be shaped using SBOMs, making them critical components of any organization's regulatory compliance strategy.
Endnotes
1 Cybersecurity and Infrastructure Security Agency, “Software Bill of Materials” USA
2 Biden, J. R.; Executive Order on Improving the Nation’s Cybersecurity, The White House, USA, 12 May 2021
3 National Institute of Standards and Technology (NIST), “Improving the Nation's Cybersecurity: NIST’s Responsibilities Under the May 2021 Executive Order,” USA, 12 May 2021
4 US Department of Commerce and National Telecommunications and Information Administration, The Minimum Elements for a Software Bill of Materials (SBOM), USA, 12 July 2021
5 Skouloudi, C.; A. Malatras; R. Naydenov; G. Dede; Guidelines for Securing the Internet of Things, European Union Agency for Cybersecurity, Greece, 2020
6 National Cyber Security Center (NCSC), “NCSC Issues Fresh Guidance Following Recent Rise in Supply Chain Cyber Attacks,” United Kingdome, 12 October 2022
7 Australian Cyber Security Centre, Information Security Manual: Guidelines for Software Development, Australia, 2022
8 Canadian Forum for Digital Infrastructure Resilience Supply Chain Assurance Working Group, Recommendations to Improve the Resilience of Canada’s Digital Supply Chain, Canada, 2022
9 International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC), ISO/IEC 29147:2018 Information Technology—Security Techniques—Vulnerability Disclosure, Switzerland, 2018
10 Souppaya, M.; K. Scarfone; D. Dodson; National Institute of Standards and Technology (NIST) Special Publication (SP) 800-218 Secure Software Development Framework (SSDF) Version 1.1: Recommendations for Mitigating the Risk of Software Vulnerabilities, USA, 2022
11 Log4j, “Apache Log4j Security Vulnerabilities,” 13 September 2022
12 Temple-Raston, D.; “A 'Worst Nightmare' Cyberattack: The Untold Story of the SolarWinds Hack,” NPR, 16 April 2021
Shailesh Y. Rangari
Is a security engineering leader at Cisco Inc. He has more than 14 years of experience in offensive security, secure development practices and software security. He led the offensive security practice at NVIDIA Corporation and was a manager at Ernst & Young's security consulting practice.