An SBOM lists the parts inside your software. A vulnerability scan report lists known flaws in those parts. A VEX statement says whether a given flaw actually affects your product. Three documents, three questions: what is in it, what is wrong with it, and does that problem matter here.
TL;DR
- SBOM: the ingredient list. It does not say whether anything is broken.
- Vulnerability scan report: the list of known problems found when the ingredients are checked against public databases. It changes as new problems are found.
- VEX: a short statement from the software maker about whether a specific flaw affects a specific product.
- Customers often ask for the first, receive the second, and really need the third.
Definition. VEX stands for Vulnerability Exploitability eXchange. CISA describes a VEX document as an attestation, a form of security advisory, that indicates whether a product is affected by a known vulnerability or vulnerabilities.
What does an SBOM tell you?
An SBOM answers one question: what is in this software?
CISA calls it a nested inventory, a list of ingredients. The 2026 minimum elements guidance, written by CISA with partner agencies, describes the data in it. That includes the name and version of each component, who produced it, its identifiers, its license, and how the components relate to each other.
What the SBOM does not do is judge. It does not say a component is safe or unsafe. The same guidance puts it directly: "An SBOM alone is data about software components. Analysis of SBOMs transforms data into insights about associated risks."
Think of the ingredient label on a cereal box. It lists wheat, sugar and salt. It does not tell you whether you are allergic to anything. You have to compare it with your own needs.
What does a vulnerability scan report tell you?
A vulnerability scan answers a different question: which of these ingredients have known problems?
A scanner takes your list of components and compares each one with databases of known vulnerabilities. A vulnerability is a flaw in software that an attacker might misuse. Most are tracked with a CVE number, which is a public ID for a specific flaw.
The result is a report. It usually names the component, the flaw, how severe it is rated, and sometimes the version that fixes it.
Two things are worth knowing.
It changes over time. Your software can stay exactly the same while the report gets longer, because researchers find new flaws in old code every day. The 2026 guidance says that after learning new vulnerability information, an organization can check whether its SBOMs contain a vulnerable component. That check is the scan, and it can be repeated whenever the data changes.
It does not know your context. A scanner sees that a flawed component is present. It does not automatically know whether your product ever uses the flawed part. That leads to the third document.
What does a VEX statement tell you?
VEX answers the question the first two cannot: does this flaw matter for this product?
The software maker makes the call and writes it down in a standard format. The CycloneDX project describes VEX as focused on "whether a vulnerability in a component can actually be exploited in its specific context." The OpenVEX specification, one open format, defines four statuses:
| Status | Plain meaning |
|---|---|
not_affected | No action is needed. A reason must be given. |
| affected | Action is recommended to fix or address it. |
| fixed | These product versions contain a fix. |
under_investigation | It is not yet known. Updates will follow. |
For "not affected," OpenVEX requires a justification or an impact statement. The justification labels include component_not_present and vulnerable_code_not_in_execute_path. The second one means the product includes the flawed code but does not run it.
CISA's 2026 guidance says VEX and similar advisories "help avoid unnecessary effort if a trusted source deems that potential risk does not translate to actual risk."
Which document should I send, and when?
Use the question as your guide.
| The reader asks | Best document | Why |
|---|---|---|
| What is in your software? | SBOM | It is the inventory. |
| Do you have known vulnerabilities? | Scan report | It shows today's matches. |
| Our scanner flagged a CVE in your product. Is it real? | VEX statement | It gives your reasoned answer. |
| Did you fix it? | VEX (fixed) or release notes | It ties the fix to versions. |
Here is a simple way to handle a customer request in four steps.
- Send the SBOM first. It is stable for a given release and lets the customer run their own checks.
- Share scan results only on purpose. A raw report is a snapshot and can cause alarm without context.
- Answer each flagged item with a status. Use not affected, affected, fixed or under investigation.
- Update when things change. When you ship a fix, issue a new statement. OpenVEX describes how a product can move from under investigation to fixed over time.
For guidance on what to share, see what to send when a customer asks for your SBOM.
Worked example: one flagged flaw
These numbers are invented to show the flow. They are not from a real product.
A customer's scanner reads your SBOM and reports 40 findings.
| Step | Invented result |
|---|---|
| Findings from the customer's scan | 40 |
| Package present but the vulnerable code is never called | 22 |
| Component fixed in the current release | 6 |
| Still under review | 4 |
| Real, needs a fix | 8 |
You reply with a VEX document. Twenty two items are marked not affected with the reason that the vulnerable code is not in the execute path. Six are marked fixed with the release number. Four are under investigation. Eight are marked affected, with a plan.
The customer now has a clear picture. Instead of 40 unexplained alarms, they see 8 real items and a timeline. The conversation moves from "why is your software full of holes?" to "when will those 8 be fixed?"
Try it yourself
In the demo below, follow how a finding moves from a raw alert to a decision. Look for the point where the tool separates what is present from what needs action.
Click through it at your own pace, or open it full screen.
How can Safeguard help?
Safeguard's SBOM and dependency scanning produces the inventory and exports it in SPDX or CycloneDX. Its vulnerability management compares that inventory with known issues, and reachability analysis shows which flagged packages your code can actually reach. That reachability work is the evidence behind a "not affected" answer.
If a fix exists, autonomous remediation can open a fix pull request for your review. It is off by default and every category starts on Manual. You can start with a free scan at gold.safeguard.sh/scan.
Related reading: VEX statements and SBOM noise and why a clean scan is not proof of safety.
Quick check
Does an SBOM tell me if my software is vulnerable?
Not by itself. An SBOM lists components. A scan compares the list with known vulnerabilities, and a VEX statement says whether a flaw matters for your product.
Why does my scan report change when my code did not?
New flaws are found in existing software all the time. The same list of components can match more known problems tomorrow than it did today.
Who writes a VEX statement?
The maker of the product writes it, because they know whether the flawed code is used. The reader decides how much to trust it.
Sources
- CISA, Software Bill of Materials (SBOM): https://www.cisa.gov/sbom
- CISA and partners, 2026 Minimum Elements for a Software Bill of Materials (SBOM): https://www.cisa.gov/resources-tools/resources/2026-minimum-elements-software-bill-materials-sbom
- OpenVEX Specification: https://github.com/openvex/spec/blob/main/OPENVEX-SPEC.md
- CycloneDX, Vulnerability Exploitability eXchange (VEX): https://cyclonedx.org/capabilities/vex/
Last reviewed: 19 October 2026.
