Treat vulnerability data embedded in a supplier SBOM as a dated claim, not a current verdict. Read it for the supplier's assessment, then rematch the component list against your own advisory sources today, because advisories change after the file was written.
Two different things can travel in one file
An SBOM can list components only, or it can also carry vulnerability records. CycloneDX, for example, lets a BOM hold vulnerability entries that point at components through a reference. The component list is a fact about composition. The vulnerability entries are an opinion about risk at the moment of writing, and that opinion ages.
What the embedded data is good for
- It shows what the supplier already knows and has triaged.
- It may carry a status and a reason, which saves you a round of questions.
- It gives you something to compare with your own scan.
Where it falls short
- Age. New advisories appear daily. A file from last quarter cannot mention them.
- Source. You do not know which databases the supplier used.
- Scope. The supplier may have assessed their build, not the way you deploy it.
- Incentive. A supplier reporting on its own product may leave things out, innocently or not.
A simple handling rule
- Always run your own match on the component list.
- Load the supplier's statements as a separate layer, labeled with author and date.
- Where the two agree, accept and move on.
- Where the supplier says a component is not affected but your match says it is, ask for the justification. OpenVEX, for instance, expects a justification or an impact statement for not affected, with values such as the vulnerable code not being in the execute path.
- Where the supplier lists an issue you did not find, check whether your data source has a gap.
- Store both layers so a later audit can see what each party said.
Recording the disagreement
| Situation | Action |
|---|---|
| Supplier says affected, you agree | Plan the fix, ask for a date |
| Supplier says not affected, you disagree | Request justification, keep finding open |
| Supplier silent, you find an issue | Send the advisory and ask for status |
| Supplier lists issue, you find nothing | Verify your source, then close |
Try it yourself
Click through it at your own pace, or open it full screen.
Compare how a vulnerability looks before and after the exploitability question is answered.
Where Safeguard fits
Safeguard scans SBOMs and dependencies and applies reachability analysis, which gives you an independent view to hold next to a supplier's statements. Start with a free scan if you want a second opinion on a file.
Quick check
Can I skip scanning if the SBOM already lists vulnerabilities?
No. The embedded list is a snapshot. Rematch against current data.
Who is responsible for a vulnerability the supplier marked not affected?
You still own your risk decision. Ask for the justification and keep the record.
Sources
- CycloneDX 1.6 JSON reference: BOM structure and component references.
- OpenVEX specification: statuses and justifications.
Last reviewed: 19 October 2026.
