Dependabot, OSV, and CVE scanners: what they miss before disclosure

Three of the most-deployed dependency-security tools, all built around the same data flow. A factual look at what each one is, what they do well, and the shared blind spot, the pre-advisory window.

Published 2026-05-07 · 5 min read

Tags: comparison, dependabot, osv, cve-scanners

Three of the most-deployed dependency-security tools in 2026 are GitHub's Dependabot, Google-stewarded OSV (and osv-scanner), and the broader category of CVE scanners (Trivy, Grype, Mend, the language-ecosystem audit commands). They're all useful. They all share a structural blind spot.

This post is a factual look at what each one is, what it does well, and where the boundary sits.

What each one actually is

Dependabot

Dependabot is a GitHub-native feature with two related capabilities:

• Dependabot alerts, matches your repository's dependencies against the GitHub Advisory Database and surfaces vulnerabilities as security alerts. The advisory database includes both reviewed advisories curated by GitHub and CVE imports from NVD.
• Dependabot version updates and security updates, opens pull requests that bump dependencies, either on a schedule (version updates) or in response to alerts (security updates).

Dependabot is bundled with GitHub at no additional cost (for public repos always; for private repos with most modern plans). It's a strong default for teams already on GitHub.

OSV and osv-scanner

OSV (Open Source Vulnerabilities) is a distributed vulnerability database format and a hosted aggregator service. Multiple sources push into it: PyPA Advisory Database, RustSec, Go Vulnerability Database, npm advisories, OSS-Fuzz, GitHub Security Advisories, and more.

osv-scanner is a CLI that takes your lockfile (npm, Go, Python, Rust, etc.), resolves the dependency graph, and queries OSV for matches. It's open source and free.

OSV's value is data-source breadth. By aggregating across many ecosystem-specific advisory feeds, it catches some advisories that NVD-only or GHAS-only scanners miss.

CVE scanners (broader category)

This is a category, not a product. It includes Trivy, Grype, Mend, Snyk Open Source (covered separately), the per-ecosystem audit commands (npm audit, pip audit, cargo audit, bundler-audit, mix deps.audit), and various commercial offerings.

What unites them is the data flow: take your dependency graph, look up versions in a vulnerability database, return matches. Different scanners pull from different combinations of NVD, GitHub Advisory Database, OSV, and proprietary feeds. They differ in output format, integration ergonomics, and depth of enrichment, but the core mechanic is the same.

What each does well

Practical strengths:

For their primary job, "is this dependency version in a known advisory database?", these tools are good and improving. Most teams should run at least one of them.

The shared blind spot

All of these tools share a data source: an advisory database. NVD, GHAS, OSV, and the commercial enrichments are different views of the same underlying flow:

someone discovers a vulnerability → fix is committed → release ships → CVE is requested → advisory is published → database refreshes → scanner alerts.

The earliest moment any of these scanners can tell you about a problem is after the advisory exists. Steps before the advisory, the public commit, the public PR, the public release, the public researcher post, are upstream of the data flow these tools observe.

This isn't a tooling failure. It's a property of the data source. As long as the input is "what does the advisory database say?", the output can't include "things that aren't in the advisory database yet (or ever)".

Three categories of risk live in that gap:

Pre-advisory commit activity. A maintainer commits a fix titled "prevent path traversal in serveStatic". No advisory exists yet. None of these scanners will fire. (See "The hidden window".)

Silent patches. A security-relevant fix ships in a release without ever getting an advisory. None of these scanners will ever fire on that fix. (See "Silent patches".)

Active-window registry compromises. A malicious version is live on the registry for hours, yanked before any CVE is assigned. The advisory database never gets the entry. Scanner-only stacks see nothing during the active window or after. (See the axios worked example.)

Where the differences between scanners matter

Despite the shared blind spot, the differences between scanners aren't nothing. If you're choosing between them:

Database breadth. OSV aggregates more ecosystem-specific feeds than NVD alone, so OSV-backed scanners catch advisories that NVD-only scanners miss. Snyk's proprietary research adds advisories ahead of public databases for some classes of vulnerability.

Time-to-alert after advisory publish. Dependabot and Snyk are usually within hours. NVD-only scanners can lag by a day or more depending on refresh cadence.

Reachability and exploitability. Some commercial scanners (Snyk, Endor) layer reachability analysis to reduce false positives. Worth it if your team is overwhelmed by advisory noise; less critical if you triage in volume.

Container / IaC coverage. Trivy is unusual in covering OS-level packages, container images, IaC manifests, and language deps in one tool.

Compliance artifacts. Commercial scanners produce nicer reports. Free / OSS scanners require more glue.

These differences matter at the margin. None of them changes the structural floor, "after the advisory", that all scanner-class tools share.

Where dependency intelligence sits

Dependency intelligence reads upstream activity directly, before the advisory exists. It catches fix-language commits, silent patches, release anomalies, and maintenance posture changes. Output is review triggers tied to source artifacts.

This is a fundamentally different data source from any CVE scanner. The two layers are complementary:

• CVE scanners (Dependabot, OSV, Trivy, Grype, Snyk, etc.), answer "what advisories apply to my graph?". Source of truth for known disclosed vulnerabilities. Compliance-friendly.
• Dependency intelligence, answers "what's happening in the upstream of my graph that I should review, regardless of advisories?". Source of pre-disclosure signals.

Most teams that adopt dependency intelligence keep their existing CVE scanner doing what it's built for. Removing the scanner would leave you blind to advisories; running only the scanner leaves you blind to the gap before them.

A short, honest summary

If you have nothing today, start with a CVE scanner. Dependabot is the lowest-friction option for GitHub teams; osv-scanner is the strongest free non-GitHub option. Either is a meaningful improvement over running nothing.

If you have a CVE scanner today and you're feeling the pre-disclosure gap, registry-side compromises, silent-patch incidents, fix-merged-but-unreleased windows, that's where dependency intelligence fits. Run both.

The next Tools post compares the SBOM-tooling stack (Syft, CycloneDX, SPDX), different layer, different question.