Your Security Team Is Patching the Wrong Vulnerabilities. The Data Is Unambiguous.

Around 20,000 CVEs were reported in 2021, but fewer than 5% of them were actually used to attack anything. Organizations that focused on patching based on CVSS scores (which is what most vulnerability management programs do) used considerable amounts of engineering effort patching vulnerabilities that were never exploited, but failed to address exposure to vulnerabilities that were actively being attacked. This is not a hypothetical concern about efficiency. This is an actual failure of security. And it is taking place at most organizations today.

The CVSS Illusion

The Common Vulnerability Scoring System, also known as CVSS, was created to establish the severity of a vulnerability by assigning it a score ranging from 0 to 10 on the basis of certain criteria including but not limited to: attack vector, attack complexity, privileges required, and impact. On paper, it sounds logical, but in practice, CVSS rates the wrong thing.

CVSS calculates theoretical severity, that is what the maximum possible damage done by exploiting the said vulnerability would be under ideal conditions. However, it fails to rate how vulnerable the vulnerability really is, whether an exploit is feasible given the particular scenario, or if the asset is realistically vulnerable to any attacks. This results in misallocation where a high CVSS rating of a system that does not have any publicly known exploits consumes resources which would be more useful in correcting low CVSS systems that are exploited by ransomware groups targeting your industry.

The Log4Shell Lesson That Teams Keep Forgetting

CVSS 10.0 Log4Shell (CVE-2021–44228) was a critical Remote Code Execution bug that affected Apache Log4j, a library so widely used that it is claimed to exist in just about every java based application created. When it was disclosed at the end of 2021, exploit code had been released publicly within hours of the announcement. Threat actors from nation-states, ransomware gangs, and script kiddies alike all began hunting for systems to exploit.

Traditional organizations that followed the standard approach of prioritizing by CVSS score, patching according to the predetermined schedule, and verifying the completion took from several days to weeks until they got successfully patched. The ones who managed to transform vulnerability exploitation into incident-level response got patched in 24–48 hours.

It wasn’t about having sufficient resources, it was about a certain process. And the essence of this process boiled down to one question: whether there was another path to vulnerability response when there was confirmed exploitation in the wild or not.

The Two Metrics That Actually Matter

EPSS (Exploit Prediction Scoring System ) is an exploit prediction scoring system created by FIRST through machine learning of historical data of exploitations. EPSS generates a probability score of how likely the particular CVE will be exploited within the next 30 days in the wild. CVSS vs EPSS can be seen as an example of practical risk management vs theoretical risk assessment.

There is strong empirical evidence to back EPSS as well. In research carried out by EPSS developers, they show that organizing your patch queue according to EPSS score and fixing the top 10% by exploitation probability will cover roughly 60% of exploits. Organizing patches by CVSS only covers around 13%.

CISA’s Known Exploited Vulnerabilities catalog is, in my view, the single most actionable free resource in vulnerability management. It lists CVEs for which CISA has confirmed evidence of exploitation in the wild. For U.S. federal agencies, patching KEV entries within defined timeframes is a legal mandate. For every other organization, the KEV catalog should function as your P1 patch queue is the first thing that moves when a new entry appears, regardless of CVSS score.

In 2024, KEV listed vulnerabilities have been leveraged in attacks against critical infrastructure, financial services, and healthcare organizations. From KEV listing to exploitation at scale takes days, not weeks.

The Structural Fix Most Programs Are Missing

While risk-driven vulnerability management is not a new idea, few organizations practice it comprehensively. This framework needs three factors that are missing from CVSS:

Indicator of exploitability, KEV, and EPSS can tell you if an attack is happening or likely to happen. Asset context specific vulnerabilities have different significance as risks for an online authentication service than for an internal development machine. Threat actor context — a vulnerability attacked by APTs within the healthcare industry versus a vulnerability attacked by opportunistic botnets when you operate in the healthcare industry.

The system that integrates these criteria where KEVs get treated as events, where EPSS is used to prioritize everything else, where the weighting factor includes criticality of the asset and relevance of the threat actor will always beat out the CVSS-first program in terms of what truly counts decreased exploitable attack surface versus realistic attacks, not decreased number of open CVEs.