SBOM: Software Bill of Materials
In plain terms#
An SBOM (Software Bill of Materials) is a complete list of ingredients for a piece of software: every component, library, and dependency it contains, with versions. Like the ingredient label on food, it doesn't do anything on its own, but it's the record that makes everything else possible, from vulnerability matching to license compliance.
Why it matters#
When the next Log4Shell-scale vulnerability drops, the first question every organization scrambles to answer is: "are we affected, and where?" Without an SBOM, that's an archeology project across dozens of services. With one, it's a query. SBOMs became a mainstream requirement partly through the US Executive Order 14028 on supply-chain security, and they're now a common procurement ask.
Where it fits#
- Artifact: produced at build time for each release, from source, dependencies, and/or the final container image.
- Stage: generate on build; store it as a release artifact; feed it into vulnerability scanning and share it with downstream consumers.
How it works#
An SBOM generator inspects your project or image, enumerates every component and version, and writes it out in a standard format. The two dominant ones are CycloneDX and SPDX. That document can then be scanned for vulnerabilities (SCA and image scanning are "SBOM + vulnerability match") and archived so you can answer "what was in release 1.4.2?" months later.
Popular & reputable tools#
| Tool | Notes |
|---|---|
| Syft | OSS, from Anchore; generates CycloneDX/SPDX from images and dirs |
| Trivy | OSS; can emit SBOMs as well as scan them |
| cdxgen | OSS; multi-ecosystem CycloneDX generator |
| SPDX tools / CycloneDX | The two standard formats |
Common pitfalls#
- An SBOM you never use is just a file. Its value comes from feeding it into scanning and incident response, not from generating it.
- Accuracy varies by depth. Source-based and image-based SBOMs capture different things; know what yours covers.
- Keep it with the release. An SBOM must correspond to the exact artifact you shipped, generate and store it per release, ideally signed.
config.sbom.enabled: true in your Saga and every scan also inventories each repository and image, CycloneDX JSON by default, SPDX JSON if a procurement or license-compliance process asks for ISO/IEC 5962 by name. Documents are written alongside your other artifacts and delivered by any publisher you have configured. See the Saga reference.It is deliberately not a control. Every control Draugr runs checks something and returns a verdict that decides whether your build passes; an SBOM finds nothing, so it has none to give, and listing it as a control would mean a row that always reads "pass" without ever having looked. It travels as evidence instead, reported, never counted.
config.sbom.scope: project assembles one document for the whole release rather than one per repository and image, which is the unit an SBOM is requested in. And --report vex emits the VEX document that says which of the vulnerabilities in it affect you. What it will do is fail the scan if you asked for an inventory and Draugr could not produce one. Draugr's own release pipeline has published signed SBOMs for its binaries since before this shipped.
Keep learning#
- SCA, scanning the components an SBOM lists
- Container image scanning, SBOM + vulnerability match for images
- VEX, saying which of the vulnerabilities in an SBOM affect you