Tell customers that an SBOM is an inventory of components. It does not show whether a vulnerability can be exploited, whether the list is complete without checking, or what you plan to fix. Pair it with VEX or advisories for status, and with a way to report errors, so the limits do not become surprises.
What an SBOM is
CISA's 2026 minimum elements guidance describes an SBOM as a nested inventory, a list of ingredients that make up software. It says SBOMs capture component data in a machine-processable format so organizations can analyze, share, and manage it. It also states plainly that SBOMs will not resolve all software security and supply chain concerns, but are a necessary step for risk-informed decisions.
What it does not show
| Customer assumption | Reality |
|---|---|
| "No components with known issues means safe" | The SBOM lists components. Risk needs matching against advisories |
| "Every listed issue is exploitable" | Presence is not exploitability. VEX statements address that |
| "The list is perfect" | Accuracy and completeness depend on tools and process. CISA says organizations may use other sources, such as binary analysis tools, to detect components missing from an SBOM |
| "It shows your whole security posture" | It covers components, not controls, testing, or response |
| "It never changes" | Each release or correction produces a new one |
Why the gap matters
A customer who scans your SBOM will often find known vulnerabilities in listed components. Many will not affect your product, because the vulnerable code is not used or is not reachable. If you did not warn the customer, the first reaction may be alarm. A short note on the page, plus a VEX channel, prevents that.
CISA's guidance on correlating SBOMs with advisories explains the value: advisories such as VEX and CSAF communicate the status of a component, including where a producer is working on a fix, and can help avoid unnecessary effort when a trusted source judges that potential risk does not translate to actual risk.
Put limits in plain words
Add a short block next to the download:
- What the file contains: components, versions, identifiers, relationships.
- What it does not contain: exploitability, fix plans, configuration.
- How current it is: release and timestamp.
- How to ask a question or report an error.
- Where status statements live.
The guidance expects authors to correct errors promptly and to have a process for recipients to ask about redacted, security-related information. Include both in the block.
Say what is unknown
CISA asks SBOM authors to state explicitly whether missing data is unknown or withheld, not leave it blank, and says organizations may consider an SBOM incomplete if essential component data is withheld. Name your gaps. A short list of known unknowns is more credible than silence.
Link the other half
Point to your advisories and VEX statements from the same place. See how to link an SBOM, VEX, and advisories from one page.
Try it yourself
Click through it at your own pace, or open it full screen.
See how many listed findings turn out not to be reachable. That is the context an SBOM alone cannot give.
Where Safeguard fits
Safeguard's reachability analysis helps separate findings that matter from those that do not, and its SBOM and dependency scanning supplies the inventory. Try a free scan at gold.safeguard.sh/scan.
Quick check
Does a long vulnerability list in my SBOM scan mean I am unsafe?
Not by itself. Check which listed components are used and reachable, and publish status statements for the ones that matter.
Should I hide unknown fields?
No. State that the value is unknown or withheld, as CISA's guidance asks.
Sources
Last reviewed: 19 October 2026.
