SBOM completeness
SBOM completeness is whether an SBOM lists every component that went into the software it describes, at every depth, not just whether the file is valid.
Last updated: November 11, 2026
An SBOM is complete when it lists every component that went into the software it describes, at every depth of the dependency tree, including components that no lockfile or manifest lists. SBOM completeness is that property. CISA's 2026 Minimum Elements ask SBOM authors to state explicitly when information is unknown, and note that recipients may consider an SBOM incomplete if essential component data is withheld.
Completeness, validity and quality are different
| Question | What it means | What checks it | What it cannot tell you |
|---|---|---|---|
| Valid | The file conforms to the CycloneDX or SPDX schema | A schema validator | Whether components are missing |
| Field quality | Each component has a name, version, supplier, identifier, license and hash | A quality scorer | Whether components are missing |
| Complete | Nothing that went into the software is missing | A comparison with what the build actually took in | Inputs the comparison did not see |
The identifier in the second row is usually a package URL or a CPE. A file can pass the first two checks perfectly and still leave half the software out.
Why completeness is hard to measure afterwards
A scanner works from lockfiles, manifests or the finished output. It cannot know about a package that a post-install script downloaded, a crate compiled into a binary, or a base image layer it was never shown. Each of those is a hidden dependency.
Take a Node.js service whose lockfile lists 400 packages. One of them has a postinstall script that downloads a prebuilt binary during npm ci. An SBOM generated from package-lock.json is valid, every component has a version and a package URL, and the binary is not in it. No quality score will flag that, because nothing in the file points to what is missing.
Rebuilding later does not settle the question either: unless the build is a reproducible build, a second build can take in something different from the first.
How to report completeness honestly
- State the generation context: whether the SBOM was made from the source before the build, recorded during it, or produced by analyzing the output afterwards.
- List known gaps: parts of the software the tool could not see, such as vendored code, prebuilt binaries or components installed outside a package manager.
- Prefer a state with reasons over a score. A percentage of completeness needs a total, and the total is exactly what nobody knows. A statement such as "incomplete: the job allowed unmonitored traffic" can be acted on.
SBOM best practices covers the wider practice of saying what an SBOM could not see.
Completeness states in CRACI
CRACI gives each job's SBOM a completeness state, and caches get one too. The states, as CRACI's documentation defines them:
- Complete: "CRACI observed complete job evidence, and every restored cache was complete."
- Complete with connections: "The requirements passed, but the job used one or more custom network connections."
- Incomplete: "CRACI identified a condition that could leave dependencies out of the SBOM."
- Unavailable: "CRACI could not finish evaluating the evidence."
- Not recorded: "The job predates completeness reporting."
CRACI can state this because it sees each job's traffic to package sources, so it knows when something could have gone around it: traffic it did not monitor, or a restored cache whose own SBOM was incomplete. When a job is incomplete, the job shows the reason, for example "Unmonitored traffic was allowed". See SBOM generation.
These states apply to builds that run on CRACI runners. For an SBOM from a supplier, or from a pipeline that does not run on CRACI, use the comparisons and the reporting rules above.