Software Bills of Materials (SBOMs) became compliance-required after high-profile supply chain attacks. The risk is treating them as a checkbox: generate, file, forget. The value comes from connecting SBOMs to vulnerability feeds and gating deploys.
Two formats: SPDX vs CycloneDX
SPDX (Linux Foundation): broad metadata, compliance-focused. CycloneDX (OWASP): security-focused, more vulnerability-ready. Most tools emit both. Pick CycloneDX if you have to pick one.
Generation in CI
Syft, Trivy, cdxgen scan a built artifact and emit SBOM. Run on every build. Sign the SBOM (cosign attestation) alongside the image. Attach to the registry as a referrer.
Connecting to vuln data
Feed SBOM into Grype, Trivy, or Snyk for CVE matching. The valuable output: 'this deploy contains CVE-2025-X with known exploit'. Block deploys on critical CVEs (with override for documented mitigations).
Provenance with SLSA
SLSA (Supply-chain Levels for Software Artifacts) defines build provenance: who built this, from what source, with what builder. SLSA 3 requires hardened builders (GitHub Actions reusable workflows, Buildkite signed steps). Pair with SBOM for full picture.
Don't drown in noise
A modern app has thousands of transitive deps. Default vuln scans return hundreds of 'criticals'. Filter to reachable code (using tools like Endor Labs, Mend) — most CVEs are in unreached paths. Otherwise teams ignore the report.