An SBOM reflects the moment it was captured. A source SBOM comes from manifests before a build, a build SBOM from the build itself, and a post-build or deployed one from the finished artifact. Each answers different questions, so find out which you have before relying on it.
Why the stage changes the answer
Two SBOMs for the same product can differ because one was made from the manifest files in the repository and the other by inspecting the final container image. The first may list libraries that were never shipped. The second may include operating system packages the developers never chose.
Neither is wrong. They describe different things. The NTIA minimum elements report notes that knowing how the data was captured, with examples of "source," "build," or "post-build," helps consumption and data management.
What CycloneDX calls the stages
CycloneDX 1.6 has a lifecycles field in the metadata for exactly this. The reference defines these phases:
| Phase | What the spec says |
|---|---|
| design | Early inventory of components proposed or planned |
| pre-build | Information from before a build, such as source files and manifests; versions may need resolving |
| build | Information from during the build; precise resolved versions and provenance are usually available |
| post-build | Information from after the build, on built components that may be deployed |
| operations | Inventory of what is running, possibly across staging or production |
| discovery | Information observed through network discovery |
If the field is present, read it first. If it is absent, you have to infer the stage from the content.
How to infer the stage
Look for these clues:
- Lock file versions only, no OS packages. Likely pre-build or build, from language manifests.
- Exact versions with hashes and source locations. Likely build, where resolved versions are known.
- OS packages, base image layers, and installed binaries. Likely post-build, from scanning the artifact.
- Host names, running services, or environment details. Likely operations.
- A tool name in the metadata. Many tools have a typical mode. Check the tool's documentation.
If you cannot tell, ask the sender directly. It is a fair question and takes one line to answer.
What each stage can answer
| Question | Source or pre-build | Build | Post-build or deployed |
|---|---|---|---|
| What did developers choose to depend on? | Best | Good | Partial |
| Which exact versions were resolved? | Weak | Best | Good |
| Is a vulnerable library in the artifact I run? | Weak | Good | Best |
| Does the base operating system add risk? | No | Partial | Yes |
For vulnerability exposure in what you actually run, the post-build view is closest to reality. For understanding developer choices and planning upgrades, the source view is cleaner.
Mismatch checks
If a vendor sends one SBOM, compare it with what you can observe. If you can scan the delivered container or package yourself, do it, and see whether the component counts are in the same range. A big gap suggests the SBOM is source level while you deployed a larger artifact, or the reverse.
You can also ask for more than one. Many suppliers can produce a build time SBOM and a post-build one from the same pipeline.
Where Safeguard fits
Safeguard provides SBOM and dependency scanning, so you can scan the artifact you received and compare it with the supplier's file. A free scan is at gold.safeguard.sh/scan.
Quick check
Which SBOM type is best?
None is best for every question. Pick by the question: developer choices, resolved versions, or what is running.
What if the file has no lifecycle information?
Infer it from the content and ask the supplier to confirm. Record the answer next to the file so the next reader does not repeat the work.
Sources
- CycloneDX 1.6 JSON reference
- The Minimum Elements for an SBOM, NTIA
- Types of Software Bill of Materials (SBOM), CISA
Last reviewed: 19 October 2026.
