What is pre-CVE dependency risk?

A working definition for the class of dependency risk that exists before, and sometimes instead of, a CVE. The categories, the signals, and what review actually looks like.

Published 2026-05-09 · 4 min read

Tags: pre-cve, definitions, supply-chain, fundamentals

The phrase pre-CVE sounds tautological at first. Either a vulnerability has a CVE or it doesn't; "pre" implies an inevitable progression. In practice the term names something more specific and useful: a class of risk in your dependency graph that has publicly visible signals but no advisory yet.

This post is the working definition we use across the rest of our writing.

Definition

Pre-CVE dependency risk is the set of security-relevant changes in your dependencies, code, releases, maintenance posture, that are publicly observable today and not represented in any advisory feed.

Two things follow from that definition:

• It's about observability, not severity. Pre-CVE risk includes both serious (an active backdoor in a published release) and mild (a hardening patch that doesn't affect you) cases. The defining property is "a signal exists upstream and your scanner can't see it."
• It's not the same as zero-day. Zero-day implies an exploit with no fix. Pre-CVE risk usually has a fix or partial fix already, it's just not in any advisory database yet.

Defining the term this way scopes the problem. Anything you couldn't have known is not pre-CVE risk; that's the discovery research domain. Anything an advisory already names is not pre-CVE risk; that's CVE-scanner territory. The middle is what's interesting.

The four categories

Within that middle, four patterns produce the bulk of pre-CVE risk in modern supply chains.

1. Public-fix-before-advisory

A maintainer commits a fix. The commit message or diff makes the security relevance clear. No CVE has been requested. No GHSA advisory has been opened.

Examples of how this surfaces:

• A commit titled fix: prevent path traversal in serveStatic.
• A PR description that mentions "potential RCE" and links to a private discussion.
• A test added with a name like does_not_leak_session_token_on_redirect.

This is the most common shape of pre-CVE risk. The fix is in main for days, weeks, or months before any database knows about it.

2. Fix-merged-but-unreleased

The fix exists; the release does not. Every published version on the registry still ships the unfixed code path.

This category is particularly insidious because when the advisory eventually lands, it points at the release version that's now patched. Your scanner sees 1.13.0 → 1.14.0 upgrade and stops complaining. But the unpatched window, when 1.13.0 was the latest release and the fix sat in main, is invisible after the fact.

3. Silent patches

A new release contains a security-relevant fix and the maintainer never opens an advisory. The release notes use neutral language ("minor fix", "refactor in auth.ts"). No CVE is requested, ever.

Multiple research groups have measured this frequency at 20–40% of security-relevant fixes across major ecosystems. Your scanner has no way to flag a silent patch unless someone retroactively assigns a CVE, which often doesn't happen.

4. Trust degradation

The package itself doesn't change; the signals around it do. The maintainer's commit cadence drops to zero. A new co-maintainer is added with no prior history. The repo is transferred to a different organisation. A fork suddenly gets the bulk of activity.

None of these are vulnerabilities. They're posture changes that warrant a review. The recent shape of supply-chain attacks, typosquats, maintainer-account takeovers, registry-side compromises, makes them worth tracking.

What "review" looks like

Pre-CVE signals are review triggers, not verdicts. The output of a system that surfaces them is "here is a thing worth a security engineer's time"; the input to your decision is the source itself, the actual PR, commit, issue, or release.

A reasonable review of a pre-CVE signal answers four questions:

1. Does this affect us? Code path analysis: do we exercise the vulnerable surface?
2. Is the fix released yet? If not, can we hold the dependency at the last-known-good version until it is?
3. Is the upstream actor trustworthy here? Is this fix consistent with the maintainer's pattern, or is something off?
4. Should we automate the response next time? Update detection rules, tighten the PR check, document the pattern.

This is the same shape as a CVE response, the difference is only in the trigger.

Why this matters operationally

Two reasons.

Time. When a pre-CVE signal exists, your CVE-equivalent moment moves earlier, sometimes by weeks. That window is where the cost of incidents like supply-chain compromises actually accrues. A three-hour active-attack window with no scanner signal is a different problem than a CVE published a week after the attack closed.

Coverage. Silent patches and unreleased fixes are permanently invisible to scanner-only workflows. That isn't a tail problem; for some ecosystems it's a substantial fraction of all security-relevant changes.

The point of naming pre-CVE risk explicitly is to make these gaps visible to the people who own dependency security, and to give them something concrete to ask about when a vendor pitches them a "scanner".

What pre-CVE risk is not

Two clarifications worth being firm about.

It is not a replacement for CVE scanners. CVE scanners answer "is a published advisory matching one of my dependencies?" That is a real and necessary question. Pre-CVE awareness sits alongside it; the two together cover before, during, and after disclosure.

It is also not a promise of universal early detection. Some vulnerabilities are discovered privately, fixed quietly, and disclosed only after the patch ships everywhere. A pre-CVE-aware system has nothing to surface in that case. The claim is "where signals exist, see them earlier", not "see everything earlier."