State that the product is not affected, give the specific reason, name the versions you checked, and date the statement. OpenVEX takes the same approach: a not_affected statement must include a justification, an impact statement, or both. A bare "we are not affected" invites follow-up questions.
Why a reason matters
When a well known library issue makes the news, customers ask whether you ship it. "No impact" with no explanation sounds like a template. A reason shows you looked.
Reasons also let customers verify. If you say the vulnerable function is never called, a technical reader can ask how you know. That is a good conversation to have.
What OpenVEX says
OpenVEX statements use a fixed set of statuses: not_affected, affected, fixed and under_investigation. A not_affected statement must include a justification label, a free text impact statement, or both. The spec notes that the free text is not meant to be machine readable and its use is discouraged for automated systems. Affected statements must include an action statement describing remediation or mitigation. A document must carry a timestamp for when it was issued.
You do not need to publish OpenVEX to borrow the discipline.
A reason table for customer notes
| Situation | Plain wording |
|---|---|
| You do not ship the component | "The affected library is not part of any release of this product." |
| You ship it but never call the affected code | "The product includes the library, but the vulnerable function is not called by our code." |
| A condition for exploitation is absent | "The flaw needs a setting we do not enable, and cannot be enabled by users." |
| You are still checking | "We are investigating and will update by a stated time." |
The last row matters. Saying "investigating" is honest, and it maps to the under_investigation status.
Steps
- Check the dependency tree of every supported release, including transitive dependencies.
- Record the exact versions checked.
- Decide the reason category from the table.
- Have an engineer confirm the reasoning, not just the component list.
- Write the note in two or three sentences and date it.
- Add a line saying you will update it if circumstances change, and do so.
Example note
"We reviewed the recent issue in the parsing library. Releases 5.0 to 5.3 of our product include the library but do not call the affected function, and we have no configuration that enables it. As of this date we consider the product not affected. We will update this note if that changes."
Mistakes to avoid
- Claiming "not affected" from a scan that only checks direct dependencies.
- Skipping the date.
- Saying "not vulnerable" when you mean "not exploitable in our configuration". Those are different claims.
- Forgetting older supported releases.
Try it yourself
Click through it at your own pace, or open it full screen. Look for how direct and transitive dependencies appear in one inventory.
Quick check
Is a free text reason enough?
For a customer note, yes. For automation, a machine readable justification label is better, because OpenVEX discourages relying on free text for automated systems.
Should I say not affected before I have finished checking?
No. Use "under investigation" and give a time for the next update.
Safeguard's SBOM and dependency scanning and reachability analysis help teams back a not affected statement with evidence. Try the free scan at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
