← Concepts & Glossary
Inventory & Provenance

SBOM (Software Bill of Materials)

A machine-readable inventory of every component in your software.

What is an SBOM?

A Software Bill of Materials is a structured, machine-readable list of every component that ships inside a piece of software — direct and transitive dependencies, the exact versions, the licenses, the suppliers, and the cryptographic hashes that identify each artifact. Think of it as the ingredients label on a packaged good, except legally binding in some jurisdictions.

Two formats dominate: CycloneDX, maintained by OWASP with a strong security focus, and SPDX, maintained by the Linux Foundation with a strong licensing focus. Both are ISO-recognised and interchangeable through well-defined conversion tools.

How it works

SBOMs are produced at three points in the lifecycle, each with different accuracy trade-offs:

  1. Source SBOM. Generated from manifests and lockfiles (package-lock.json, go.sum, pom.xml). Fast and easy, but misses components injected at build time.
  2. Build SBOM. Produced by the CI pipeline alongside the artifact, often signed as part of SLSA provenance. Reflects exactly what went into the shipped binary.
  3. Runtime / deployed SBOM. Extracted from the running container or firmware image. Catches the dynamic components that source-side tools never saw — OS packages, native libraries, sidecar binaries.

Why it matters

SBOMs are now mandated or strongly expected by US Executive Order 14028, the EU Cyber Resilience Act, the FDA for medical devices, and many tier-1 enterprise procurement processes. If your software ships to regulated buyers, not having an SBOM is increasingly a reason you lose the deal.

Beyond compliance, SBOMs are the primary join key for supply-chain security. Every vulnerability correlation, license audit, and "are we affected by X?" incident response starts with "show me everywhere this component ships." Without an SBOM, you are guessing.

What value it adds

  • EU CRA and EO 14028 compliance

    Signed, up-to-date SBOMs are the primary artifact regulators ask for. Generating them in CI is cheaper than a compliance scramble later.

  • Instant blast-radius answers

    "Which of our products ship log4j 2.17.1?" becomes a SQL query against your SBOM corpus, not an all-hands incident spreadsheet.

  • Vendor transparency at scale

    A machine-readable SBOM per release lets procurement, security, and legal evaluate third-party software the same way on every deal.

  • License risk visibility

    GPL, AGPL, and commercial-restricted licenses surface automatically — before they ship to a customer under the wrong terms.

  • Correlation with vulnerability feeds

    Every component in the SBOM can be joined against CVE, EPSS, and KEV feeds to produce a live picture of exposure, not a point-in-time scan.

How Safeguard uses it

Safeguard generates, ingests, and continuously analyses SBOMs — source, build, and runtime — and correlates them against vulnerability intelligence. See SBOM Studio, the supply-chain compliance workflow, and the related VEX companion format.

Generate a signed SBOM per build.

Point Safeguard at a repo or artifact. Get CycloneDX and SPDX outputs, diffed against previous versions.