How Organisations Can Leverage SBOMs to Improve Software Security

Software bills of materials (SBOMs) have gained traction over the past few years and are becoming a new staple in software security.

While few organisations are required to deploy SBOMs today, government agencies prepare the ground for potential broader-scale mandates by releasing guidelines and recommendations to best deploy an SBOM strategy.

According to Gartner, more than 60% of organisations will have adopted SBOMs by 2025, representing a 20% increase from 2022.

Infosecurity has selected all you need to know to get ahead of the curve and prepare your organisation for SBOM implementation.

A software bill of material is a machine-readable document that lists all software packages an organisation – or a unique business unit – uses and their dependencies, i.e., other elements the listed software is built on, including open source bricks. These can include software components such as applications, libraries, frameworks and application programmable interfaces (APIs).

Generally, an SBOM also includes:

• Software version(s)
• Software licence
• Associated vulnerabilities
• Intellectual property data, such as copyrights and patents

SBOMs are designed to be shared across organisations and are particularly helpful at providing transparency of components delivered by participants in a software supply chain.

Incorporating an SBOM into an information system audit allows auditors to identify any software security risk that needs addressing, such as outdated, unauthorised, or non-compliant components.

The concept of SBOMs can be traced back to the early 2000s in the US. However, SBOMs really started to garner focus in 2019, when the US National Telecommunications and Information Administration (NTIA) launched a multi-stakeholder initiative called the Software Component Transparency (SCT) project.

This initiative aimed to promote the adoption of bills of materials as a best practice in software development, among other things.

Since then, various industry initiatives and standards organisations, such as the Open Source Security Foundation (OpenSSF), the US National Institute of Standards and Technology (NIST) and the Linux Foundation, have worked towards adopting SBOMs. 

Organisations Mandated to Deploy SBOMs

In May 2021, US President Joe Biden issued an Executive Order tasking the National Institute of Standards and Technology (NIST) to develop a set of best practices to improve software security. This EO was codified in legal, actionable documents in 2022, meaning that US agencies are now required to obtain SBOMs from their software producers.

In December 2022, a coalition of cybersecurity industry associations published an open letter urging the US Congress to delay SBOM requirements for defence contractors, arguing that the existing SBOM technologies were not mature enough.

In October 2023, NASA, the US Department of Defense (DoD) and the US General Services Administration (GSA) proposed new rules for federal contractors that would require them to develop and maintain an SBOM.

This proposition was included in the Cyber Threat and Incident Reporting and Information Sharing bill (FAR Case 2021-017).

While not universally mandated yet, specific industries, especially those handling sensitive data or critical infrastructure, are more likely to encounter SBOM requirements through:

• Contractual obligations: Many large organisations are starting to include SBOM requirements in their contracts with vendors, making it a de facto necessity for businesses working within their supply chains.
• Sector-specific regulations: Some sector-specific rules might indirectly mandate SBOMs, particularly in industries like healthcare or automotive, where stringent security standards are already in place.

ADVERTISEMENT

Existing Government Guidelines in Europe and the US

Many governments have published recommendations regarding SBOM implementation.

In Europe, the EU Agency for Cybersecurity’s (ENISA) Guidelines for Securing the Supply Chain for the Internet of Things provides a valuable resource for organisations seeking to enhance their cybersecurity posture and manage supply chain risk associated with software.

Other countries have published guidelines, including:

• The UK National Cyber Security Centre (NCSC) which recommends that organisations use SBOMs to understand the risk associated with the software components they use and to identify and manage vulnerabilities in those components.
• The Australian Cyber Security Centre’s (ACSC) Information Security Manual: Guidelines for Software Development, which 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.”
• The Canadian Communications Security Establishment’s (CSE) Recommendations to Improve the Resilience of Canada’s Digital Supply Chain, which recommends the use of SBOMs to improve transparency and the ability to address software supply chain attacks.

In the US, SBOM recommendations are included in several government guidelines, including:

• Cybersecurity and Infrastructure Security Agency’s (CISA) guidelines for secure software development, completed in 2023 with three SBOM-related documents, focusing on scaling and operationalising SBOM use, exploring new technologies and use cases, and facilitating community engagement in SBOM development.
• Department of Commerce and National Telecommunications and Information Administration’s Minimum Elements for a Software Bill of Materials (SBOM), published in July 2021.
• NIST Special Publication (SP) 800-218, called 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.
• National Security Agency’s (NSA) guidance to help organisations incorporate SBOMs and combat the threat of supply chain attacks, published in December 2023.

Read more: Regulations for SBOMs are Useless if You Cannot Take Action

Creating an SBOM? 

To create an SBOM, organisations need to collect relevant information about each software component. Several tools and techniques are available to assist in this process.

One of the easiest approaches is to do it manually. However, this can be a fastidious task and requires that developers and software architects maintain an inventory of the components used in their applications. 

A more scalable option is to leverage software composition analysis (SCA) tools, which automatically analyse an application's dependencies and generate an SBOM.

Additionally, some tools integrate with vulnerability databases and provide real-time alerts when new vulnerabilities are discovered in the components.

Some security solutions providers, like NetRise or ActiveState, offer SBOM management packages, sometimes with extra features, including support for the CISA Known Exploited Vulnerabilities (KEV) Catalog.

In its December 2023 guidance, NSA advised software users to refer to NIST’s Secure Software Development Framework (SSDF) and the Software Component Verification Standard (SCVS). They can also look at the Open Web Application Security Project (OWASP) and materials from CISA.

SBOM Formats Compared

When deploying an SBOM, one of the first choices organisations will face is which SBOM standards to use.

Based on NIST recommendations, the US government currently recognises three SBOM standards:

• CycloneDX: This lightweight SBOM standard from OWASP aims to provide guiding principles for reinforcing a risk-based approach to standard development. The CycloneDX SBOM specification supports XML, JSON, and Protocol Buffers. It includes a collection of official and community-supported tools that create or interoperate with the standard. 
• Software Package Data Exchange (SPDX): It provides a format for communicating the components, licenses, and copyrights of software packages and supports various formats, including RDF, XLS, SPDX, YAML, and JSON. Although it started as an open source project hosted by the Linux Foundation, it is now driven by a consortium of vendors, system integrators, and other foundations. It is recognised as an international standard (ISO/IEC 5962:2021).
• Software Identification (SWID) tag: SWID tags contain data and metadata about a particular software product version. They are supported by both the Trusted Computing Group (TCG) and the Internet Engineering Task Force (IETF).

Maturity Assessment

Are you ready to deploy an SBOM? A great way to find out is by performing an SBOM maturity assessment.

Many private companies provide SBOM maturity assessment solutions, but you can also follow the steps provided in OWASP SCVS’ BOM Maturity Model.

Read more: #HowTo: Create and Maintain SBOMs

Enjoyed this article? Make sure to share it!

Looking for something else?