A SBOM (Software Bill of Materials) is a detailed list of all components used in software. The Cybersecurity and Infrastructure Security Agency (CISA) has identified six different types of SBOMs, which reflect software components at different stages of the software development lifecycle (SDLC).
The most common SBOM types are Source SBOM and Build SBOM, but depending on needs and environment, other SBOM types can be valuable.
| SBOM Type | Description | Use Case |
|---|---|---|
| Design SBOM | Planned architecture and intended components. | Used in the design phase to identify potential problems. |
| Source SBOM | Built from source code and identifies components and dependencies. | Enables early identification of vulnerabilities and code analysis. |
| Build SBOM | Generated during the build process and includes all actual dependencies. | Provides a verified and accurate representation of the software. |
| Analyzed SBOM | Created through analysis of a finished artifact, such as a binary file. | Used when source code or build environment is unavailable. |
| Deployed SBOM | Documents installed software components in a production environment. | Shows current software in production and identifies configuration-specific details. |
| Runtime SBOM | Monitors a running system and identifies active components. | Enables analysis of dynamically loaded dependencies. |
Below follows a closer description of each SBOM type and its use cases including advantages and limitations.
Design SBOM
This SBOM describes the planned architecture and components expected to be included in 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 organizations plan their projects and identify potential compatibility issues before development starts.
- Can serve as a guideline for which components are approved for use in the development process.
Limitations:
- Contains only theoretical components, meaning actual dependencies added later may be missing.
- Can be difficult to generate in detail.
Source SBOM
Created directly from source code by analyzing the code to identify components and dependencies. Usually generated with an SCA (Software Composition Analysis) tool.
Advantages:
- Enables early identification of vulnerabilities and dependencies in the codebase.
- Provides a clear picture of which components are used in a specific software.
Limitations:
- May include dependencies that are never used in the final product.
- Lacks insight into components added later in the build process.
Build SBOM
Generated during the build process and includes all dependencies actually used to create the finished software.
Advantages:
- Provides a high degree of accuracy as it reflects the actual build process.
- Enables signing of SBOM and product artifact, increasing trust.
Limitations:
- Requires adaptations in the build process to generate correctly.
- May miss dependencies loaded dynamically at runtime (see Runtime SBOM).
Analyzed SBOM
Created through analysis of a finished artifact, such as a binary file, package, or container. This type is often used when access to source code or build environment is lacking.
Advantages:
- Makes it possible to analyze legacy systems or third-party software.
- Requires no insight into the build process and can validate other SBOM data.
Limitations:
- May contain approximations as analysis tools don't always identify all components correctly.
- Dependent on heuristic methods that can lead to inaccuracies.
Deployed SBOM
Documents which software components are actually installed on a system and used in a production environment.
Advantages:
- Provides a clear picture of software components in the actual production environment.
- Can combine data from multiple SBOMs and identify configuration-specific details.
Limitations:
- Requires detailed information from the production environment, which can be difficult to collect.
- Only reflects the current installation and can change over time.
Runtime SBOM
Generated by monitoring a running system and identifying the components and dependencies actually used during operation.
Advantages:
- Identifies exactly which modules and external calls are used in real-time.
- Enables analysis of dynamically loaded components and external connections.
Limitations:
- Requires active monitoring of the system, which can impact performance.
- May miss components only used in specific runtime scenarios.
Which type of SBOM is best?
The most commonly used SBOM types are Source SBOM and Build SBOM, as they provide a detailed and verifiable picture of software composition.
For third-party software or legacy systems, an Analyzed SBOM may be the most realistic solution.
In an ideal world, a combination of multiple SBOMs is used to create as complete a picture as possible of a software's components and security risks.
Runtime SBOM
A Runtime SBOM captures the components that are actively loaded and running in the production environment.
Characteristics:
- Shows only components actually loaded and executed
- Reflects the runtime environment configuration
- May differ from build SBOM due to conditional loading or runtime optimization
- Can include dynamically loaded libraries and modules
When to use:
- For operational security monitoring
- When assessing the attack surface of running systems
- For incident response and forensic analysis
- For runtime vulnerability management
Choosing the Right SBOM Type
For Development Teams
- Source SBOM for early vulnerability detection and license compliance
- Helps catch issues before they reach production
- Supports developer education about dependencies
For Security Teams
- Build SBOM for release approval and security assessments
- Runtime SBOM for operational monitoring and incident response
- Combined approach for comprehensive security coverage
For Compliance
- Build SBOM is typically required for regulatory compliance
- Some regulations may require multiple types for complete transparency
- Runtime SBOM may be needed for continuous compliance monitoring
Implementation Considerations
Tooling
Different tools excel at generating different SBOM types:
- Source scanners work well for Source SBOMs
- Build integration tools create accurate Build SBOMs
- Runtime agents and scanners generate Runtime SBOMs
Automation
- Source SBOMs can be generated from CI/CD pipelines
- Build SBOMs require build system integration
- Runtime SBOMs need deployment and monitoring integration
Storage and Management
- Different types may require different storage and versioning strategies
- Consider how to link related SBOMs (source → build → runtime)
- Plan for SBOM lifecycle management across types
Best Practices
- Use Multiple Types: Implement multiple SBOM types for comprehensive coverage
- Automate Generation: Integrate SBOM generation into existing development and deployment workflows
- Version Control: Maintain clear versioning and relationships between different SBOM types
- Regular Updates: Update Runtime SBOMs regularly to reflect changes in production environments
- Tool Integration: Choose tools that can generate multiple SBOM types or integrate well together
Standards Compliance
Both SPDX and CycloneDX formats support metadata to indicate SBOM type, ensuring interoperability and clear communication about the SBOM's scope and purpose.
Understanding and implementing the appropriate SBOM types for your use case is essential for maximizing the value of your SBOM program and meeting various compliance and security requirements.