Software Bill of Materials

What is an SBOM?

A software bill of materials (SBOM) lists all packages and libraries included in an application. It's essentially the digital equivalent of a manufacturing bill of materials. And just like a traditional BOM includes all sub-assemblies, an SBOM includes transitive dependencies – or your components' dependencies. SBOMs make it easy to see if there are any risky packages in an application.

An SBOM is the first step toward taking control of your dependencies and managing risk from open source components. In recent years, the number of cyberattacks targeting open source components has skyrocketed. SBOMs give you insight into your dependencies and can be used to look for vulnerabilities, license issues, and other risky components.

Why do I need an SBOM?

Some vendors require an SBOM when purchasing software to manage their security. And while they are not universally required at the moment, the US National Telecommunications and Information Administration has laid the groundwork for requiring SBOMs from vendors in the future.

What are the minimum requirements for an SBOM?

Data fields

Every SBOM provides general information for component identification.

This information includes:

• The supplier name.

• The component name.

• The version.

• The dependency relationship.

• The author of the SBOM.

• The time the data was added to the SBOM.

Automation support

An SBOM must include support for automatically generating and parsing, with the goal being interoperability across organizations. An SBOM from one organization should be easy to parse without adopting new tools.

Currently accepted formats that meet the requirements for automation support include:

• SPDX

• CycloneDX

• Software identification tags

Are all SBOM formats the same?

Over time, various software groups have created a few different formats for a software bill of materials. Each one has its advantages

The two most common SBOM formats are:

CycloneDX

• Created by the Open Web Application Security Project (OWASP).

• Built with cybersecurity in mind.

• Allows for the inclusion of vulnerability information.

• Allows links to a separate Vulnerability Exploitability Exchange (VEX), which can indicate false positives and component vulnerability information.

SPDX (Software Package Data Exchange)

• Developed by the Linux Foundation.

• Built with license compliance in mind.

• Makes collecting and sharing package data easier

CycloneDX and SPDX meet the National Telecommunications and Information Administration’s minimum requirements for a Software Bill of Materials.

Why is a software bill of materials necessary?

An SBOM:

• Provides a consistent, readable profile of an application's dependencies.

• Provides a standard format that customers can easily understand

• Can be automatically generated during a project's build step to ensure up-to-date dependency information.

• Standardizes the way dependencies are listed.

• Makes reviewing dependencies easy, regardless of the ecosystem.

• Makes automation easier through standardization.

Why do creators need SBOMS?

• Maintaining a software bill of materials helps track a project's dependencies.

• Keeping track of package versions makes finding vulnerable components easier.

• Using a single standard for storing dependency info allows teams to improve consistency.

• An SBOM helps reduce the burden of working across ecosystems.

Why do consumers need SBOMs?

• It's a more transparent way to operate.

• Allows consumers to ensure a product meets their internal security and architectural requirements.

• Third-party software with an SBOM is less risky than third-party software without one.

• Consumers can use the SBOM to monitor their security.

• Many tools can scan an SBOM and generate a list of vulnerabilities.

When should an SBOM be made publicly available?

Discretion should always be exercised when deciding when and how an SBOM is shared. For projects where the source code is proprietary or private, making it available to existing customers and qualified leads is recommended.

When it comes to open source projects, there is little risk to incur from maintaining a publicly shared SBOM. Why? The dependency information is already publicly available.

A best practice is to create a public advisories page to call out false positives. Making this info publicly available provides additional transparency and gives users another way to monitor their safety.