Software Bill of Materials (SBOM)

A Software Bill of Materials (SBOM) is a formal, machine-readable inventory of every component inside a piece of software: libraries, their versions, licenses, and supplier information.

Just as a food label lists ingredients, an SBOM lets you answer in seconds: does this product contain the vulnerable version of X? Without one, that question can take days of manual archaeology.

When a critical vulnerability lands, the first operational question is exposure: which of our products ship the affected component?

During the Log4Shell incident, organizations with SBOMs queried their inventory and triaged in hours. Those without spent weeks grepping build directories. Regulators and major buyers increasingly require SBOMs as a procurement condition.

• Rapid vulnerability impact analysis
• License compliance and obligation tracking
• Supply chain transparency for customers and auditors

Two open standards dominate. Tooling can usually convert between them.

• SPDX — a Linux Foundation standard, strong on licensing, widely accepted by regulators
• CycloneDX — an OWASP standard, security-focused, supports vulnerability and dependency relationship data

Avoid inventing your own format; consumers and scanners expect these.

Each component entry should carry enough identity to be matched against vulnerability feeds. The key fields:

• name and version — exact, not a range
• PURL (package URL) — a universal identifier like pkg:npm/lodash@4.17.21
• hash — to verify integrity
• license — SPDX license identifier
• supplier — who produced it

Generate SBOMs automatically from source or from a built artifact. Syft is a common cross-ecosystem generator that outputs both standards.

An SBOM generated at different stages captures different truths.

• Source SBOM — what the manifest declares; may miss bundled or vendored code
• Build SBOM — what the build actually pulled in; most accurate for release
• Runtime / deployed SBOM — what is actually present in the running image, including OS packages

For supply chain assurance, generate at build time from the real artifact, and scan the final container for OS-level packages too.

An SBOM becomes powerful when fed to a matcher that maps components to known CVEs. This decouples generation from analysis: scan an old SBOM the day a new CVE drops.

An SBOM may show a vulnerable component that is not actually exploitable in your product (the vulnerable function is never called). A VEX (Vulnerability Exploitability eXchange) document records that assessment.

VEX cuts noise: instead of every customer panicking over a listed CVE, you publish a statement of not_affected with justification, or affected with remediation. It turns a raw inventory into actionable triage.

An SBOM is only trustworthy if it is authentic and tied to the exact artifact it describes. Sign it and attach it as an attestation rather than a loose file.

Manual SBOMs drift instantly. Wire generation into the pipeline so every release produces and stores one as a build artifact, ideally signed and scanned in the same job.

• Generate from the built artifact, not just the repo
• Store SBOMs in a queryable registry keyed by version
• Re-scan stored SBOMs on a schedule against fresh CVE feeds
• Gate releases on the vulnerability scan result

SBOMs fail quietly when treated as a checkbox.

• Stale — generated once and never regenerated
• Incomplete — misses OS packages, statically linked or vendored code
• Unverified — no hash linking it to the deployed artifact
• Unused — produced but never scanned or queried

An accurate, regenerated, signed, and continuously scanned SBOM is the goal, not a one-off JSON file.

Apply what you learned to an incident scenario.

You can now inventory what your software contains and act on it.

• An SBOM is a machine-readable list of every component, in SPDX or CycloneDX format
• Identify components by PURL, version, hash, and license
• Generate at build time, then feed to a matcher (grype, osv-scanner) for CVEs
• Use VEX to declare real exploitability and cut false alarms
• Sign and automate in CI; re-scan stored SBOMs against new feeds

Next: proving where artifacts came from with signing.