Use component_not_present when the library is not in the image, vulnerable_code_not_present when it is built without the affected feature, and vulnerable_code_not_in_execute_path when the code is there but never called. OpenVEX requires one of these labels, or an impact statement, on every not_affected claim.
What OpenVEX requires
The OpenVEX specification defines four status labels: not_affected, affected, fixed and under_investigation. A not_affected status must come with either a machine readable justification label or a free form impact statement. The spec says the free form text is not intended to be machine readable and discourages it for automated systems.
The justification catalog was defined by the VEX Working Group in a July 2022 document and has five labels.
The five labels for embedded work
| Label | Meaning in the spec | Firmware example |
|---|---|---|
| component_not_present | The component is not included | Advisory names a library your image does not contain |
| vulnerable_code_not_present | Component is included, but the vulnerable code was excluded by configuration or build | A protocol feature disabled at compile time |
| vulnerable_code_not_in_execute_path | Code is present but the product does not call it | A parsing function your firmware never invokes |
| vulnerable_code_cannot_be_controlled_by_adversary | An attacker cannot control the vulnerable code | Input only ever comes from a signed, internal source |
| inline_mitigations_already_exist | Built in protections prevent exploitation | A guard the user cannot disable |
The spec itself warns that the last two can be hard to prove conclusively. Treat them as the weakest claims and use them last.
How to choose
- Check presence first. Search the SBOM for the component name and version. If it is absent, you are done, and component_not_present is the cleanest statement.
- Check the build. Look at configuration flags, linker maps and the objects in the final image. If the code was not compiled in, use vulnerable_code_not_present.
- Check the call graph. If it is compiled in, find whether any path reaches the function. For C code, that may mean reading the map file and tracing calls.
- Only then consider the two harder labels, and write the evidence down.
Make the claim reviewable
A VEX statement is a promise to customers. Store the evidence next to it: the config snippet, the map file excerpt, the commit that disabled the feature. Date it. When a later release turns the feature back on, the statement must be revised, so link the statement to a specific product version.
If you do not yet know, say under_investigation. That is an honest status, and the spec expects updates in later documents as knowledge evolves.
Try it yourself
Open the exploitability demo and watch how a finding is judged by whether it can actually be exploited. Compare that thinking with the justification labels above.
Click through it at your own pace, or open it full screen.
Safeguard includes reachability analysis for application dependencies and can help you see which findings matter. Whether a firmware build excludes a feature is evidence your engineers supply.
Quick check
Can I mark not_affected without a reason?
No. The OpenVEX spec requires a justification label or an impact statement for not_affected.
Which label is most reliable for firmware?
component_not_present and vulnerable_code_not_present are easiest to prove, because the SBOM and the build output show them.
Sources
Last reviewed: 19 October 2026.
