Supply-chain security talk gets abstract very quickly. Teams jump from a headline about a compromised package to a vague decision that they should probably scan more things. The missing step is inventory: knowing what is actually inside what you ship.
That is what an SBOM gives you. It is not a silver bullet, and it does not magically fix vulnerable dependencies, but it gives you a concrete answer to a question every security team eventually asks under pressure: where are we using this component?
TL;DR
- An SBOM is an inventory of components, not a vulnerability verdict by itself.
- Generate the SBOM as close to the shipped artifact as possible.
- Inventory becomes operational when you pair it with scanning, provenance, and response workflows.
- If you cannot answer where a dependency exists, you cannot respond quickly when a new advisory lands.
| Question | Best tool | Command |
|---|---|---|
| What is inside this image? | Syft | syft my-image:latest -o cyclonedx-json |
| What packages are vulnerable? | Trivy or Grype | trivy image my-image:latest |
| What format should I export? | CycloneDX or SPDX | -o cyclonedx-json |
| How do I respond faster? | Inventory + policy | know what depends on what |
Start here: Start with What an SBOM answers. Once that clicks, the rest of the supply-chain conversation gets much less fuzzy.
What an SBOM answers and what it does not
An SBOM answers the inventory question: what packages, libraries, and components are present in this image or filesystem? That sounds basic, but it is the foundation for almost every serious supply-chain response workflow.
What it does not do is assign business judgement for you. An SBOM does not tell you whether a given CVE is exploitable in your runtime path, whether a package is unused dead weight, or whether a risk should block a release. That still requires policy and context.
Generate the SBOM close to the shipped artifact
The closer the inventory is to the actual release output, the more useful it becomes. That is why generating an SBOM from the image or filesystem you are about to ship is better than generating one from a rough development snapshot.
Syft is a clean place to start because it focuses on SBOM generation, supports multiple output formats, and plays well with downstream vulnerability tooling. In practice that gives teams a concrete artifact they can store, compare, and feed into later policy.
Inventory becomes operational when you pair it with scanning
An SBOM by itself is useful, but it becomes operational when it is paired with a scanner or response workflow. That might be Trivy on the built image, a ticketing rule for critical advisories, or a release review that checks whether a risky component is actually in scope for the shipped path.
This is where supply-chain security becomes pragmatic. You stop arguing in the abstract about dependencies and start answering concrete questions about artifacts, versions, and exposure.
Provenance matters after inventory
Once inventory is in place, provenance becomes the next useful layer. Knowing what is inside an artifact is powerful. Knowing where that artifact came from, what built it, and whether the metadata can be trusted is what turns an SBOM program into a broader supply-chain control set.
If you already think about infrastructure definitions as release artifacts, your post on important Terraform concepts sits nearby conceptually. The shared idea is that shipped infrastructure and shipped software both deserve inventory and traceability.
Example workflow
Syft keeps the inventory step straightforward. Generate the SBOM, then keep it alongside the artifact or feed it into later checks.
# container image
syft my-image:latest -o cyclonedx-json
# directory
syft ./my-project -o cyclonedx-json=./sbom.jsonFAQ
Is an SBOM the same thing as vulnerability scanning?
No. An SBOM is inventory. Vulnerability scanning uses that inventory, plus advisory data, to tell you where known issues exist.
Should I generate the SBOM from source or from the image?
If you ship containers, prefer the image or another artifact very close to release output. That gives you a more trustworthy inventory of what is actually present.
Why do teams skip SBOM work?
Because it feels indirect until the first urgent advisory lands. Once you need to answer where a component exists, inventory stops feeling optional.
Related: DevOps Guide to Important Terraform Concepts is a good companion if you want to treat infrastructure definitions and software artifacts with the same seriousness around change, inventory, and traceability.