VEX: When Should You Accept not_affected?

A VEX not_affected status asserts that a vulnerability does not affect the products identified in the advisory. Before closing the CVE alert, verify that the deployed product falls within that scope and that the justification describes your situation.

Ask whether this version of the advisory explains why this instance of your product is not affected. Merely establishing that the supplier published a VEX document is insufficient. Keeping the question specific prevents a narrow statement from becoming a permanent exception across an entire software catalog.

Start with the product, then examine the status

Record the product, version, distribution method, and deployed artifact. A commercial name is not always enough to distinguish a hosted service, an appliance, and a locally built container image.

Compare those details with the available SBOM and actual inventory. If the SBOM describes another build, fix the mapping first. Sound technical analysis applied to the wrong product can still produce an incorrect closure.

For each decision, preserve the advisory received, its source, author, and date. A link to a page that will change may not let you reconstruct what was originally stated. Also retain the document's version number or identifier when available.

The CISA minimum requirements for VEX distinguish affected, not affected, fixed, and under investigation statuses. They call for a justification or impact statement for not_affected. This framework describes the information exchanged; the procedure below concerns its technical verification in your environment.

Turn the justification into a testable question

A justification becomes useful when the team knows what evidence to request. “The component is absent” calls for examining the artifact. “The vulnerable code is not used” calls for an analysis of execution paths. Those assertions cannot be verified with the same document.

This table proposes a review method. It does not replace the exact values in the format your supplier uses. Validate the fields and vocabularies before ingesting them.

Do not substitute an operational preference for missing evidence. “The patch is difficult to deploy” explains a scheduling problem. It does not establish that the vulnerability is inapplicable.

A fictional example: the dependency is present, the function is absent

Imagine an internal application called Atelier, distributed in two variants. The server variant includes a library with an optional module affected by a CVE. The minimal variant uses a build that excludes the module. This example is fictional and does not describe a real vulnerability.

The supplier publishes a not_affected advisory for the minimal variant. A dependency scanner still recognizes the library and flags the CVE. Both results can coexist: one identifies a component; the other analyzes its contents within a particular product.

The analyst checks the installed artifact and confirms that it is the minimal variant covered by the advisory. They retain the build reference and evidence that the module was excluded. The closure records those details and the CVE concerned. It does not remove every alert associated with that library.

If the environment uses the server variant, the advisory does not answer the question. If the installed variant remains unknown, the case still needs investigation. Similar version numbers should not be sufficient grounds for applying the exception.

Respect the differences between formats

OpenVEX uses not_affected and justifications such as vulnerable_code_not_present. Its specification connects statements to identified products and vulnerabilities. It also distinguishes protection built into a product from an assumption about its environment.

This matters when a team cites its firewall as the reason a product is not exposed. An external, changeable control needs a local risk assessment and follow-up. It should not automatically become a supplier statement that the product is inherently unaffected.

CycloneDX has its own analysis model, including fields such as state, justification, and response. Its vulnerability exploitability guide describes their roles. Converting between formats must preserve meaning without assuming that every label has a direct equivalent.

Test the connector with a recognized advisory, an incomplete advisory, and a value it does not understand. In the last case, the tool should leave the decision visible to an analyst. Silently dropping an unknown field can turn a limited condition into a blanket exemption.

Put boundaries on the closure decision

Associate the closure with the CVE, product, version or artifact, and advisory version. Add the person or team that accepted the reasoning and the date of the check.

Then define what should reopen the case: a new product version, a configuration change, a revised advisory, or new information contradicting the justification. A status accepted today does not automatically apply to the next update.

Retain the scanner finding and its explanation instead of deleting it. During a technical audit or a handover, the record should show why a known alert did not require the same action as another. This history also helps identify exceptions that no longer apply.

The SBOM guide for security teams helps establish the initial inventory. The supply chain CVE response process then places the advisory within dependency and patch management.

For your next alert accompanied by VEX, request four concrete items: the deployed artifact, applicable advisory, evidence supporting the justification, and condition for review. If one is missing, assign an owner to obtain it and keep the limitation explicit. Close the case once the conclusion has been established for the product concerned.