DepOversight · Blog

Why CVE scanners are not early-warning systems

CVE scanners are good at one job, telling you which dependencies match a published advisory. That job ends where the most expensive incidents begin.

Published 2026-05-08 · 3 min read

Tags: cve, vulnerability-management, supply-chain

A modern CVE scanner, Dependabot, Snyk, GitHub Advanced Security, Trivy, Grype, Mend, is a database lookup. You give it your dependency graph; it gives you back the rows in a vulnerability database that match. The database is usually some combination of NVD, the GitHub Advisory Database, OSV.dev, and the vendor's own enrichments.

That's a useful job. It's not an early-warning system, and treating it like one is where teams get hurt.

What "early warning" actually means

An early-warning system tells you about a problem before it has a name. Tornado sirens fire on the radar signature, not after the touchdown report. Smoke detectors fire on particles in the air, not after a 911 call.

A CVE scanner fires on the 911 call.

The signal a CVE represents, advisory published, identifier assigned, severity scored, is the outcome of an existing process. By the time it shows up in your scanner, the following has already happened:

  1. Someone discovered the issue (often weeks or months earlier).
  2. The maintainer was contacted, or chose to disclose publicly.
  3. A fix was written, reviewed, and released, sometimes silently, sometimes with an advisory.
  4. A CVE number was requested from a CNA.
  5. The CNA published the entry.
  6. NVD, GitHub, and other databases ingested it.
  7. Your scanner refreshed its feed and matched it against your graph.

That sequence has a long tail. Independent research has measured the gap between the public fix commit and the CVE publication date in days and weeks for most ecosystems, and months for a non-trivial slice. During every day in that gap, your dependency graph is exposed and your scanner is silent.

Three windows your scanner can't see

Not all of these windows produce a CVE. Some never do.

1. The pre-disclosure window

A maintainer pushes a commit titled "fix: avoid prototype pollution in deepMerge". No advisory exists. No CVE has been requested. But the commit message, the diff, and the test name all describe a security-relevant fix.

A reviewer who reads upstream activity sees this. A scanner that reads advisory databases does not.

2. The fix-merged-but-not-released window

The fix is in main. Every release on the registry still ships the unfixed path. Many advisories are tied to release versions, not git commits, so even when the advisory eventually lands, it points at a release that doesn't yet exist.

In this window, your scanner has nothing to flag. The "vulnerable" version is the one you're using and the one the advisory will eventually name. The fix is a commit hash that no advisory database tracks.

3. The silent-patch window

A new release contains a security-relevant fix and no advisory is ever published. The release notes call it a "minor fix" or a "refactor". This is more common than people think. Researchers at Snyk, GitHub, and academic groups have repeatedly documented projects where 20–40% of security-relevant fixes ship without an advisory ID.

Your scanner is silent here permanently. The vulnerable version stays in your graph until you happen to upgrade for an unrelated reason.

Why scanners can't fix this

This isn't a product gap that any individual vendor has been negligent about. It's a structural property of the data source. A CVE scanner is built around the question "is the version I have in a list of vulnerable versions?". The list exists because someone published an advisory. The question can't be answered before the publish step happens.

You can layer faster ingestion, more enrichment sources, and proprietary research on top, and good vendors do. But the floor, the earliest moment a scanner can tell you about a problem, is the publish step itself.

That floor is exactly what dependency intelligence is designed to break through.

What changes if you know

The honest answer is: not always anything. Plenty of pre-CVE signals turn out to be false alarms, scope-narrowing patches, or maintainer hygiene that doesn't affect you. The output of an upstream-watching system is review triggers, not verdicts.

What changes is the time at which the decision becomes possible. For an active supply-chain attack with a three-hour window, that difference is the difference between catching it and not. For a silent patch, it's the difference between auditing your usage now and discovering it twelve months from now in a postmortem.

CVE scanners do the job they were built for. The job they were built for ends where the dangerous part of dependency security begins.