Types and Uses of SBOMs

The original and still primary use of a software bill of materials (SBOM) is to list what components are included in a software when provided to a customer. As explained, there are two main uses:

Governance and compliance. Large companies in a supply chain wanted and still want to know what components they have to deal with, often in advance of a delivery. The primary reason is open source governance (ensuring only desired components are included) and license compliance (making sure the licenses can be complied with).
Security. More recently, fueled by worries of cybersecurity, governments including the US and the EU have put forth requirements that any product is to come with an SBOM. This way, users can identify any security issues with the product as vulnerabilities of the included components become known. SBOMs have become a purchasing requirement.

This is not the only type of SBOM, there are several more.

The most prominent classification of SBOM types is provided in a 2023 whitepaper by the U.S.’ Cybersecurity & Infrastructure Security Agency (CISA) [1]. CISA identifies six different types of SBOM, which can be broken down into two sets of three depending on how the SBOM is created:

SBOMs created from the supplier’s development process
1. Design. A Design SBOM is created from planning documents like prospective product architectures. As a consequence, a Design SBOM may not be an accurate reflection of what will be shipped eventually. It may be helpful to buyers in a supply chain to prepare for what’s to come their way.
2. Source. A Source SBOM provides a static picture of the supplier’s source code and its dependencies, as found in the repositories. It can be helpful to identify vulnerabilities, but does not provide a complete picture as it omits any build or runtime dependencies.
3. Build. A Build SBOM is created from the build process of the supplier as it compiles source code and assembles the final package for delivery to customers. Aimed at operations, it does not include components needed for building and testing. It may still miss dynamic dependencies though.
SBOMs created by the buyer (or others) through analysis
1. Analyzed. An Analyzed SBOM is created from software composition analysis of the static delivered software. This is almost always a binary analysis of the artifact. As such, an Analyzed SBOM will miss much, but it may discover components that the suppliers may have overlooked.
2. Deployed. A Deployed SBOM is created from analyzing the deployed software. After deployment, additional components may have been loaded or may have become visible that were not identifiable before. Like Analyzed, Deployed SBOMs complement the supplier’s SBOMs.
3. Runtime. A Runtime SBOM is created from observing the running software (often requiring instrumentation). Of the SBOMs created through analysis, a Runtime SBOM provides the most comprehensive picture, but it will miss components that have not been activated and are not visible yet.

The original type of SBOM mentioned in the beginning corresponds to the Build SBOM created by the supplier. Other SBOM types have other uses, for example, the developer may want to track and document details of testing and staging their products for various reasons, for example, debugging, auditability, or certification.

There is a logic of progression in the two classes of SBOMs. A Build SBOM is by and large more comprehensive and more accurate than a Source SBOM than a Design SBOM, and a Runtime SBOM is by and large more comprehensive and more accurate than a Deployed SBOM than an Analyzed SBOM.

Both classes complement each other: SBOMs created by the supplier may miss some dynamically loaded components, knowingly or unknowingly, and SBOMs created by user analysis may miss some or many of the components that the system has not yet run into or that were obscured otherwise. Taken together, a Build SBOM and a Runtime SBOM, can provide a comprehensive picture, one that is needed for safe and secure operations.

[1] See Types of Software Bill of Material (SBOM) Documents

Return to overview.