Acknowledge the report the same day, verify whether the finding is real in your product, then reply with one of three answers: affected with a fix date, not affected with the reason, or cannot tell yet with a date you will know. Back "not affected" claims with evidence, ideally a VEX statement.
Why these reports arrive
Customers run scanners against installed software, container images, or exposed endpoints and forward the output. Many items will be false alarms: a version string that matches an advisory although the fix was backported, or a library present but never called. Some will be real. You cannot tell which without checking.
Step by step
- Acknowledge quickly. One sentence: you received it, who owns it, when they will hear back.
- Reproduce the match. Find the component and version behind the finding in your own SBOM. If it is not there, ask what the scanner looked at.
- Check the advisory. Is your version in the affected range? Distributions often backport fixes without changing the upstream version number. Debian's security FAQ explains that fixes are backported to the shipped version instead of upgrading, so a version string can mislead a naive matcher.
- Check usage. Is the vulnerable code present and reachable in how your product runs it?
- Decide the answer using the table below.
- Reply with evidence, not reassurance.
Pick the right answer
| Finding | Reply | Attach |
|---|---|---|
| Affected, fix planned | Say so, give a target date and any workaround | Advisory link, release plan |
| Affected, fix shipped | Point to the version that contains it | Release notes |
| Not affected, code absent or unreachable | Say why in two sentences | A VEX statement with a justification |
| Not affected, fix backported | Name the package version that includes the fix | Distribution advisory entry |
| Unknown | Say what you are checking and when you will report back | Nothing yet |
CISA publishes minimum requirements for VEX documents, which are a machine readable way to say that a product is or is not affected by a given vulnerability.
What not to say
Avoid "we are not affected" without a reason. Avoid "false positive" as a dismissal, since the customer may read it as defensiveness. Avoid promising a fix date you cannot meet. If the answer depends on your supply chain, say that you are waiting on an upstream fix.
Keep a reusable pack
Teams that answer these often keep a short pack ready: current SBOM, recent VEX statements, a summary of how vulnerabilities are handled, and the contact for security questions. It shortens each reply.
Try it yourself
Open the demo and look at how a dependency inventory lists components and versions. That inventory is the first thing you need when a scan report lands.
Click through it at your own pace, or open it full screen.
Quick check
How fast should we reply to a customer scan report?
Acknowledge the same day if you can. Give the full answer once verified, and say when it will arrive if that takes longer.
Is a VEX statement required?
No, but it gives a clear, structured way to say not affected and why, and it saves repeat questions.
Sources
Last reviewed: 19 October 2026.
