Blog
Most of Your CVE Exposure Is in Dependencies You Didn't Choose
A majority of your CVE exposure lives in application dependencies, not the base OS. Not in the packages you chose. In the transitive dependencies that came along for the ride. When it comes to dependencies, Root starts with discovery. We're a secure supply platform that discovers what you actually use, then we fix it.

Mickey Gordon
CPO, Co-Founder
Published :
Feb 19, 2026
Most of Your CVE Exposure Is in Dependencies You Didn't Choose
You can't fix what you can't see. And most organizations don't actually see what they run.
They have requirements.txt files scattered across projects with conflicting versions. package.json dependencies three layers deep. pom.xml files pulling in transitive jars nobody explicitly chose. The result isn't just noise. It's a blind spot: if you don't know what's really in your stack, every remediation strategy is built on guesswork.
A majority of your CVE exposure lives in application dependencies, not the base OS. Not in the packages you chose. In the transitive dependencies that came along for the ride.
When it comes to dependencies, Root starts with discovery. We're a secure supply platform that discovers what you actually use, then we fix it. We fix what you're running. Everyone else makes you change what you're running.
The discovery problem
Security tools are great at giving you a menu. A catalog of everything you might be using and all the ways it might kill you. Then they hand you the rest: discovery, prioritization, triage, and remediation. Your team fills spreadsheets, chases down transitive dependencies, and still can't line up "what we think we use" with "what's running in production."
That gap has a name: the Inventory Illusion.

"Most organizations believe they have a handle on their software inventory. They don't."
Most organizations believe they have a handle on their software inventory. They don't. Your Python projects ship different versions of the same package across different requirements.txt files, and nobody knows which one is actually in production. Your npm package.json pulls in hundreds of transitive packages the developer never chose. Your Java pom.xml resolves dependency trees no one has manually reviewed. Three, four, five levels deep. This leads to organizations mistakenly pulling multiple different versions of the same package, across ecosystems and teams, without anyone noticing.
Discovery isn't a one-time project. It's not an audit you run quarterly. It's the constant and continuous monitoring of what's really in your environment. Without it, every fix is a shot in the dark.
What "actually use" means

We're not talking about theoretical dependency trees or the list of packages you intended to use. We mean what's running in your production environment right now. What your Artifactory serves. What your registries and pipelines pull.
Root connects to the places you already use (your registries, your artifact stores) and discovers that usage automatically. No spreadsheets. No guessing. No "bring your inventory and we'll tell you what's wrong."
We discover what you use. Then we commit to fixing it.

Once we've discovered what you use, the model is simple:
Discovery: We detect what you actually pull. Not what you think you use, not what your manifest says. What's really running. Continuously. This way you don't waste time upgrading packages you don't even use.
Monitor: We continuously scan it for vulnerabilities to keep you secured.
SLA: We give you a contractual commitment to patch new vulnerabilities against those versions. It doesn't matter if a library wasn't in our catalog yesterday. If you use it, we support it.
Fix: When a CVE drops, we don't send an alert and wish you luck. We research the vulnerability, patch it at your pinned version, test it, and deliver a fixed artifact directly to your repos and registries, often in 15–40 minutes from detection. Drop-in. No forced upgrades. No breaking changes.
That's the cycle. That's the product. Patches not PDFs. We discover what you use and we fix it, at the versions you run, in the places you already work. For libraries, Root Library Catalog covers direct and transitive dependencies, with SLA-backed fix rates and Critical/High vulnerabilities and CISA KEV priority.
Why it matters

We detect what you actually pull, so you're never wasting time upgrading packages you don't use. We continuously scan it for vulnerabilities. We put it under SLA. We patch. We deliver.
Root covers the dependencies you didn't choose, across npm, PyPI, and Maven, with an SLA. We fix it in place, so you can move toward zero effective vulnerabilities without changing your stack.
No migrations. Just fixes. No rip-and-replace. No "upgrade to our stack or stay vulnerable." Discovery that matches reality, and fixes that match what you actually use. This isn't a tool. It's a commitment.
See the product in action: discovery, SLA-backed fixes at your versions, and delivery to your repos and registries. Book a demo to learn more.
Continue Reading










