--- title: 'What is pre-CVE dependency risk?' date: 2026-05-09 excerpt: '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.' category: fundamentals 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."