SBOM - the software bill of materials

Security (DevSecOps) · Vulnerability scanning with Trivy in the pipeline · Lesson 5 of 5

An SBOM lists every package and version inside a piece of software in the CycloneDX or SPDX standard; generate it at build time, keep it with the artifact and rescan it when new CVEs appear without rebuilding.

What an SBOM is

An SBOM (Software Bill of Materials) is like the ingredient list on packaging: it lists every component of the software, including name, version, supplier, licence, hash and dependency relationships. When a major vulnerability such as Log4Shell appears, an organisation with SBOMs can answer "are we running log4j 2.14 anywhere?" in minutes.

Regulations increasingly require SBOMs, for example the 2021 US cybersecurity executive order for software sold to government and the EU Cyber Resilience Act.

Two common standards

Standard	Maintainer	Notes
CycloneDX	OWASP	Security-focused, supports VEX, JSON or XML
SPDX	Linux Foundation	Strong on licences, the ISO/IEC 5962 standard

Each component is usually identified by a purl (package URL), for example pkg:npm/express@4.19.2 or pkg:deb/debian/openssl@3.0.11.

Generating and using SBOMs

trivy image --format cyclonedx --output sbom.cdx.json example-org/myapp:1.0
trivy fs --format spdx-json --output sbom.spdx.json .
trivy sbom sbom.cdx.json                      # rescan an SBOM for CVEs
syft example-org/myapp:1.0 -o cyclonedx-json  # an alternative tool: Syft
grype sbom:./sbom.cdx.json                    # scan an SBOM with Grype

flowchart LR
  B["Build image"] --> G["Generate SBOM"]
  G --> A["Store with the artifact<br/>(registry attestation)"]
  A --> S["Rescan regularly<br/>trivy sbom"]
  S --> AL["Alert on new CVEs"]

A big benefit: scanning an SBOM is faster than scanning an image because no layers are downloaded or unpacked, so you can rescan your whole software estate daily.

VEX

VEX (Vulnerability Exploitability eXchange) is a companion document stating whether a CVE affects the product, for example "not_affected: the vulnerable code is never called". Trivy reads VEX with --vex to filter out irrelevant findings.

Good practice

Generate SBOMs in the pipeline from the exact artifact being released, not from a dev machine.
Attach the SBOM to the image as a signed attestation (see cosign in a later module).
Store them centrally in a tool such as Dependency-Track for search and tracking.
An SBOM is only valuable if it is kept current and actually scanned.

Traps: generating an SBOM from source and assuming it describes the image (the image also has OS packages); storing SBOMs nobody scans; confusing an SBOM with a vulnerability report.