A known unknown is a gap the SBOM author admits to. The NTIA minimum elements say that when the full dependency graph is not listed, the author must say so explicitly, and a reader should treat the data as incomplete. Stating the gap is honest. Silence is the risk.
The idea in plain terms
No tool sees everything. A build may pull in a precompiled binary, a vendored folder of copied code, or a library whose own dependencies are hidden. If the SBOM tool cannot see inside, the honest output is: this component exists, and its contents are unknown.
The NTIA report describes this as part of the depth practice. An SBOM should list primary components with transitive dependencies. Where that is not possible, the author identifies the known unknowns.
Where gaps usually come from
- Closed source components with no dependency data
- Vendored or copied source with no package metadata
- Statically linked libraries in compiled output
- Container layers added by a base image you did not build
- Build steps that fetch things at install time
How an author should document them
For each gap, record the component that has the unknown contents and say that its dependencies were not enumerated. Do not leave the field blank and imply completeness. The NTIA report says that when a component's dependencies are not listed, the default reading of the data should be that it is incomplete, unless the author states otherwise.
How a consumer should read them
Treat each known unknown as a line in your risk register. Ask the supplier:
- Can you provide an SBOM for that component from its own maker?
- If not, can you describe what it does and how it is isolated?
- Is there a plan to close the gap, and when?
Do not reject an SBOM for admitting gaps. An SBOM that claims perfect completeness for a complex product is more suspect than one that names its limits.
Ways to shrink the unknowns
- Prefer components that ship their own SBOM.
- Scan binaries and images, not only source manifests.
- Move vendored code back to package managers when you can.
- Pin base images and generate an SBOM for the image.
Using the information
When a new vulnerability lands, known unknowns are where you cannot answer "are we affected?" from the data. Plan an alternate path for them, such as asking the supplier directly. See how to check a supplier SBOM.
Safeguard's SBOM and dependency scanning, including container image scanning, helps reduce unknowns on your own builds. Try the free scan at https://gold.safeguard.sh/scan.
An example in practice
Suppose a product bundles a precompiled analytics library from a supplier. Your scan lists the library by name and version, but cannot see what it contains. The right record says exactly that. You then ask the supplier for the library's own SBOM, and if none exists, you note the library as a standing risk with an owner. When a new vulnerability is announced in a popular package, you check that entry first, since it is the one place your data cannot answer.
Quick check
Is a known unknown a defect in the SBOM?
No. It is a disclosed limit. The defect is hiding a gap.
Sources
Last reviewed: 19 October 2026.
