An SBOM can support a "not present" answer only if it covers all components including transitive ones, matches the exact version, and was generated with the right context. If any of those fail, the honest answer is "not listed in this SBOM," not "not in the product."
What the guidance promises
CISA's 2026 minimum elements say an SBOM should include all components that make up the target software, including transitive dependencies, with no minimum depth. They add an example: from a vulnerability management view, the recipient should be able to conclude that a newly reported vulnerability does not affect them if the SBOM does not list the component associated with it.
That is the goal. The 2021 NTIA report made a related point, noting that some use cases need complete or mostly complete graphs, such as the ability to prove the negative that a given component is not on an organization's network.
The promise only holds if the SBOM is actually complete.
Five checks before you say "not present"
| Check | Question |
|---|---|
| Version | Is this SBOM for the exact version the customer runs? |
| Generation context | Was it made from source before build, or from the built artifact? Build time additions can be missed from source. |
| Coverage | Does it list transitive dependencies, base image packages and bundled libraries? |
| Unknowns | Are there components with unknown producer or version that could hide the library under another name? |
| Currency | Has anything changed since the SBOM was generated? |
If every answer is solid, you can say the component is not listed and that you have no indication it is present. If any answer is weak, say what you checked and what you did not.
Naming traps
Libraries have more than one name. Alternate names are allowed in the CISA text, and a vulnerability may be filed against a name different from the one in your inventory. A search for one spelling can miss another. Also search by package identifier, not only by display name. The CISA text points to identifiers such as Package URL and CPE for this reason.
Vendored code is another trap. The CISA text notes that copying and pasting code from another project makes it effectively a dependency, better tracked as a fork with a dependency relationship. Untracked copies will not appear in a standard list.
How to word the answer
Use language that matches the evidence.
- Strong: "Library X is not listed in the SBOM for version 4.2, which was generated from the built artifact on this date and includes transitive dependencies."
- Weaker: "Library X is not listed in the SBOM we have. It was generated from source, so we are verifying against the build."
- Wrong: "Library X is definitely not in our product." You cannot know that from a file alone.
Check with a second source
The CISA text suggests that to confirm accuracy and completeness, organizations may use sources such as open source repositories or binary analysis tools to detect components not listed in the SBOM. A cross check against the shipped artifact is the strongest second source.
Try it yourself
Open the demo and look at how direct and indirect components are listed. Search for a transitive entry and notice how easy it is to miss if you only read the top level.
Click through it at your own pace, or open it full screen.
Quick check
If the SBOM is signed, does that prove completeness?
No. A signature shows who made the file and that it was not changed. Completeness is a separate quality.
Should we send VEX saying component not present?
If it is accurate, yes. Component not present is one of the five justification labels CISA lists for a not affected status.
Safeguard's SBOM and dependency scanning can help engineering check what is in a build, and the free scan lets you try it on your own code.
Sources
- 2026 Minimum Elements for a Software Bill of Materials (SBOM), CISA and partners, 29 July 2026
- The Minimum Elements For a Software Bill of Materials (NTIA, 2021)
- Minimum Requirements for Vulnerability Exploitability eXchange (VEX), CISA, April 2023
Last reviewed: 19 October 2026.
