DevSecOps Practice Hub

Software Bill of Materials

Generate and publish a machine-readable inventory of every component shipped in a release.

IntermediateSBOMSupply Chain

Where it fits in the lifecycle

  1. Plan
  2. Code
  3. Build
  4. Test
  5. Release
  6. Deploy
  7. Operate
  8. Monitor
  • Build Dependency scanning, image scanning, SBOM generation and signing.
  • Release Approval controls, artefact promotion and provenance.

Overview

An SBOM lists components, versions and relationships for an artefact, in a standard format such as SPDX or CycloneDX. It is generated at build time and stored alongside the artefact it describes.

Why it matters

When a new advisory lands, the question is which releases contain the affected component. Without an SBOM per artefact, that answer takes days instead of minutes.

How it works

  1. 01A generator inspects the built artefact or image layers.
  2. 02Components are recorded with purls, versions, licences and relationships.
  3. 03The document is attached to the release or attested alongside the image.
  4. 04Consumers re-scan stored SBOMs when new advisories are published.

Common tools

SyftTrivycdxgenSPDXCycloneDXDockerGitHub

Implementation examples

bashGenerate a CycloneDX SBOM
syft $IMAGE_NAME -o cyclonedx-json=sbom.cdx.json
Produces an SBOM from the built image rather than from source.
bashAttach the SBOM as an attestation
cosign attest --predicate sbom.cdx.json \  --type cyclonedx $IMAGE_DIGEST
Signed attestations let downstream consumers verify the SBOM actually belongs to that image digest.

Best practices

  • Generate SBOMs from the built artefact, not from the source tree.
  • Store SBOMs immutably with the artefact digest as the key.
  • Re-scan stored SBOMs on a schedule rather than only at build time.

Common mistakes

  • Producing an SBOM and never consuming it.
  • Generating from source and missing OS-level packages in the image.

Hands-on labs

Learning resources