Vulnerability management has a math problem. In 2024, the CVE Program published 40,077 vulnerability records. In 2025, that figure climbed to 48,244. By the end of the second quarter of 2026, another 35,872 records had already been published, with Q2 alone accounting for 20,709 CVEs compared with 15,163 during Q1. Those figures describe a disclosure system producing security information at a pace few organizations can match with remediation.

That growth does not mean software suddenly became proportionally less secure. The vulnerability-disclosure system itself has grown. The CVE Program reported more than 500 participating CVE Numbering Authorities in March 2026, up from only 23 CNAs when its federated publication strategy began in 2016. Vendors, researchers, open-source projects, CERT organizations, bug-bounty providers, and other groups now publish vulnerabilities across a much broader portion of the technology stack. Better visibility is part of the reason more CVEs appear every year.

For defenders, the operational effect is still the same. More vulnerabilities enter scanners. More findings appear on dashboards. More remediation tickets compete for engineering time. More patches require testing, deployment, validation, and change approval. A single CVE can appear across hundreds or thousands of systems, meaning tens of thousands of global vulnerability records can translate into far more internal findings.

Security teams have become very good at finding vulnerabilities. The harder problem is deciding which ones deserve attention first.

The Vulnerability Queue Keeps Growing

Academic research has documented that problem for years. A 2020 study by Jay Jacobs, Sasha Romanosky, Idris Adjerid, and Wade Baker in the Journal of Cybersecurity examined vulnerability prioritization using more than 75,000 vulnerabilities and exploitation observations collected in part from more than 100,000 corporate networks. The researchers found that simple remediation strategies based on broad vulnerability characteristics produced poor efficiency. A better approach focused effort on vulnerabilities attackers were more likely to exploit.

That distinction matters since a CVE record is not the same thing as a remediation decision. A scanner can identify a technical weakness, assign it a severity score, and report every affected asset, but it cannot automatically determine how much operational attention each finding deserves. Organizations have limited maintenance windows, testing capacity, engineering staff, and tolerance for production changes. Vulnerability disclosure has no comparable ceiling.

This mismatch is one reason CVSS has become both useful and frequently misused. CVSS gives defenders a standardized way to describe technical severity. An unauthenticated remote code-execution flaw is plainly different from a low-impact information disclosure. Problems begin when the score is treated as a complete measure of organizational risk.

FIRST, which maintains CVSS, states in its CVSS v4.0 guidance that the Base Score measures severity rather than risk. The score describes properties of the vulnerability itself. It does not know where the affected system sits inside a network, whether it faces the Internet, what data it stores, whether exploit code exists, or whether attackers are actively using the flaw.

That distinction often disappears inside vulnerability-management programs. A scanner reports hundreds of Critical findings and thousands of High findings, and teams naturally start at the top of the severity column. Research suggests that this approach can consume remediation capacity without reliably identifying the vulnerabilities attackers will use.

Severity Is Not the Same as Exploitation

Luca Allodi and Fabio Massacci examined this issue in a 2014 study published in ACM Transactions on Information and System Security. Their case-control analysis compared CVSS severity with observed exploitation and found that remediation strategies built mainly around high CVSS scores performed little better than random selection in identifying vulnerabilities tied to real attacks. Evidence that exploit code existed was far more useful.

The 2020 Journal of Cybersecurity study produced a related finding. The researchers observed exploitation in the wild for only 5.5 percent of vulnerabilities in their dataset. The number is not a universal exploitation rate, but it illustrates the gap between vulnerabilities that exist and vulnerabilities that attackers actually use. A large vulnerability backlog can contain thousands of technically valid findings, yet only a fraction may represent near-term attack paths.

That changes the question defenders need to ask. “What has the highest score?” is often less useful than “What is most likely to be used against us?”

CISA’s Known Exploited Vulnerabilities Catalog attempts to answer part of that question. KEV does not list every severe vulnerability. It tracks vulnerabilities for which CISA has evidence of active exploitation. Federal Civilian Executive Branch agencies face defined remediation deadlines for entries added to the catalog, and CISA encourages private organizations to use KEV as part of their own vulnerability-management programs.

The value of KEV comes from evidence. A Critical vulnerability with no observed exploitation can still matter, but a lower-scoring flaw that attackers are already using may deserve action sooner. The existence of exploitation changes the context in a way severity alone cannot capture.

Age does not solve the prioritization problem either. Vulnerabilities disclosed years earlier can return to operational relevance once attackers begin using them at scale or locate unpatched systems that remain exposed. Old CVEs regularly appear in active attack chains. A vulnerability does not become harmless simply because it disappeared from security headlines.

KEV has limits. Evidence of exploitation may arrive after attacks begin, and absence from the catalog does not mean a vulnerability is safe. Security teams also need signals that estimate what attackers may use next.

Predicting What Attackers Will Use

The Exploit Prediction Scoring System was built for that purpose.

EPSS estimates the probability that a published CVE will be exploited in the wild during the next 30 days. The model evaluates features tied to the vulnerability, exploit code, offensive tooling, public references, threat intelligence, age, and observed attacker activity. Scores are recalculated daily as new information appears.

Its academic foundation comes from research by Jacobs, Romanosky, Benjamin Edwards, Michael Roytman, and Idris Adjerid. Their 2021 paper in ACM’s Digital Threats: Research and Practice presented a data-driven model for estimating exploitation probability rather than using technical severity as a stand-in for attacker behavior.

Research presented at USENIX Security 2022 extended the same idea. Octavian Suciu and colleagues examined more than 103,000 vulnerabilities and developed a metric called Expected Exploitability. Their work treated exploitability as something that changes over time as proof-of-concept code, technical writeups, exploit modules, and other artifacts become available. Their model improved precision from 49 percent to 86 percent compared with existing exploitability metrics in their evaluation.

That changing threat state matters. On disclosure day, a vulnerability may have little public technical detail. A researcher may release proof-of-concept code two days later. An exploit framework may incorporate it next. Internet scanning can follow. Commodity attackers may begin probing for exposed systems soon after.

The CVE identifier never changes. The risk around it can change dramatically.

Static vulnerability queues are poorly suited to that reality. A flaw assigned moderate priority on Monday may deserve emergency remediation by Thursday. EPSS can move as exploitation probability changes. CISA can add the flaw to KEV once exploitation is confirmed. Threat-intelligence reporting can connect it to active campaigns. Internal asset data can reveal that an affected system recently became Internet-accessible.

A vulnerability program that assigns priority once and leaves the finding in a fixed queue can miss that entire progression.

More Data Does Not Automatically Mean Better Prioritization

Modern vulnerability platforms can ingest CVSS scores, EPSS probabilities, KEV status, vendor ratings, exploit availability, threat intelligence, asset ownership, network exposure, business function, compensating controls, patch availability, and support status. Each signal answers a different question.

CVSS describes technical severity. EPSS estimates near-term exploitation probability. KEV identifies confirmed exploitation. Asset inventories show where the vulnerable software exists. Exposure data shows whether attackers can reach it. Business context helps estimate what successful exploitation could affect.

None of those signals works well as a complete answer by itself.

FIRST makes the same point in its EPSS documentation. EPSS does not know whether a vulnerability exists inside a given organization, what system contains it, what defensive controls surround that system, or what damage exploitation could cause. A high EPSS score on an isolated laboratory system may represent less organizational risk than a lower-probability vulnerability on an Internet-facing identity platform.

The same CVE can carry very different consequences across two assets. One system may sit behind multiple network controls, contain no sensitive information, and have little access to other infrastructure. Another instance of the same flaw may exist on an external gateway handling authentication for thousands of users. The vulnerability record is identical. The remediation priority is not.

That is where asset context becomes one of the most useful inputs in vulnerability management. Internet exposure matters. System privilege matters. Data sensitivity matters. Placement within an attack path matters. A vulnerability on a domain controller, hypervisor, VPN concentrator, security appliance, privileged management server, or identity platform can deserve more attention than the same flaw on an isolated low-value host.

Prioritization Needs More Than One Score

Recent research increasingly treats prioritization as a multi-signal problem. A 2026 IEEE Access study proposed a model combining KEV, EPSS, and CVSS instead of relying on a single metric. The researchers evaluated the method against 28,377 vulnerabilities and reported 85.6 percent coverage of exploited vulnerabilities, with higher remediation efficiency than a CVSS-only strategy in their dataset.

The value of that research is less about copying one formula and more about changing how the decision is structured. Teams can begin with evidence of active exploitation, examine predicted exploitability, evaluate technical impact, and then place those signals into the context of the affected asset.

CISA’s Stakeholder-Specific Vulnerability Categorization model follows a similar idea. SSVC uses decision points tied to exploitation and organizational impact rather than assigning every vulnerability one universal priority number. The approach reflects a simple fact: vulnerability management is local. A flaw can be urgent for one organization and relatively low priority for another.

This also exposes the limits of “patch everything” as an operational strategy. A fully patched environment is an attractive goal, but production infrastructure has constraints. Patches require testing. Legacy software can break. Operational technology may have narrow maintenance windows. Network appliances can require reboots. Some vendors release fixes slowly. Some products reach end of support long before organizations finish replacing them.

Treating every unresolved CVE as an emergency can create its own problems. Engineering time gets consumed by low-value fixes. Production systems absorb unnecessary change. The findings that pose the most immediate danger compete with routine patching for the same staff and maintenance windows.

The 2020 exploit-prediction study frames this as a tradeoff between coverage and efficiency. Fixing everything gives broad coverage but consumes enormous resources. Fixing too little preserves resources but leaves meaningful exposure behind. Good prioritization tries to use finite remediation capacity where it reduces the greatest amount of real risk.

That requires more than sorting a spreadsheet by CVSS.

The Queue Has to Keep Changing

It also requires vulnerability management to operate continuously. Priority cannot remain a permanent label assigned during the first scan. New exploit code, new attacker activity, new CISA entries, new threat reporting, and new asset exposure can all change the decision.

A useful vulnerability program needs a mechanism for pulling old findings back to the front of the queue when their threat state changes. A three-year-old CVE should not remain buried in a backlog if attackers begin exploiting it against a product the organization still operates.

The larger trend points to vulnerability management becoming an information-filtering discipline. The CVE Program published 28,961 records in 2023, 40,077 in 2024, and 48,244 in 2025. The first half of 2026 produced 35,872 more. Greater disclosure is a positive development. A flaw does not become safer by remaining undocumented.

The cost of that visibility is noise.

Better scanners find more issues. More CNAs publish more vulnerabilities. Researchers disclose more flaws. Software inventories become more complete. Cloud environments create more asset data. Threat-intelligence platforms add more context. Every improvement in visibility gives defenders more information to process.

The strongest vulnerability programs will not be the ones that produce the longest reports. They will be the ones that can reduce thousands of findings into a defensible sequence of actions.

That means separating severity from exploit likelihood, confirmed exploitation from theoretical risk, exposed systems from isolated ones, and high-value infrastructure from low-impact assets. It also means accepting that remediation capacity is finite and that vulnerability management is partly an allocation problem.

More bugs will keep appearing. More scanners will keep finding them. More data will keep entering the queue.

The security problem is no longer finding enough vulnerabilities to fix. It is making sure the right vulnerability reaches the front of the line before an attacker gets there.

How Can Netizen Help?

Founded in 2013, Netizen is an award-winning technology firm that develops and leverages cutting-edge solutions to create a more secure, integrated, and automated digital environment for government, defense, and commercial clients worldwide. Our innovative solutions transform complex cybersecurity and technology challenges into strategic advantages by delivering mission-critical capabilities that safeguard and optimize clients’ digital infrastructure. One example of this is our popular “CISO-as-a-Service” offering that enables organizations of any size to access executive level cybersecurity expertise at a fraction of the cost of hiring internally.

Netizen also operates a state-of-the-art 24x7x365 Security Operations Center (SOC) that delivers comprehensive cybersecurity monitoring solutions for defense, government, and commercial clients. Our service portfolio includes cybersecurity assessments and advisory, hosted SIEM and EDR/XDR solutions, software assurance, penetration testing, cybersecurity engineering, and compliance audit support. We specialize in serving organizations that operate within some of the world’s most highly sensitive and tightly regulated environments where unwavering security, strict compliance, technical excellence, and operational maturity are non-negotiable requirements. Our proven track record in these domains positions us as the premier trusted partner for organizations where technology reliability and security cannot be compromised.

Netizen holds ISO 27001, ISO 9001, ISO 20000-1, and CMMI Level III SVC registrations demonstrating the maturity of our operations. We are a proud Service-Disabled Veteran-Owned Small Business (SDVOSB) certified by U.S. Small Business Administration (SBA) that has been named multiple times to the Inc. 5000 and Vet 100 lists of the most successful and fastest-growing private companies in the nation. Netizen has also been named a national “Best Workplace” by Inc. Magazine, a multiple awardee of the U.S. Department of Labor HIRE Vets Platinum Medallion for veteran hiring and retention, the Lehigh Valley Business of the Year and Veteran-Owned Business of the Year, and the recipient of dozens of other awards and accolades for innovation, community support, working environment, and growth.

Looking for expert guidance to secure, automate, and streamline your IT infrastructure and operations? Start the conversation today.

recent posts

about

Leave a comment Cancel reply