SBOMs for Kubernetes
A Software Bill of Materials (SBOM) is a machine-readable inventory of every package, library, and dependency inside a container image. It is generated at build time (often with Syft), stored alongside the image, and consumed downstream for vulnerability scanning, license audits, and supply chain verification. The two widely used formats are SPDX (Linux Foundation) and CycloneDX (OWASP). Both are first-class in the OCI specification as of 2023.
What goes in an SBOM
- Every OS package (deb, rpm, apk) with name, version, architecture, PURL.
- Every language-level dependency (npm, pip, gem, Maven, Go module, Cargo crate).
- Binary artifacts with hashes.
- License metadata.
- Build provenance (build tool, timestamp, builder identity, which is the SLSA framework).
- Optional cryptographic signing for integrity.
SPDX and CycloneDX
SPDX is older, rooted in Linux Foundation license compliance work. Verbose, strong for legal and license use cases.
CycloneDX is OWASP's format, security-first, more compact. Popular with AppSec teams.
Both formats carry essentially the same information for security purposes. Modern tools such as Syft generate either. Pick one per organization. Converting between them is lossless in practice for most fields.
Why SBOMs are becoming a default expectation
- US federal mandate. Executive Order 14028 directs federal agencies to require SBOMs from software vendors.
- EU Cyber Resilience Act. Mandates SBOMs for most connected products sold in the EU, with compliance deadlines landing from 2027 onward.
- Incident response. When a log4shell-scale CVE is disclosed, SBOMs identify in minutes which images are affected.
- Supply chain attacks. The axios compromise and Trivy compromise both benefit from SBOM-level visibility during response.
Generating SBOMs in practice
The common starting point is Syft at build time.
syft packages docker.io/myapp:1.2.3 -o spdx-json > sbom.spdx.jsonIn CI/CD, an ABOM (see ABOM: pipeline bill of materials) captures what tools built the image, not just what ran in it. The Trivy supply chain compromise is one reason teams add ABOMs alongside SBOMs.
Frequently asked about sboms for kubernetes
Who generates the SBOM: the build or the registry?
The build. The registry stores and serves it (current OCI registries support SBOM attachments natively). Registry-generated SBOMs exist but they re-scan after the fact and lose build provenance.
Are SBOMs sensitive?
They reveal your dependency graph, which is a moderate secret. Most teams keep SBOMs internal but accessible to engineering. Public SBOMs (for open-source projects or supply chain transparency) are becoming more common.
Do I need to sign SBOMs?
For high-security environments, yes. Use cosign or Notation. An unsigned SBOM can be tampered with in transit, which is a problem if the SBOM feeds runtime trust decisions (for example "only run images with a passing SBOM-based policy check").
What is the difference between an SBOM and a vulnerability report?
An SBOM lists packages. A vulnerability report lists CVEs. A scanner (Grype, Trivy, Snyk) consumes an SBOM to produce a vulnerability report. Keep SBOMs long-term and rebuild vulnerability reports from them as CVE databases update.
What is an ABOM?
ABOM (Actions Bill of Materials) catalogs your pipeline dependencies: every GitHub Action, runner image, and build tool used to produce an image. The Trivy supply chain compromise made the case for why SBOMs alone are insufficient. More on ABOMs.
See this in your clusters
Juliet maps your Kubernetes security posture as a graph and ranks findings by reachable attack paths, not just CVSS. Free tier, five-minute setup, no credit card.