SBOM (Software Bill of Materials)

An SBOM (Software Bill of Materials) is a machine-readable inventory of all components, libraries, and dependencies of a software system, including their versions and licences. It is the foundation of supply chain security: only those who know what is in their software can systematically remediate known vulnerabilities (CVEs).

Without an SBOM, the attack surface is unknown. The Log4Shell incident in 2021 painfully showed many organisations how many of their systems contained a particular library without anyone knowing.

What an SBOM Contains

• Components: All direct and transitive dependencies (libraries, frameworks, packages).
• Versions: Exact version numbers for vulnerability matching.
• Licences: SPDX licence identifiers for compliance checks.
• Provenance: Where does a component come from? Which source repository does it correspond to?
• Hashes: Cryptographic checksums for integrity verification.

Formats and Standards

• SPDX: ISO/IEC 5962, the standardised format for SBOMs. spdx.dev
• CycloneDX: Widely used, security-oriented format. cyclonedx.org
• SWID Tags: Software identification tags per ISO/IEC 19770-2, prevalent in enterprise environments.

Generation and Integration

1. Build-Time Generation: Tools such as Syft, cdxgen, or Trivy automatically generate SBOMs within the CI/CD process.
2. Dependency Tracking: The SBOM is updated at every build and stored in the artefact repository.
3. Vulnerability Scanning: The SBOM is matched against CVE databases (NVD, OSV).
4. Licence Compliance: Automated checking for licence conflicts (e.g. GPL in proprietary projects).

Focus: Reactivity on Zero-Days

When a new critical vulnerability becomes known, the SBOM can answer within minutes which systems are affected.

Exchange Across Organisational Boundaries

An SBOM is not produced only internally. It is increasingly exchanged between organisations, because software today is assembled from purchased and open-source building blocks.

• Procurement: Customers request an SBOM from their suppliers to check, before operation, which components are contained in a purchased piece of software. In security-critical and public tenders, this proof of transparency is often mandatory.
• Technical Review: In acquisitions and audits, an SBOM makes the technological quality and vulnerability risk of an external codebase visible without requiring the source code to be disclosed.
• Ongoing Monitoring: A received SBOM is imported into a management platform and continuously matched against new CVEs. This stays important because vulnerabilities often become known only years after delivery.

Regulatory Drivers

In many places, SBOMs are no longer optional but mandated. The CISA Minimum Elements define which data an SBOM must contain at a minimum. US Executive Order 14028 requires an SBOM for software delivered to US federal agencies. The EU Cyber Resilience Act makes a bill of components mandatory for connected products on the European market.

Sources

• cisa.gov SBOM (Software Bill of Materials). US authority, leading in SBOM standards and minimum elements. (2021). www.cisa.gov/topics/information-communications-technology-supply-chain-security/sbom
• github.com/anchore/syft Syft. Open-source SBOM generator. github.com/anchore/syft
• dependencytrack.org OWASP Dependency-Track. SBOM management platform. dependencytrack.org

---

• Related Topics: Public Code and SBOM | Technology: Security Strategy | Compliance | Standards