The Unbearable Weight of Massive CVE Numbers

Every year, thousands of new CVEs are disclosed. The numbers keep rising at staggering rates. In 2024, almost 40,000 CVEs were published, setting a new record and nearly doubling the count from just a few years earlier. The numbers as of September 2025 are at the 90% mark, with 3 months still to go.

For security teams, this creates an overwhelming reality: too many vulnerabilities to track, too many risks to manage, and not enough people or time to handle them all. For CISOs, the pressure is mounting to not only find these vulnerabilities but to demonstrate measurable risk reduction. The result is constant pressure on engineering and security teams to react and deploy patches. If you run scanners to identify unpatched vulnerabilities in a large software environment, reports containing 5-or-more-digit findings are no rarity.

Security professionals and frameworks offer a wide range of approaches for managing this overload. In this post, we examine scanning, triaging, and patching, and share our perspective on how teams can move beyond counting vulnerabilities to reducing real risk through remediation.

Vulnerability Scanning

Vulnerability scanning is a broad term but has evolved to often refer to scanning for missing patches as opposed to e.g. SAST or DAST. A variety of products and open-source solutions are available to support different types of systems and environments. The technical aspects of scanning for vulnerabilities are covered in many publications, however, good reporting on identified vulnerabilities can be just as important as the actual scanning.

Solutions refer to these using terms like vulnerabilities, issues, or findings. A missing patch means that a vulnerability exists in a piece of software that is present in your environment, however, it does not mean that there actually is a vulnerability in your environment. The distinction comes down to whether your environment is actually exploitable via the vulnerability present in a piece of code, which depends heavily on the functions actually imported from a library, the used configuration flags, or type of input being passed to an application.

Various data points support this differentiation, for example 25,082 CVE entries are reported for 2022, however, the Known Exploited Vulnerabilities Catalog (KEV) by CISA only lists 557 entries for 2022. Niels Provos and Peiter Zatko gave a must-watch presentation on When data contradicts security best practices, indicating that timely updates of all software packages may put you at a bigger risk than updating less often! This claim can anecdotally be supported by many security practitioners who in sum have triaged tens of thousands of software vulnerabilities and ended up determining that only a very little percentage of those actually affect their environments.

There are also debatable CVE instances on a regular basis (see e.g. here and here) which illustrate the strain our vulnerability handling ecosystem is under, sometimes even leading to differing ratings for the same CVE (here vs here). Even when the scoring is consistent, the rating can be nuanced: The CVSS definition of Attack Vector indicates vulnerabilities should be rated as exploitable via network if any attack path can be constructed for remote exploitation, however, the attack path then often depends on a more niche use of the vulnerable software (good example).

Finding numbers sometimes get even more inflated by scanners by reporting a certain vulnerability multiple times (e.g. because a CVE entry, a language-specific security advisory, and a Linux distribution security advisory exists and matches) or wrongly reporting certain vulnerabilities as fixable because a distribution vulnerability feed is broken.

All the factors above illustrate the challenges when scanning for vulnerabilities and, even more so, when wanting to act on the results. They are also meant to illustrate the complexity of our modern software landscape and not any individual shortcomings. Security practitioners sharing results, engineers maintaining open source, and security researchers discovering bugs put in amazing effort to make software more secure and we are excited to contribute to it.

But one thing is amply clear — scanning alone does not reduce risk. Without triage to determine what truly matters in your environment, and without remediation, reports will remain noisy and the backlog will only grow.

Triaging

Scanning surfaces thousands of issues, but not all vulnerabilities are equal. The next step is triaging — cutting through the noise to identify which issues actually matter for your environment and require action first.

CVE entries come with CVSS severity ratings that are the most common input for triaging processes and you are most likely familiar with those. We will describe a few additional data sources that may be helpful for your particular environment:

• Already mentioned above, the Known Exploited Vulnerabilities Catalog (KEV) by CISA lists vulnerabilities for which known exploits exist, which is probably one of the strongest indicators that you need to take action. However, we also saw above that those numbers are much lower and only cover ‘known knowns’. In other words, this is an essential but not sufficient list.‍
• First’s EPSS score is attempting to fill the gap between vulnerability release and availability of a publicly known exploit: They estimate “the likelihood (probability) that a software vulnerability will be exploited in the wild”, giving an indication which vulnerabilities may soon require you to act. This post on EPSS gives some great background information, but also recommends to pair it with “environment-specific techniques”.
• Environment-specific techniques can comprise utilizing the Vulnerability Exploitability eXchange (VEX), to determine whether your specific software packages are affected by certain vulnerabilities or a custom prioritization mechanism, where you track your most exposed or business-relevant software and focus on findings in this software first.
• It is often recommended to extend this custom prioritization by automated exposure analysis, where your environment is scanned from public networks to determine which software is exposed and should thus be most thoroughly triaged. However, external exposure analysis only gives you insight into the outermost layer of your environment, and most modern application environments are way more complicated than that.

Each of these techniques — KEV, EPSS, VEX, and exposure analysis — are important inputs to triaging vulnerabilities in your environment, but they still demand human effort and judgment. Analysts need to interpret whether a CVSS score actually maps to their environment, weigh external exposure data against what is exploitable in practice, and reconcile overlapping or conflicting signals. Even with automation, these steps rarely give the full picture.

The complexity can only be truly covered by analyzing the overall environment for exposure, blast radius, and attack chains through the complete environment. This involves looking beyond lists and external exposure to factoring in the interconnectivity within your environment and understanding how vulnerabilities can be chained together by an attacker to accomplish their goals — whether data exfiltration, ransomware deployment, or something more nefarious.

The Final Step: Remediation

Scanning surfaces issues. Triaging cuts down the noise and shows you what matters most. But risk only goes down when those prioritized vulnerabilities are actually fixed. That’s where remediation comes in.

At the heart of effective remediation is engineering workflow integration.

Patching is the most common form of remediation, and every team needs a solid patching culture. The reality is, at some point all software has to be updated. If you haven’t patched for a while and don’t have workflows in place, catching up becomes painful fast. With mature workflows, though, patching feels a lot less heavy. When updates are built into engineering processes — with automation, testing, and developer review — patching shifts from being a fire drill to being part of the flow. That means teams can react faster to threats like backdoored npm packages and stay aligned with requirements from industry standards and frameworks (e.g., CIS Controls, PCI DSS).

But patching is only part of the story. Remediation can also mean configuration changes, dependency upgrades, compensating controls, or fixing breaking changes that come with updates. The common thread is the same: simplify and automate remediation right within engineering workflows so fixes happen quickly, safely, and without grinding your team down.

Automating triage keeps the team from drowning, automating remediation within engineering workflows gets you to shore. Together they leave your team with fewer issues, less firefighting, and measurable risk reduction.