Stop Chasing Ghosts: Using VEX to Kill Vulnerability Noise

TLDR: Security teams are drowning in false positives from automated scanners, leading to developer burnout and missed critical bugs. By integrating Software Bill of Materials (SBOM) and Vulnerability Exploitability eXchange (VEX) into a centralized pipeline, you can programmatically filter out non-exploitable vulnerabilities. This approach shifts the focus from raw CVE counts to actual risk, allowing researchers and developers to prioritize what truly matters.

Every security researcher knows the feeling of running a scan against a target and getting back a list of thousands of vulnerabilities. Most of these are noise. They are either unreachable code paths, non-exploitable configurations, or simply incorrect findings. When you hand that list to a development team, you aren't helping them; you are burying them. The industry has spent years pushing for "shift left" security, but we have largely failed to provide the context necessary to make that shift sustainable.

The reality is that more than 25% of the vulnerabilities flagged by standard Software Composition Analysis (SCA) tools are not exploitable or not fixable in the context of the application. When you treat every CVE-2017-20195 with the same urgency, you lose the ability to identify the actual threats. This is where the combination of SBOM and VEX changes the game.

Mapping the Supply Chain

An SBOM is essentially a manifest of every open-source component, library, and dependency in your product. Without it, you are guessing what is running in your environment. However, an inventory is just a list. To make it useful, you need to map those components to specific products and ownership.

The approach demonstrated at Black Hat 2025 involves building a centralized portal that forces developers to register their repositories and artifacts. By doing this, you create a source of truth. When a vulnerability is discovered, you no longer have to scan the entire organization to see if you are affected. You query your inventory. If the component isn't in your SBOM, you can immediately ignore the alert. If it is, you move to the next step: determining if it is actually reachable.

The VEX Advantage

VEX is the missing link in vulnerability management. It is a machine-readable document that communicates the status of a vulnerability in a specific product. Instead of just saying "this component has a vulnerability," VEX allows you to say "this component has a vulnerability, but it is not affected because the vulnerable code path is never called."

The four standard VEX statuses are:

• Not affected: The product is not impacted by the vulnerability.
• Affected: The product is impacted and requires remediation.
• Fixed: The vulnerability has been addressed in a specific version.
• Under investigation: The team is still determining the impact.

By automating the generation of these statements, you can filter out the "Not affected" noise before it ever reaches a human. If a scanner flags a library, but your VEX data shows that the vulnerable function is dead code, the ticket should never be created.

Automating the Triage Pipeline

The most effective way to implement this is to treat your issue tracker, like Jira, as an abstraction layer. You don't want developers manually checking vulnerability databases. You want the security pipeline to do the heavy lifting.

When a scan runs, the system should:

1. Cross-reference the findings against the SBOM.
2. Check for existing VEX statements or reachability data.
3. Automatically close tickets that are marked as "Not affected" or "False positive."
4. Assign actionable tickets to the correct owner based on the repository mapping.

This creates a feedback loop. When a developer marks an issue as "Not affected" because they know the code path is unreachable, that information is captured and stored. The next time that same CVE appears in a different project, the system already knows the context. You are essentially building an institutional memory of your own attack surface.

Why This Matters for Researchers

For those of us doing offensive work, this is a double-edged sword. On one hand, it makes the target harder to compromise because the "easy" vulnerabilities are being cleaned up. On the other hand, it forces us to move beyond simple scanner output. If you are performing a penetration test or hunting for bugs, you can no longer rely on the low-hanging fruit of unpatched dependencies. You have to prove reachability.

If you are looking at a target that uses VEX, you need to understand how they are determining exploitability. Are they using static analysis to prove a code path is unreachable? Are they using dynamic analysis? If you can find a way to trigger that "unreachable" code, you have found a bypass that the automated systems are blind to.

Moving Forward

We need to stop treating vulnerability management as a numbers game. A lower CVE count does not mean a more secure product. It just means you are better at hiding the noise. If you are a founder or a lead, stop forcing your developers to chase ghosts. Build the infrastructure to track your dependencies, automate the triage process, and use VEX to communicate the reality of your risk.

The goal is not to have zero vulnerabilities. The goal is to have zero actionable vulnerabilities that you haven't already addressed. Start by mapping your inventory and stop the flood of tickets that don't actually matter. Your developers will thank you, and your security posture will be significantly more honest.