Rank supplier SBOM findings by four questions you can answer without source code: is it exploited in the wild, has the supplier said it is not affected, is the affected product exposed in your environment, and is a fix available. Work the top of that ranking and ask the supplier about the rest.
The problem
A supplier SBOM can produce hundreds of matches. You cannot run reachability analysis on code you do not have. Sorting only by severity score will bury the items that matter and flood the supplier with questions.
A four step ranking
- Exploitation evidence. CISA's Known Exploited Vulnerabilities catalog lists CVEs with reliable evidence of active exploitation and a clear remediation step. CISA tells organizations to treat it as an input to prioritization. Matches in KEV go first.
- Supplier statements. If the supplier published VEX, apply it. OpenVEX defines four statuses: not affected, affected, fixed and under investigation. A not affected statement needs a justification or an impact statement. Treat statements as claims you can challenge, but they cut your list sharply.
- Exposure in your setting. Is the product reachable from the internet, does it handle untrusted input, does it hold sensitive data? A flaw in an internal batch tool ranks below the same flaw in an edge gateway.
- Fix availability. A supplier release that fixes the issue gives you a clear action. If none exists, you need a mitigation or a timeline.
Put it in a table
| Priority | Condition | Action |
|---|---|---|
| 1 | In KEV, product exposed, supplier says affected or silent | Escalate to supplier, apply mitigation now |
| 2 | In KEV, internal product | Ask for fix date, add compensating control |
| 3 | Not in KEV, exposed, no supplier statement | Request VEX status |
| 4 | Supplier says not affected with justification | Spot check, record, close |
| 5 | Everything else | Batch for next review |
What to ask the supplier
Keep questions narrow. Send the product, release, component, advisory and the one thing you need: status, fix date or justification. A tight list of ten gets answered. A spreadsheet of three hundred does not.
Use compensating controls while you wait
Network segmentation, disabling an unused feature, a web application firewall rule or tighter credentials can cut risk before the fix arrives. Record each control with the finding it covers and an expiry date.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at how knowing whether a flaw can be exercised changes what you do next.
Where Safeguard fits
For code you own, Safeguard applies reachability analysis to SBOM and dependency findings, and it can open fix pull requests (off by default, every category on Manual). You can start with a free scan.
Quick check
Is a high severity score enough to rank a finding?
No. Add exploitation evidence, exposure and fix availability.
Should I accept a supplier's not affected claim?
Accept it as a claim with a justification, spot check a sample, and keep the record.
Sources
- CISA KEV catalog: criteria and recommended use.
- OpenVEX specification: statuses and justification requirement.
Last reviewed: 19 October 2026.
