Triage every finding, sort it into affected, not affected, fixed or under investigation, and reply with a short VEX document that says which, with a reason for each not affected claim. Do not send a blanket denial. A list with a status per item and a date is what the customer can act on.
Why this happens
Customers feed your SBOM to a scanner. The scanner matches component names and versions to advisories and reports everything. It cannot tell whether the code is reachable or whether you have already mitigated it. Many findings will be noise, and some will be real.
Steps
- Acknowledge within a day, and say when you will reply in full.
- Deduplicate. The same advisory often appears several times through different paths.
- Check each unique finding against your product. Is the component really in the shipped build? Is the vulnerable function used?
- Assign a status from the OpenVEX set.
- Write the reply as a VEX document, plus a short cover note.
- Update your own tracking so the next request is faster.
The four statuses
| Status | Meaning | What you must add |
|---|---|---|
| not_affected | The product is not exposed | A justification, an impact statement, or both |
| affected | The product is exposed | A remediation or mitigation action |
| fixed | A release resolves it | The fixed version |
| under_investigation | You are still checking | A date for your next update |
The OpenVEX specification lists five justification values for not affected: component not present, vulnerable code not present, vulnerable code not in execute path, vulnerable code cannot be controlled by an adversary, and inline mitigations already exist. It recommends the machine readable justification, with the free text impact statement as optional.
Be careful with not affected
A not affected claim must be true and checkable. If you claim the vulnerable code is not in the execute path, you should be able to show how you know. If you cannot, use under investigation and say so. Customers lose trust when a not affected is later reversed.
Match to components
Identify each statement's product and component with a package URL where you can. The spec recommends purls as identifiers. If your SBOM has no purls, matching your statement to their scanner results will be manual for them.
Try it yourself
Click through it at your own pace, or open it full screen.
Try deciding whether a finding is exploitable in context. That is the judgment behind each VEX status you send.
Quick check
Do I have to answer every scanner finding?
Answer every unique advisory that matches a component in your SBOM. A VEX document lets you do it compactly.
Can I just say we are not vulnerable?
Not usefully. Give a status and a reason per advisory, and a date.
Safeguard's reachability analysis and SBOM scanning help establish whether a vulnerable function is used, and a free scan is available at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
