The fastest trigger produces no CVE

Every scanner you run is examining events that have already transpired. A CVE is a record of a flaw that has previously been discovered. Between the moment a vulnerability is uncovered and when it is catalogued, considerable time elapses. The most critical attacks don't wait for this process. The industry's focus on CVEs becomes problematic.

EPSS scores a CVE. CISA's Known Exploited Vulnerabilities catalogue lists those that have been exploited in the wild. Prioritization is based on severity, a suitable mechanism within its intended context, yet it overlooks potential threats that lack an established identifier. These threats are often the ones advancing at the greatest pace.

The decisive moment occurs without a corresponding CVE. Examine how supply-chain compromises commonly unfolded. event-stream (2018) saw a widely-used npm package, downloaded millions of times weekly, maintained by someone who had become disengaged. A stranger agreed to take over, and the maintainer complied. The new owner released a couple of clean versions, then introduced a dependency containing code designed to target a specific Bitcoin wallet.

No CVE existed at the moment of the handover. The handover served as the indicator. ua-parser-js (2021) experienced a hijacking of the maintainer's npm account, resulting in the release of three compromised versions within a few hours. One delivered a cryptominer, the other a password stealer. The CVE appeared afterward. Anyone who installed a version from that period was compromised before a formal advisory was issued. polyfill.io (2024) had no associated package or CVE.

A domain serving scripts to hundreds of thousands of sites was sold, and the new operator began injecting malware into its output. The change in ownership and the corresponding change in the payload occurred simultaneously, with no vulnerability database able to identify the event, as it transpired beyond the scope of a database's description. xz-utils (2024) did receive a CVE, and it serves as the most illustrative case.

A contributor dedicated nearly two years to building trust, gaining commit rights, and ultimately inserting a backdoor into release tarballs. CVE-2024-3094 was only assigned when an engineer noticed a minor slowdown in his SSH logins and began investigating. The backdoor had been constructed over months, and the warning signs were evident throughout: a new maintainer assumed control of a critical library, the original author appeared exhausted, and the published tarball no longer matched its git history.

These incidents are not vulnerabilities; they are warnings, all of which preceded the assignment of a CVE by several months. The pattern is consistent. The source of each package becomes hazardous at its origin, visible openly and well before any record is made. A scanner relying solely on CVEs arrives after the critical phase has passed.

What we should focus on instead is the health of the project, tracking indicators that precede the issuance of an advisory. These include a sudden drop in commit velocity, indicative of abandonment, high maintainer turnover, and a thin bus factor, suggesting a critical library depends on a single, worn-down individual. Changes in ownership and control, such as npm handovers and domain sales, are events worthy of attention in their own right.

Revisions to release artefacts that diverge from the original source also merit scrutiny. None of these require a CVE to trigger. Most of them precede one, and some, like polyfill.io, describe attacks that would not have generated a CVE at all. Our objective is not to predict the future but to observe where the warning is evident, at the moment it occurs, rather than waiting for a database to provide a late or absent number.

This approach does not replace the critical work of tracking known, scored, and actively exploited vulnerabilities. It supplements it by addressing the period between a package becoming dangerous and its vulnerability being documented. I prefer to be early and occasionally incorrect about a project's health rather than precisely accurate about a CVE that arrives too late to be relevant.

The fastest trigger produces no CVE. If that is the trigger of primary concern, the CVE will never be where you discover it. Originally published on the OSPulse blog.