Different types of SBOMs
The six SBOM types from CISA, from design to operation
An SBOM describes a piece of software at a point in time, and the content depends on when and how it is created. The US agency CISA has defined six types of SBOM, corresponding to different stages in the software lifecycle.
The most common are the Source SBOM and the Build SBOM.
| SBOM type | Description | Use |
|---|---|---|
| Design SBOM | Planned architecture and intended components. | Used in the design phase to identify potential problems. |
| Source SBOM | Built from the source code, listing components and dependencies. | Enables early identification of vulnerabilities and code analysis. |
| Build SBOM | Generated in the build process, with all actual dependencies. | Gives a verified and exact representation of the software. |
| Analyzed SBOM | Created by analysing a finished artefact, such as a binary file. | Used when source code or build environment is not available. |
| Deployed SBOM | Documents installed software components in an operating environment. | Shows current software in production and configuration-specific details. |
| Runtime SBOM | Monitors a running system and identifies active components. | Enables analysis of dynamically loaded dependencies. |
Design SBOM
A Design SBOM describes the planned architecture and the components that are expected to be part of a product. It is often based on design specifications or requests for proposals (RFP) and is used to identify potential problems at an early stage.
Advantages:
- Helps organisations plan their projects and identify compatibility problems before development starts.
- Can serve as a guide to which components are approved for use in development.
Limitations:
- Contains only planned components, so actual dependencies added later can be missing.
- Can be hard to generate in detail.
Source SBOM
Created directly from the source code by analysing it to identify components and dependencies. Usually generated with an SCA tool (Software Composition Analysis).
Advantages:
- Enables early identification of vulnerabilities and dependencies in the code base.
- Gives a clear picture of which components a piece of software uses.
Limitations:
- Can include dependencies that are never used in the final product.
- Lacks insight into components added later in the build process.
Build SBOM
Generated in the build process and includes all dependencies that are actually used to create the finished software.
Advantages:
- High accuracy, because it reflects the actual build.
- Makes it possible to sign the SBOM and the product artefact together.
Limitations:
- Requires changes to the build process to generate correctly.
- Can miss dependencies that are loaded dynamically at runtime (see Runtime SBOM).
Analyzed SBOM
Created by analysing a finished artefact, such as a binary file, a package or a container. This type is often used when there is no access to source code or build environment.
Advantages:
- Makes it possible to analyse older systems or third-party software.
- Requires no insight into the build process and can validate the data in other SBOMs.
Limitations:
- Can contain approximations, because analysis tools do not always identify every component correctly.
- Depends on heuristic methods that can introduce errors.
Deployed SBOM
Documents which software components are actually installed on a system and used in a production environment.
Advantages:
- Gives a clear picture of the software components in the actual operating environment.
- Can combine data from several SBOMs and identify configuration-specific details.
Limitations:
- Requires detailed information from the operating environment, which can be hard to collect.
- Reflects only the current installation and can change over time.
Runtime SBOM
Generated by monitoring a running system and identifying the components and dependencies that are really used in operation.
Advantages:
- Identifies exactly which modules and external calls are in use.
- Enables analysis of dynamically loaded components and external connections.
Limitations:
- Requires active monitoring of the system, which can affect performance.
- Can miss components that are only used in specific scenarios.
Which type should you choose?
- For software you build yourself: a Build SBOM, because it describes what is actually shipped.
- For third-party software or older systems: an Analyzed SBOM, when the supplier does not provide one and the source code is not available.
- For systems in operation: a Deployed or Runtime SBOM as a complement, when it matters what is actually installed and running.
Always state which type an SBOM is when it is shared. The recipient needs to know whether it describes what was declared in the source code or what was shipped. In CISA's draft of updated Minimum Elements this is a field of its own, Generation Context.