Skip to content

SBOM Enrichment: Adding Value to Your SBOM

A generated SBOM provides a baseline inventory of software components. However, producers can significantly increase the value of their SBOMs by enriching them with additional release metadata before sharing them with consumers and distributors.

Enrichment improves the quality and completeness of the SBOM, making it more actionable for downstream stakeholders. A well-enriched SBOM helps consumers to:

  • Assess provenance: Understand where each component comes from and how it was built.
  • Ensure compliance: Verify that all license obligations are met before deployment.
  • Build trust: Demonstrate transparency through complete and accurate release metadata.
  • Enable automation: Provide the data fields that asset management and compliance tools need to operate effectively.

Release Metadata

Add product version, build identifiers, release timestamps, and supplier contact information. This helps consumers map the SBOM to a specific software release and verify its authenticity.

License Data

Go beyond auto-detected licenses. Confirm and correct license expressions for each component, resolve ambiguities, and document any license exceptions or dual-licensing arrangements. Accurate license data is essential for procurement and legal compliance.

Component Relationships

Ensure the dependency graph is complete. Document direct vs. transitive dependencies, build-time vs. runtime dependencies, and the composition completeness of each section. This allows consumers to understand the full supply chain depth.

Provenance & Pedigree

Add information about where each component’s source code originates (download URLs, source repositories), how it was built, and any modifications applied (patches, backports). This supports supply chain integrity verification.

An SBOM is created at a specific point in time and provides a static snapshot of the software’s components at that moment. To maintain accuracy, it is crucial to update the SBOM when changes are made to the software or its underlying components.

Producers should issue a new or revised SBOM when:

  • The software is updated with a new build or release.
  • A build integrates an updated component or dependency.
  • The producer learns new details about the underlying components or wishes to correct an error in the existing SBOM data.

Some producers release an SBOM for every major release, others for every minor release, and some for each code change. The appropriate approach depends on the business model and customer needs.

Vulnerability Data is NOT Part of the SBOM

Section titled “Vulnerability Data is NOT Part of the SBOM”