Send a short, specific statement: the CVE, the product and version, a status of not affected, and a standard justification such as the vulnerable code not being in the execute path. Machine readable VEX formats exist for this. A vague "we are not impacted" invites follow up questions.
What customers want to know
When a CVE makes the news, customers scan their own inventories and your product shows up in a list. They do not want to read an essay. They want to close a ticket. Give them enough to do that confidently.
The four statuses
The OpenVEX specification defines four status values:
- not_affected
- affected
- fixed
- under_investigation
The statement should always name one. If you have not finished checking, say under investigation and give a time you will update. That is more honest than silence and more useful than a guess.
Pick a justification, not just a sentence
For not affected, OpenVEX lists these justifications:
| Justification | Plain meaning |
|---|---|
| component_not_present | The component is not in the product |
| vulnerable_code_not_present | The component is there, the vulnerable code is not |
| vulnerable_code_not_in_execute_path | The code is included but cannot be executed |
| vulnerable_code_cannot_be_controlled_by_adversary | An attacker cannot control the vulnerable code |
| inline_mitigations_already_exist | Built in protections prevent exploitation |
The specification discourages relying on free text alone, because it is not machine readable and breaks automation. Choose a justification from the list and add a sentence of explanation if helpful.
A template you can reuse
Keep customer notices short and consistent:
- Product name and affected version range
- CVE identifier
- Status and justification
- One sentence on how you determined it, and the date
- Contact for questions
- When you will update the statement
Do the work first
A not affected claim is a factual statement customers will rely on. Check it. Confirm the component is or is not in the shipped build, and for the execute path claim, confirm with call path evidence rather than an assumption. If the build differs per platform, check each. Revisit the statement when the product changes, because a later release can reintroduce the code.
Try it yourself
Click through it at your own pace, or open it full screen.
See which findings drop out when reachability is considered, then think about which ones you could back with a not affected statement.
Quick check
Is "not affected" the same as a risk acceptance?
No. Not affected says the vulnerability cannot be exploited in your product. A risk acceptance says it can, and you chose to live with it.
Do we need a special tool to publish this?
No. A consistent written notice works. A VEX file helps customers automate the intake.
Safeguard's reachability analysis and SBOM tooling can supply the evidence behind such a statement; the free scan is at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
