Stop Chasing CVEs: Focus on What’s Exploitable with VEX

Between 70% and 90% of code in modern enterprise applications is third-party, with open source making up the vast majority of that. If maintaining an accurate inventory, a software bill of materials (SBOM) is challenging enough, add on trying to keep up and patch every single vulnerability reported for these dependencies as quickly as possible.

That’s why AppSec and legal teams need accurate Software Composition Analysis (SCA) and complementary context from VEX – because most of the risk in your application doesn’t come from code you wrote, but from code you integrated.

A common question across product security, legal, and engineering teams is:

“Do we need to act on this CVE or is it not actually a risk in our software?”

VEX, or Vulnerability Exploitability eXchange, helps answer that question. It adds valuable clarity to your source code scans and SBOMs by providing precise context about whether a known vulnerability is exploitable in your product.

What Is VEX?

VEX is a machine-readable format that communicates the exploitability status of known vulnerabilities (typically CVEs) in a given software product. It is designed to complement SBOMs and vulnerability disclosures by clarifying risk based not on theoretical severity, but on actual conditions in your environment.

Each VEX record includes:

• CVE identifier
• Affected component and version
• Exploitability status (i.e. Not Affected, Affected, Fixed, or Under Investigation)
• Justification for the status
• Optional notes on remediation, timelines, or investigation

This structure enables precise, evidence-based security statements that reduce confusion and help teams focus on real risk.

Clarifying “Exploitability”

A common misconception is that VEX simply indicates whether the vulnerable code is present or used. That’s not quite right. That refers to a unique AppSec technique called Vulnerable Snippet Detection.

VEX is about exploitability – whether the conditions that make a vulnerability dangerous are actually met in your product.

A component may be present, and the affected code may even be loaded, but if exploit conditions are absent or mitigated, the vulnerability may pose no meaningful risk. VEX captures and communicates this distinction.

This information allows developers to prioritize their bandwidth addressing true threats.

Common Reasons a Vulnerability May Not Be Exploitable

Understanding why a CVE might be declared Not Affected under VEX is essential for teams managing disclosures. Common mitigating factors include:

1. Dead or Unreachable Code
   The vulnerable function exists in the component but is never invoked in your application. Static analysis or manual code inspection can confirm that the code path is not reachable.
2. Component Not Deployed
   The affected library is included in the source tree but excluded from the final product build. For example, dev-only or test dependencies in embedded firmware are common cases.
3. Disabled Features or Configurations
   The exploitability depends on a runtime feature or setting that is disabled in your deployment. A classic case: a CVE in a web server module that is not enabled in your configuration.
4. Sufficient Mitigations in Place
   The vulnerable behavior is protected by existing controls such as sandboxing, privilege boundaries, memory protections, or input validation layers that neutralize the exploit path.
5. Product Usage Does Not Trigger the Vulnerable Condition
   Your product may include a component with a known vulnerability, but due to its intended use, user interaction, or deployment environment, the exploit path can never be activated.

Why VEX Matters to AppSec Teams

Without VEX, most SBOM-driven vulnerability disclosures lack prioritization. They tell you what is included and what is vulnerable, but not whether it’s actually exploitable in your product. That leads to alert fatigue, unnecessary patch cycles, and slower response times.

With VEX, AppSec teams gain:

• Clarity and focus: Filter out false positives and prioritize vulnerabilities that represent real threats.
• Auditability: Document why specific vulnerabilities were deprioritized, creating a defensible compliance trail.
• Improved cross-team communication: Help legal, product, compliance, and security teams align on what matters – and why.
• More mature disclosures: When combined with SBOMs, VEX shows customers and partners that you understand and manage your software risk proactively.

Real-World Use Cases

Industrial IoT Vendor
A CVE is flagged in zlib. The AppSec team confirms the affected function is part of an optional compression module that is neither included in the final firmware nor enabled in any runtime configuration.

VEX Status: Not Affected

Justification: Vulnerable code is excluded from the deployed binary.

Automotive Supplier
An SBOM shared with an OEM shows multiple third-party components with known CVEs. VEX records clarify:

• 6 CVEs were fixed in recent updates
• 5 are under investigation
• 12 are not exploitable due to runtime configuration or use-case restrictions

This proactively delivered clarity reduces customer friction and builds trust.

How Enterprise Software Teams Can Adopt VEX

1. Understand the Format Options
   VEX is supported in:
   • CycloneDX VEX (JSON or XML)
   • CSAF VEX, used in regulated contexts
   • OpenVEX, a streamlined JSON format for modern pipelines

   Choose a format that aligns with your tooling and distribution needs.

2. Integrate VEX Into SBOM and SCA Workflows
   Advanced SCA tools, like FossID, can help identify whether a vulnerable function is actually present, allowing you to quickly focus your analysis on exploitability.
3. Develop an Internal Governance Model
   Decide who owns the VEX process and how decisions are made. Key considerations:
   • What qualifies as sufficient evidence for a Not Affected status?
   • How often should VEX records be reviewed and updated?
   • Who signs off on VEX statements shared with external parties?

Integrate VEX Into Your Software Risk Assessments

VEX adds crucial context to your vulnerability data. It doesn’t ignore risk – it sharpens your focus by clarifying what is truly actionable. For teams managing large-scale open source adoption, VEX is a practical requirement for scalable security governance.

By implementing VEX alongside SBOMs and accurate SCA tooling, you can reduce noise, demonstrate compliance, and make smarter decisions faster.

Resources

• CycloneDX VEX Specification
• OpenVEX
• CSAF Overview
• FossID Workbench – snippet-level vulnerability detection with high precision for VEX generation

Have questions about integrating VEX into your product security strategy? Contact FossID to learn how we can help you build accurate, defensible, and efficient vulnerability workflows.