CVE noise drowns out supply chain threats

Although more than 48,000 Common Vulnerabilities and Exposures (CVEs) were published in 2025, only 58 posed a genuine, discoverable, and exploitable threat to enterprise supply chains, according to a new report from Black Kite.

This finding reinforces a critical shift in how organizations must approach cyber risk, Black Kite said in a statement. The challenge is no longer just scale. It’s precision.

Vulnerability volume is surging, Black Kite said, driven by rapid adoption of AI to both produce software and discover vulnerabilities. At the same time, it wrote, attackers are exploiting vulnerabilities faster than ever, on average seven days before public disclosure, and they are expected to get even faster as AI technologies accelerate scanning and exploitation capabilities.

As vulnerability volumes increase, the “patch everything” approach becomes mathematically and operationally impossible, said Black Kite’s chief research and intelligence officer, Ferhat Dikbiyik.

Patch with precision, the report advises. But precision alone doesn't close the gap — because the threats doing the most damage in software supply chains today don't arrive as CVEs at all.

[ Learn: Why RL Built Spectra Assure Community | Join: RL's free Community ]

Why the CVE overload matters

Security teams need to stop drowning in raw CVE volume and static CVSS scores, Dikbiyik said. “That 58-to-48,000 ratio proves teams must filter the noise using real-world exploitability, like dynamic EPSS predictions and OSINT discoverability.”

“If a vulnerability isn’t externally discoverable and actively targeted, it shouldn’t be at the top of the triage list.”
—Ferhat Dikbiyik 

Tim Mackey, head of software supply chain risk strategy at Black Duck Software, said that addressing the flood of CVEs requires prioritization and triage from the outset. First, he said,  you need to know whether the library or software impacted by the CVE in question is even used in your products or IT-managed environment.

“The next step is to determine which CVEs are known to have an exploit path. Those CVEs are the priority, and for most organizations they’re a small subset of the total number of CVEs per day.”
—Tim Mackey 

Overcoming vulnerability noise

Derek Fisher, Director of the Cyber Defense and Information Assurance program at Temple University, said Black Kite’s findings back up what most security teams realized years ago.

“There is a lot of noise in vulnerability management. There has been a continuing effort to determine reachability or exploitability when new findings are discovered, to reduce the burden on security teams that have limited time and resources.”
—Derek Fisher 

Roger Grimes, a CISO advisor at KnowBe4, said it isn’t news that less than 1% of reported CVEs are ever used by any real-world criminal against any real-world organization. “It has always been that way,” he said.

“Only a few dozen account for most of the real-world exploits. What that fact tells me is that defenders need to concentrate on the exploits most likely to be used against them. CISA’s Known Exploited Vulnerability Catalog [KEV] list is a good place to start.”
—Roger Grimes 

However, Brian English, product security lead at SAS, countered that for organizations managing large enterprise environments, it’s often more efficient, and lower risk, to remediate known vulnerabilities than to spend excessive time trying to determine theoretical exploitability. 

“From a product security perspective, it is often safer and more responsible to address known vulnerabilities than to assume they pose no practical risk.”
—Brian English 

But he does agree that exploitability analysis can help teams prioritize limited resources and avoid treating every CVE as equally urgent. Just don’t rely solely on tools such as software composition analysis (SCA) and the detection and patching of CVEs, he said, because that can provide a false sense of security.

Mind the (security) gap

The Black Kite report also noted that AI is widening the gap between organizations that can afford its advanced security capabilities and those that can’t. “While resource gaps have always existed, AI makes the divide exponentially faster and more concentrated,” Black Kite’s Dikbiyik said.

Anthropic’s Claude Mythos, for example, offers the opportunity to cut vulnerability detection time from 197 days to just 14, but “midmarket software publishers and open-source projects simply cannot afford these enterprise-grade AI defenses,” Dikbiyik said — which is putting them at even greater risk.

“Attackers are adapting to hardened enterprise perimeters by aggressively shifting their focus to these Tier 2 softer targets, meaning risk is migrating directly into the dependencies that large enterprises rely on.”
—Ferhat Dikbiyik

Dependencies are at risk

The report reinforces what a soft spot software dependencies are, especially with open-source components. Dikbiyik stressed that 82% of company-to-CVE matches involve vulnerabilities from outside the top 20 vendors.

“For software security teams, this means you cannot secure your perimeter just by monitoring a handful of big tech providers. You need continuous, automated visibility across your entire fragmented vendor ecosystem, because your risk often begins long before a commercial product is ever deployed.”
—Ferhat Dikbiyik

JPMorgan’s Fisher said software security teams have been aware for years that open-source security vulnerabilities are a big problem and have largely deployed the tools such as SCA that can spot them. 

“However, these teams do not need more ways to find vulnerabilities in dependencies. They need practical ways to identify vulnerabilities that have impact through exploitability metrics like CISA KEV, EPSS, or OSINT to confirm discoverability and visibility.”
—Derek Fisher

Time is not on our side

Dikbiyik illustrated the time crunch facing supply chain security defenders: “The median time from an attacker gaining initial access to handing it off to a secondary threat actor, like a ransomware cartel, has plummeted from over eight hours in 2022 to an astonishing 22 seconds.”

“When you combine that hand-off speed with the seven-day exploitation window, the reality cannot be clearer: Once a vendor in your supply chain is compromised, escalation is practically instantaneous.”
—Ferhat Dikbiyik

All of this is happening while the next generation of frontier AI such as Claude Mythos is poised to turn the CVE noise up to 11. But maybe it’s the signal that really matters.

Supply chain threats don't come with CVE numbers

The problem with CVE-centric security isn't that patching known vulnerabilities is wrong — it is necessary, and SAS's English is right that for large enterprises, blanket remediation can be more operationally practical than case-by-case exploitability analysis. But it is incomplete. And the incompleteness is growing more costly as attackers increasingly route around the vulnerability disclosure process entirely.

Supply chain attacks are the clearest illustration of this gap. On June 1, ReversingLabs researchers disclosed that an attacker published malicious versions of 31 packages in the @redhat-cloud-services npm scope in a 72-second scripted batch push. The payload — a three-layer obfuscated credential stealer targeting AWS, Azure, Google Cloud, HashiCorp Vault, GitHub, and npm credentials — began executing the moment any developer ran npm install. No CVE was assigned. No CVSS score was published. No EPSS prediction was generated. The threat was live and credential-harvesting in developer build environments before any vulnerability scanner had anything to scan.

This is the category of threat that vulnerability prioritization frameworks — however sophisticated — cannot address. They are built around disclosed flaws, not injected malware. The SolarWinds, 3CX, and XZ Utils attacks followed the same pattern: the compromise didn't exploit a known vulnerability; it introduced malicious code directly into the software itself.

AppSec teams need a detection layer that catches what vulnerability scanners miss: malware injected into packages before publication, software tampering after build, exposed secrets baked into binaries, and backdoor code introduced through compromised open-source dependencies. Binary analysis addresses this directly — by examining the final, assembled artifact for behavioral indicators of malicious activity, rather than checking it against a list of known flaws.

RL's Spectra Assure Community monitors more than 6 million open-source packages continuously for exactly these indicators. When the @redhat-cloud-services attack landed, behavioral analysis flagged the malicious preinstall execution, dynamic code evaluation, and binary-to-string obfuscation patterns uniformly across all affected packages — before the malicious versions were removed from npm, and before any CVE assignment was possible.

The 58 exploitable vulnerabilities in Black Kite's report are worth patching. But the next supply chain attack isn't going to arrive as CVE number 48,001.

Learn how RL's free Spectra Assure Community monitors open-source packages across npm, PyPI, NuGet, and more for the threats that don't show up in a vulnerability database.