VEX communicates whether a particular vulnerability affects a particular product. An unaffected statement needs technical reasoning and evidence.
Evaluation approach
Assess component identity, vulnerability identifier, product version and impact status together. Support reasons such as an absent module or unreachable function with evidence.
Application example
When a scanner matches a library, check whether the affected function exists in the final package. Revisit the decision if a later release adds it; do not carry it forward indefinitely.
Limits and considerations
A VEX statement does not remediate a vulnerability. Unsupported unaffected labels only hide warnings.
Checks and decisions
- Identify product versions
- Include technical reasoning
- Set reassessment triggers
RASP alone is not evidence that a product is unaffected. Establish why the specific vulnerability cannot produce the claimed impact.
Sources
The primary references above provide the technical basis. Example workflows and evaluation suggestions are this publication’s explanations, not independent test results for a particular product.