To report that a product is not affected by a vulnerability, write down why, who decided and when, in a form someone else can check. A Vulnerability Exploitability eXchange document exists for this. A zero findings report without those reasons is a claim, not evidence.
Why this comes up
Component scanners list every package with a known issue, including ones where the vulnerable code is never reached or the affected function is not used. Teams then need to say, to customers or auditors, that these entries do not matter. A bare statement invites doubt. A recorded reason invites checking.
What a VEX is
CISA has published a document describing the minimum elements for creating a VEX document, drawn from existing VEX work and refined by experts from across the security and software sectors. The practical idea is a machine readable statement tying a product, a vulnerability and an exploitability status, so downstream users can filter noise. Read the minimum elements document itself for the exact fields before you build or accept one.
What to record for each not affected decision
- Product and version the statement covers.
- The vulnerability identifier.
- The reason, in plain words: component present but vulnerable code not included, function never called, mitigation in place, and so on.
- Evidence: a reachability result, a configuration, a test.
- Owner, date and review date.
Pitfalls
- Reasons that are really guesses. Mark them as under review until evidenced.
- Statements that outlive the product version they were made for. Tie each to a version.
- Mixing business risk acceptance with technical not affected. They are different decisions: one says the flaw is not present or reachable, the other says you accept a flaw that is.
Use fixed version data carefully
Advisory records express affected ranges with introduced and fixed points, and the OSV schema notes that a version is considered affected if it lies in any listed range or appears in the versions list. Different databases may record ranges differently, so confirm against the source for your ecosystem before you declare a version safe.
Reporting zero honestly
Say: "No open findings for the listed products as of 19 October. Eleven findings are recorded as not affected, each with a reason and review date." Offer the underlying records on request. Avoid language that implies certification or independent attestation unless you have it.
Review cadence
Revisit not affected statements when the product changes, when the dependency changes, and on a set schedule. A reason that was true last quarter may not be true after a refactor.
Safeguard covers the inventory and prioritisation parts of this with SBOM and dependency scanning and reachability analysis, and you can try a free scan at gold.safeguard.sh/scan. Autonomous remediation with fix PRs is off by default, and every category starts on Manual, so a person approves changes.
Quick check
Is not affected the same as accepted risk?
No. Not affected says the flaw is absent or unreachable in your product. Accepted risk says it is present and you tolerate it.
Who should approve a not affected statement?
Someone who understands the product code path, usually a developer, with security review for anything customer facing.
Sources
Last reviewed: 19 October 2026.
