To tell a customer whether a CVE affects your product, confirm whether the vulnerable component is present, whether your code reaches the vulnerable function, and whether a fix exists. Then reply with a dated status of affected, not affected or under investigation, plus the next step and when you will update.
Why this question arrives fast
When a widely covered flaw appears, enterprise customers forward the advisory and ask one line: are you affected? A slow or vague answer costs trust. A fast, structured one earns it. The trick is to decide the process before the email arrives.
The four step triage
- Presence. Search your dependency inventory for the package and version range named in the advisory. This is why an up to date inventory matters: it turns a day of grepping into a lookup. Check every production repository and container image, not just the main service.
- Reachability. Present does not mean exploitable. Look at whether your code calls the vulnerable function or path, and whether the vulnerable feature is turned on in your configuration.
- Exposure. Is the component reachable from the internet, or only from internal jobs? Note any mitigations already in place.
- Fix path. Is a patched version available, and can you upgrade without breaking something? If not, what is the interim control?
Three honest statuses
| Status | Meaning | What to send |
|---|---|---|
| Not affected | Component absent, or vulnerable code not reachable | The reason in one or two sentences and the date checked |
| Affected | Reachable and exploitable in your setup | Impact summary, interim mitigation, expected fix date |
| Under investigation | You have not finished checking | When the next update will arrive |
CISA describes a Vulnerability Exploitability eXchange document as an attestation, a form of security advisory, that indicates whether a product is affected by known vulnerabilities. You do not need a formal document for every reply, but the same idea applies: state affected or not, and why.
What to put in the reply
Keep it short. Name the advisory, your status, the date and time, the evidence category you used, and the next update time. Do not guess. If you have not finished, say so rather than promising "not affected" to be reassuring.
Mistakes to avoid
- Answering from memory instead of the inventory.
- Saying "not affected" because the package is only a transitive dependency. Transitive packages are still in your build.
- Forgetting container base images and build tools.
- Not following up once you finish the check.
Try it yourself
Open the exploitability check demo and follow how a finding moves from detected to a reasoned status. Look at what evidence supports the final call.
Click through it at your own pace, or open it full screen.
Safeguard's reachability analysis and dependency inventory are built for this triage, and the free scan at https://gold.safeguard.sh/scan shows what a result looks like.
Quick check
How fast should we reply?
Send an initial status the same day if you can, even if it is "under investigation" with a next update time.
Do we need a formal VEX file?
Not for every case. Some customers ask for one, so know the idea, but a clear written status is often enough.
Can we say not affected without testing?
Only if the component is absent or the vulnerable path is clearly not used. Otherwise say it is under investigation.
Sources
Last reviewed: 19 October 2026.
