Skip to content

2-3-6-1-SBOM.md

Latest commit

 

History

History
117 lines (82 loc) · 8.03 KB

2-3-6-1-SBOM.md

File metadata and controls

117 lines (82 loc) · 8.03 KB
Raw

Software Bill of Materials (SBOM)

A Software Bill of Materials (SBOM) is a formal, machine-readable inventory of every component that makes up a piece of software — its open-source and third-party dependencies, versions, and relationships. Just as a food label lists ingredients, an SBOM lets you (and your customers) know exactly what is inside an application. When a new vulnerability like Log4Shell is disclosed, an organization with SBOMs can answer "are we affected, and where?" in minutes instead of weeks.

Why SBOMs matter

  • Rapid vulnerability response — instantly map a new CVE to every affected artifact across your estate. Without SBOMs, Log4Shell-style responses require manual inventory across hundreds of repositories.
  • Supply-chain transparency — know your transitive dependencies, not just direct ones. The 2021 Executive Order found that most organizations could not accurately enumerate their software components.
  • Regulatory drivers — SBOMs are increasingly required (US Executive Order 14028, EU Cyber Resilience Act, FDA guidance for medical devices) for software sold to governments and regulated markets.
  • License and risk management — feed SBOM data into SCA, license checks, and procurement decisions.
  • Customer assurance — enterprise customers increasingly request SBOMs as part of vendor security questionnaires and procurement due diligence.

Generating SBOMs well

  • Generate during the build, not after the fact — only the build sees the exact resolved dependency tree, so build-time SBOMs are the most accurate. Post-build SBOMs are reconstructions, not observations.

  • Use a standard format — the two dominant machine-readable standards are SPDX and CycloneDX. Publish at least one; CycloneDX is generally better supported by tooling for vulnerability analysis.

  • Produce SBOMs at multiple layers — source (lock files), container image (OS packages + application dependencies), and final artifact each tell part of the story.

  • Store and version them alongside the artifact, ideally as a signed attestation attached to the artifact in the registry:

    # Generate SBOM with Syft for a container image
syft myapp:v1.2.3 -o cyclonedx-json > sbom.json

# Attach as a signed attestation with cosign
cosign attest --predicate sbom.json --type cyclonedx myapp:v1.2.3
    # Generate SBOM for a repository with cdxgen
cdxgen -t java -o sbom.json .

SBOM content requirements

For a useful SBOM (per CISA minimum elements guidance):

  • Component name, version, and supplier/origin
  • Unique identifiers (CPE, PURL — Package URL is now the preferred identifier)
  • Dependency relationships (not just a flat list)
  • Author and timestamp of the SBOM itself
  • SBOM format version and creation tool

Package URL (PURL) is the key interoperability identifier:

pkg:npm/%40angular/core@15.2.0
pkg:maven/org.apache.logging.log4j/log4j-core@2.14.1
pkg:pypi/requests@2.28.0

From static lists to living SBOMs

A one-time SBOM goes stale the moment a new vulnerability is disclosed. The current best practice is the living, enriched SBOM:

  • Continuously re-evaluate stored SBOMs against new vulnerability intelligence. When a new CVE is published, Dependency-Track or a similar platform automatically identifies every SBOM containing the affected component.
  • Enrich with VEX (Vulnerability Exploitability eXchange) — publish VEX documents that declare whether a listed vulnerability actually affects your product and why (e.g., "Log4Shell: affected function not reachable from network input"). This allows consumers and automation to triage rather than blanket-alert.
  • Manage centrally — an SBOM management platform (Dependency-Track, Anchore Enterprise) automates ingestion, monitoring, and alerting rather than leaving this as a manual spreadsheet process.

SBOM vs SLSA

An SBOM describes what is in your software; SLSA provenance attests to how it was built. They are complementary:

SBOM SLSA Provenance
Answers What components are in this artifact? Who built this, how, and from where?
Format SPDX, CycloneDX SLSA provenance predicate (in-toto)
Primary use Vulnerability management, license compliance Build integrity, tampering detection
Starting point Easier — generate from build or lock files Harder — requires hosted build attestation

Most mature programs need both, but SBOMs are usually the higher-immediate-value starting point.

Common pitfalls and anti-patterns

  • Generating SBOMs but never consuming them — a shelf full of SBOM files that nobody queries during an incident is compliance theater. Build the query capability before the crisis.
  • Flat-list SBOMs (no relationships) — an SBOM without dependency relationships cannot distinguish a direct dependency from a transitive one; priority cannot be set correctly.
  • SBOM format mismatch between producer and consumer — agree on CycloneDX or SPDX across your toolchain. Mixed formats require conversion and introduce data loss risk.
  • No VEX process — publishing SBOMs without VEX means every disclosed CVE triggers alerts for all consumers, even when the vulnerable function is not reachable. This creates noise that erodes trust in the SBOM program.
  • SBOM as a point-in-time PDF — SBOMs that live as PDF reports in a shared drive are not machine-readable, not continuously monitored, and not useful during incident response.

Maturity progression

Starter — Generate CycloneDX SBOMs from lock files using cdxgen or Trivy. Publish alongside release artifacts. Ingest into Dependency-Track for continuous monitoring.

Intermediate — Generate SBOMs at build time (exact resolved dependency graph). Attach as signed attestations in the container registry. Produce SBOMs at multiple layers (source + image). Enable automatic CVE alerting via Dependency-Track.

Advanced — Publish VEX documents for confirmed non-exploitable CVEs. Integrate SBOM queries into incident response runbooks. Track SBOM coverage (% of artifacts with SBOMs) as a KPI. Provide SBOMs to customers and partners on request as part of a documented disclosure process.

Metrics and KPIs

Metric Target
% of release artifacts with attached SBOM 100%
% of SBOMs in a machine-readable standard format 100%
Mean time to identify affected artifacts after CVE disclosure < 1 hour (with automated SBOM monitoring)
% of CVEs with VEX status (exploitable/not-exploitable declared) > 80% for high/critical
SBOM freshness (age at release) < 24 hours

Tools1

Open-source

  • cdxgen - Generates CycloneDX SBOMs for many ecosystems (Node, Python, Java, Go, Ruby, Rust, etc.); best multi-language SBOM generator.
  • GUAC - Aggregates SBOM, provenance, and scorecard data into a queryable graph; enables advanced supply-chain queries across your entire estate.
  • OWASP Dependency-Track - Best-in-class continuous SBOM monitoring platform; ingests SBOMs, tracks components, and alerts on new CVEs automatically.
  • Syft - Generates SBOMs from container images, filesystems, and directories; natural pair with Grype for SBOM-first SCA.
  • Trivy - Produces and scans SBOMs in SPDX and CycloneDX formats; good for teams wanting a single tool across scanning and SBOM generation.

Commercial

  • Anchore Enterprise - SBOM management and supply-chain security at scale; strong policy enforcement and compliance reporting on top of SBOMs.
  • FOSSA - SBOM generation, license compliance, and vulnerability management; particularly strong on license risk analysis for SBOMs.

Links

Footnotes

  1. Listed in alphabetical order. ↩