Greybeam Cuts Its Actionable Vulnerability Queue by 89%
How an AI data infrastructure company went from manually triaging every CVE across Python, Rust, and NPM to a source-built dependency graph with reachability context on all of it — in under a day.
The challenge: which CVEs actually matter
Greybeam builds AI infrastructure tooling — a domain where OSS dependency velocity is high and the cost of a missed vulnerability is amplified by what the platform does. As the codebase scaled, the pile of CVEs flagged across its Python, Rust, and NPM packages grew with it, and a harder question surfaced underneath: how many of those are actually exploitable in production?
Without a connected dependency graph, there was no way to answer that except by hand. Every flagged CVE meant tracing the dependency, finding out what pulled it in, and reasoning about whether the vulnerable code was reachable at all. That is a time sink, and the time came out of shipping.
The approach: a graph built from source, then reachability on top
Greybeam already ran Kusari Inspector in its pull requests and trusted the signal it gave. Expanding to the full Kusari Platform took that from a per-change check to a picture of the whole estate.
Kusari generated source-built SBOMs across every connected repo — capturing not just declared dependencies but the full transitive graph — and layered reachability analysis on top to determine which vulnerabilities had an exploitable call path given Greybeam's actual code. Both matter, and in that order: reachability is only as good as the graph underneath it, which is why Kusari builds that graph from source rather than reverse-engineering it from a finished artifact.
The evaluation ran against live production repositories, not a sandbox. Graph coverage was complete in under 24 hours.
The results: an 89% smaller queue
Within a few weeks of connecting their repositories, Greybeam had:
- A complete, source-built dependency graph across Python, Rust, and NPM
- Reachability context on every flagged CVE, identifying which ones had an exploitable path to running code
- An 89% reduction in the actionable vulnerability queue — traditional scanner output replaced with a focused, prioritized list of real risk
The flagged findings didn't disappear; they got sorted. Security stopped treating every dependency vulnerability equally and could prioritize the issues with reachable code paths.
From PR guardrails to full-estate intelligence
Inspector was already running on every pull request, catching risky dependencies before they merged.
Source-built SBOMs across every connected repo — the full transitive graph, not just declared dependencies.
Reachability analysis determines which flagged CVEs have an exploitable call path given Greybeam's actual code.
What's left is a ranked list of real risk — 89% smaller than the raw scanner output it replaced.
Where Kusari fits in the stack
Kusari is not another scanner. It is the intelligence layer above the tools Greybeam already runs: it maps every direct and transitive dependency across three ecosystems, and tells the team which findings have a path to running code.
We've been using Kusari Inspector for a while and trusted the signal. When we expanded to the full platform, the reachability layer changed the conversation entirely — we went from triaging noise to fixing what was actually exposed. Kusari built our dependency graph on the first day and cut our actionable vulnerability queue by 89%.
— Arsham Eslami, CTO, Greybeam
Want to know what's actually reachable in your own environment? Schedule a demo and speak with one of our founders.