Reply within a stated window with one organised answer: sort the findings into affected, fixed, not affected and still under investigation, give each a short reason, and attach a machine-readable VEX for the not-affected ones. A scanner report from an SBOM is a starting point, not a verdict.
Why scanner output is not the final word
A scanner matches component names and versions against vulnerability databases. It cannot see how your product uses the component. CISA's minimum requirements for VEX describe VEX as indicating the status of a product or component with respect to a vulnerability, and give a common use case: stating that software is or is not affected. That is the gap you are filling.
Step by step
- Acknowledge and ask for the file. Request the exact list of findings, the SBOM version they scanned and the scanner they used, so you can reproduce it.
- Sort the findings. Use four buckets that match the VEX status values: affected, fixed, not affected, under investigation.
- Write a reason for each not-affected item. The CISA document lists five justification values: component not present, vulnerable code not present, vulnerable code not in execute path, vulnerable code cannot be controlled by adversary, and inline mitigations already exist. Pick the one that fits.
- Give actions for the affected items. CISA says an affected statement must include an action statement, describing how to remediate or mitigate.
- Send both a human summary and a VEX document. The summary is for the person, the VEX is for their tooling.
- Agree on updates. Say how new statements will reach them.
A simple reply layout
| Bucket | What to tell the customer | Evidence |
|---|---|---|
| Affected | Fix version or mitigation, with a date | Action statement |
| Fixed | Release that contains the fix | Release notes |
| Not affected | The justification label and a sentence | Code or build facts |
| Under investigation | Expected date for a decision | Ticket reference |
Tone matters
Do not argue that the customer's scanner is wrong. Scanners are doing what they are built to do. Show your work and let the statuses speak. CISA also notes that under investigation is expected to change once the investigation concludes, so treat it as a promise to come back.
Related reading: how to read a VEX document as a consumer.
Try it yourself
Open the demo and see how findings are grouped and prioritised. Notice how the same list reads differently once you filter by status.
Click through it at your own pace, or open it full screen.
Quick check
Do we have to reply to every single finding?
Reply to all of them as a set, grouped by status. Individual lines can share a reason. CISA allows one statement to cover several products when the status is the same.
Can we send VEX before the customer asks?
Yes. Sending VEX alongside the SBOM often prevents the question.
Safeguard's reachability analysis helps you tell which findings your code can actually reach, and the free scan is a quick way to see a first pass.
Sources
Last reviewed: 19 October 2026.
