Introduction
A dependency you shipped last quarter didn't change today. Your code didn't change. But a few hours ago a researcher published a CVE for a library sitting three levels deep in your build, and right now that's a live exposure nobody on your team knows about yet. Your scanner will catch it on its next scheduled run, maybe tonight, maybe next week. Attackers saw it the moment the advisory hit the feed.
That gap, between when a vulnerability goes public and when your tooling tells you you're affected, is where a lot of real risk lives. Every trend line is making it wider.
The numbers stopped being on your side
In 2025, 48,185 CVEs were published, more than 20% up from the year before. The U.S. National Vulnerability Database has fallen so far behind that in April 2026 it switched to a triage model and now plans to fully enrich only 15% to 20% of incoming CVEs. The record everyone quietly leans on is bigger and thinner at the same time.
The exploitation window has almost closed, too. The median time from disclosure to exploitation is now counted in days, and a meaningful share of exploited flaws are hit within 24 hours of going public. In some 2025 datasets, attackers were already exploiting bugs before a patch existed.
Most software composition analysis still runs on a schedule. You scan on commit, or nightly, or weekly, and between runs your dependency risk is frozen at whatever the last scan happened to know. The trouble is that your dependencies didn't get more dangerous because you touched them. They got more dangerous because the world learned something new about them, and that can happen at any hour, on nobody's schedule but the researcher's.
Watch the feed, not the calendar
Continuous CVE alerting changes what pulls the trigger. Instead of waiting for the next scan to re-check your dependencies, ZeroPath watches the disclosure feed itself.
An always-on watcher tails OSV's global feed of modified advisories, the running list of everything newly added or changed, about once a minute, across 13 ecosystems including npm, PyPI, Maven, Go, NuGet, RubyGems, and Cargo. When a new advisory lands, it matches the affected version ranges against the SCA inventory ZeroPath already stored from your last scan. No rescan, no waiting on CI, nothing for you to kick off. If a package you already ship falls inside the vulnerable range, that becomes an alert, usually within minutes of the advisory going public.
The idea is simple. We already know what's in your repos. The only new information is the CVE, so that's the only thing we need to react to.
A name match is a lead, not an answer
Plenty of tools can tell you "package X is named in CVE Y." That's a starting point, and it's also the kind of thin, contextless match that buries teams under alerts they never have time to read.
When a fresh CVE lands on a direct dependency, ZeroPath re-runs the same reachability and exploitability agent it uses during a full scan. It clones the repo and reads your actual code. Does anything import the package? Does your code call the specific vulnerable function the advisory describes, or is the package just sitting in a lockfile? Is the risky path reachable in your application at all? The alert shows up already triaged, with a reachability call, an exploitability verdict, a confidence and severity rating, and a plain explanation that points at the line where you use the thing.
We stay honest about the edges. Deep transitive matches get recorded as uninvestigated rather than dressed up with a confidence score we can't stand behind. And when a finding is exploitable and a safe upgrade exists, the alert can arrive with the pull request already attached.
Continuous, without the noise
Continuous anything is only worth having if it doesn't drown you. A few choices keep the signal high.
Cosmetic advisory edits don't re-alert. OSV records get republished all the time for dull reasons: a new reference link, a re-scored CVSS, a reviewer timestamp. ZeroPath hashes only the version-relevant part of each advisory, so you hear about it when the set of affected versions actually changes, not every time someone fixes a footnote.
One advisory becomes one alert. A CVE that hits the same package in twenty places is folded into a single notification instead of twenty.
Alerts are filtered by severity and by whether the issue is genuinely exploitable, then enriched with CISA KEV data on what's being exploited in the wild and FIRST EPSS scores on what's likely to be. Reachable and actively exploited rises to the top; a theoretical bug in code you never call can wait. It's the same reachability-first approach that already cuts SCA alert volume by around 70%, now stretched across time instead of a single scan.
What it means for whoever's reading
If you do security research, this is being early. You hear about a fresh CVE in a target's stack before it surfaces anywhere obvious. If you run AppSec at a company with thousands of dependencies across hundreds of repos, your mean time to know drops from "the next scan" to "the next few minutes," and the triage is already done when you look. And if you're the one who has to answer "are we exposed to the thing in the news?" for a board or an auditor, you can answer in minutes, with evidence, instead of starting a fire drill.
Continuous CVE alerting is opt-in per repository, and you can set it at the tag or organization level too, so you decide what's worth watching. Send the alerts to Slack or a webhook, wire them into an agent playbook if you want automation, and let the triage decide what deserves a person. The dependency you shipped last quarter is still yours to worry about. We just make sure you hear about it the day it starts to matter.
