Vex

VEX, or Vulnerability Exploitability eXchange, is a way to state whether a known vulnerability is exploitable in a specific product, build, or deployment. It helps security teams avoid treating every matching CVE as equally urgent and improves prioritisation in software supply chains.

Expanded Definition

VEX, short for Vulnerability Exploitability eXchange, is a structured way to declare whether a known vulnerability is actually exploitable in a specific product, build, or deployment. That distinction matters because a matching CVE does not always mean immediate risk in the context where the software is running.

In practice, VEX sits between vulnerability intelligence and operational triage. It helps security, platform, and supply chain teams separate a theoretical issue from a condition that can be reached in the deployed environment. The emerging industry guidance around VEX is still evolving, so organisations should treat it as a decision-support signal rather than a standalone source of truth. The most common misapplication is treating a VEX statement as a permanent exemption, which occurs when teams ignore version changes, configuration drift, or dependency updates.

For broader identity and resilience alignment, VEX complements governance practices described in the Ultimate Guide to NHIs and maps well to prioritisation principles in the NIST Cybersecurity Framework 2.0.

Examples and Use Cases

Implementing VEX rigorously often introduces governance overhead, requiring organisations to weigh faster vulnerability triage against the cost of maintaining accurate product, build, and deployment context.

• A container image includes a library with a known CVE, but the application path never calls the vulnerable function, so a VEX statement marks it as not exploitable for that build.
• A CI/CD pipeline ingests VEX metadata to suppress low-value alerts and focus remediation on packages that are both present and reachable at runtime.
• A software supplier publishes VEX alongside an SBOM so downstream teams can compare affected components with actual exploitability in their environment.
• An NHI-dependent service uses a third-party agent, and the team checks whether the vulnerable dependency can be reached through the agent’s tool execution path before escalating incident response.
• Security analysts cross-reference a VEX assertion with product telemetry, because a declared non-exploitable state may change after a patch, configuration change, or deployment expansion.

The concept is especially useful when paired with supply chain visibility resources such as the Ultimate Guide to NHIs and standards-driven control thinking from the NIST Cybersecurity Framework 2.0.

Why It Matters in NHI Security

VEX matters in NHI security because service accounts, API keys, and agentic workloads often consume software faster than humans can review it, which makes blanket vulnerability handling noisy and inefficient. When exploitability is not assessed in context, teams either overreact to every CVE or miss the few that truly threaten secrets, tokens, and automation paths.

NHIMG research shows that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, which is why exploitability context cannot be separated from identity governance. The Ultimate Guide to NHIs also reports that 96% of organisations store secrets outside of secrets managers in vulnerable locations, increasing the chance that an apparently low-risk software issue becomes operationally reachable. In a mature programme, VEX helps reduce alert fatigue while improving prioritisation of the software paths most likely to expose NHI credentials.

Organisations typically encounter the operational need for VEX only after a vulnerability scan floods incident queues, at which point exploitability context becomes operationally unavoidable to address.