What is an SBOM (Software Bill of Materials)?

Understand why SBOMs are critical to supply chain security, what’s in an SBOM, and best practices for creating and maintaining SBOMs.

A software bill of materials (SBOM) is a list of software components that make up a software product. 

Today, developers often use a combination of open source components and commercial software components from third-party vendors. The objective of an SBOM is to accurately list these components, providing software users visibility over what is included in a software product, and allowing them to avoid components that can be harmful for security or legal reasons. Most commonly, organizations are concerned about using software with components that have known security vulnerabilities, compromising software supply chain security.

The concept of BOM was traditionally used in manufacturing processes. Manufacturers use BOMs to keep track of the parts used to make a product. If defects are discovered in a specific part, a BOM makes it easy to find that part and resolve the problem. SBOM extends the same concept to software development, allowing software users and vendors to know which components are problematic and remediate them. 

In this article:

Why is SBOM Important to Security?

Traditionally, organizations developed applications in-house using their own software. This methodology enabled developers and security professionals to gain visibility and control over the entire codebase. However, this model cannot meet today’s time-to-market demands for frequent software releases and updates. 

Open source software facilitates rapid development and release cycles. It enables organizations to incorporate ready-made components into their application stack so they can quickly release software. As the pace increases, so does the need for open source software. Today, even a weekly build can pull in numerous open source components. 

SBOM enables organizations to identify and track all third-party components, in particular open source components, and comply with licensing requirements. It also helps ensure that the organization does not run vulnerable open source components and keeps track of critical updates and patches. It helps organizations utilize open source components as needed while maintaining security and compliance.

SBOM Standards: CycloneDX and SPDX

Most projects that create or process SBOMs use one of two standards:

  • CycloneDX is sponsored by the Open Web Application Security Project (OWASP). The CycloneDX SBOM has associated metadata and describes a set of software elements broken down into components, services, and dependencies. The SBOM also has constructs that define relationships between elements.
  • Software Package Data Exchange (SPDX) is a project maintained by the Linux Foundation. The SPDX SBOM model defines three elements: Documents (metadata about the SBOM), Packages (groups of elements), and Files (single files). 

Both OWASP and the Linux Foundation provide a rich open source toolset that allow developers to create and edit SBOMs in their respective format. Both formats are actively maintained by a large open source community.

One difference between SPDX and CycloneDX is the set of relationships that the SBOM can express about its elements. For example, in SPDX, a file can be CONTAINED_BY a package, and a package can be a PACKAGE_OF a file. SPDX defines more granular relationships between elements, which makes it more expressive but also more complex to define and work with.

What’s in an SBOM?

The US National Telecommunications and Information Administration (NTIA) released a standard that defines the minimum requirements for an SBOM. According to the NTIA standard, an SBOM must include:

  • Author Name—usually the organization that develops the software.
  • Vendor Name—the name of the software vendor, including aliases (alternative names). Vendor and author may be different if a supplier is creating an SBOM on behalf of the vendor.
  • Component Name—the name and possible aliases of the software component.
  • Version String—the format of the version information is free-form, but should follow common industry usage.
  • Component Hash—the best way to identify a software component is to use a cryptographic hash that serves as a unique identifier.
  • Unique Identifier—in addition to the hash, each component must have an ID number that identifies it within the SBOM.
  • Relationship—defines the relationship between the component and the package. In most cases, the relationship is “included”, meaning that a certain component is included in a certain package.

In addition to these minimum requirements, an SBOM can include additional information such as security scores, common vulnerabilities and exposure codes (CVEs) of known vulnerabilities in software components, and their severity.

Software Bill of Materials Best Practices

Regularly Update the SBOM

After a software vendor creates an SBOM, it is their responsibility to maintain and update it SBOM as application components change. This includes code updates, bug fixes, new features, and other changes. These changes can happen at any time across multiple teams, and must be tracked in real time, otherwise the SBOM will quickly become outdated.

Ensure Data Integrity

Because the integrity of the information is important, it is important to be able to audit everything contained in the SBOM, including all version numbers and licenses. Information in an SBOM must come from trusted sources and must be verifiable by a third party.

Clarify Potential Issues that Can Affect Users

The SBOM should clearly show the current state of the application and what needs to be done to properly secure it. The SBOM should:

  • Clearly display existing files and components
  • Indicate files and components that are in active use
  • Call out security or other issues that require attention

The issues called out in an SBOM could include restrictive open source licenses (copyleft licenses), known vulnerabilities, and known bugs or limitations in software components. 

Identify SBOM Documents

You must clearly identify SBOM documents, because the same software version can have multiple SBOM documents. For example, you can release a new version of the SBOM to correct an error or publicize new vulnerabilities that were unknown when the previous version was released. It should be clear what is the latest version of the SBOM, and that version should contain complete, accurate, up to date information about the software product.

Try SBOMs with Aqua’s Argon supply chain security

As the leading software supply chain security company and pioneer in the market, Argon, now an Aqua Security company, was the first to release its SBOM manifest solution as part of the code-tampering prevention in the patent-pending Code Integrity Engine in 2021. The Argon SBOM manifest enables teams to identify dependencies and detect key risks in the artifact development process. This allows the implementation of a strict security evaluation of artifacts and the effective mitigation of security threats once discovered.


To learn more about SBOMs, read Gartner’s Innovation Insight for SBOMs report. If you’re ready to get started with SBOMs to enrich your DevSecOps process, try Argon.