Kusari Platform now tells you which vulnerabilities can actually be exploited — and writes the VEX
Most CVEs can't actually be reached by your code. Kusari's new AI Analysis Agent reads your codebase and traces each vulnerability so you can fix what matters and prove what doesn't.
Parth Patel
May 5, 2026
Today we're shipping a meaningful upgrade to Kusari Platform's vulnerability analysis. Until now, knowing whether a CVE was actually exploitable in your code meant trusting that an upstream maintainer had published a Vulnerability Exploitability eXchange (VEX) document — and almost none of them do. Our new reachability analysis closes that gap. It investigates each vulnerability against your actual codebase, determines exploitability automatically, and produces a machine-readable VEX you can hand to your own customers and regulators.
Why reachability/exploitability matters
The pace of vulnerability discovery isn’t slowing down. The average codebase has almost 600 known vulnerabilities, an increase of 107% year-over-year. Vulnerabilities are being discovered so fast that the National Vulnerability Database just announced that they’d stop enriching the data for most new vulnerabilities. There are a lot of vulnerabilities out there, and with new tools like Claude Mythos, there will be even more discovered.
But not every vulnerability matters equally. Some are more severe. Some are more widespread in your environment or in more important applications. Critically, some of them don’t actually apply to your code. They are “unreachable” or unexploitable based on the control and usage in your code.
What reachability actually means
Imagine you have an application that imports a library called “doStuff”. Your code calls the “doOneThing()” and “doAThirdThing()” function from that library. One day, a researcher finds a vulnerability in the “doAnotherThing()” function. Most tools will see that you import “doStuff” and say that you’re vulnerable. But you’re not using the “doAnotherThing()” function, so there’s no way that your application ever travels the vulnerable code path. There might be the case where there are mitigating controls already in place that even if the function is called, the vulnerability could never be exploited.
Does this mean you can ignore the vulnerability entirely? Probably not. You’ll still want to address it in case the application needs “doAnotherThing()” in the future. But it should never compete for attention with vulnerabilities that are on a live execution path. Treating those two categories as equivalent is what produces the 4,000-finding triage queues that eat security teams alive.
How our reachability analysis is different
VEX documents are how the industry was supposed to solve this problem. A maintainer publishes a signed statement saying "this CVE doesn't affect this product version, here's why," and downstream consumers can suppress the noise. The catch: almost no one publishes them. If you're waiting on upstream VEX coverage to clean up your queue, you're going to be waiting for a long time.
Kusari's new reachability analysis takes the question back from upstream. The Kusari AI Analysis Agent uses the full context of the Kusari Trust Fabric — your dependency graph, build provenance, function-level call paths, environment signals, and configuration — to investigate each vulnerability directly against your codebase. For every finding, the Agent answers four questions:
- Is the vulnerable package/function actually used?
- Can user input reach the vulnerable code?
- Is this production code or test-only?
- Are there mitigating controls in place?
The output isn't just a verdict. The Agent produces a machine-readable OpenVEX document for every finding — with a justification, an impact statement, and a citation to the code path that led to the determination. You can consume it inside Kusari, route it to your SIEM, or hand it to a downstream customer who's asking the same question about your product.
Here’s an interactive example:
What this changes for security and compliance teams
The most immediate impact is signal quality. When the Analysis Agent sits in front of your remediation queue, the team stops triaging vulnerabilities that don't apply to the application and starts spending its time on the ones that do. Developer hours go further. Mean time to remediation drops. And the perennial argument between security and engineering — "is this actually exploitable?" — moves from a meeting to a citation.
The second impact is on compliance. Regulations like the EU Cyber Resilience Act, with enforcement beginning September 2026, require that products with digital elements ship without known exploitable vulnerabilities — and that vendors disclose exploitability status to their downstream consumers. Without automated VEX, that's a manual obligation generated under audit pressure. With automated VEX, it's a continuous artifact your platform emits as a by-product of normal operation.
Ready to reduce the noise?
If you want to tune out the vulnerabilities that don’t affect you, check out the documentation is at docs.kusari.cloud/reachability. If you're already a Kusari Platform customer, the analysis is enabled on your tenant today. If you're not a customer, schedule a live demo and we'll show you how it works on your repo.
Like what you read? Share it with others.
.png)
.png)
.jpg)
Previous
No older posts
Next
No newer posts
Want to learn more about Kusari?