Managing vulnerabilities across a modern attack surface is difficult, and it is difficult for the same reason at every organization regardless of size: there is always more to fix than there are people and hours to fix it. Trying to address everything without a prioritization strategy is not thorough, it is wasteful. Resources go to low-risk issues while the vulnerabilities that attackers are actually using stay open.
Prioritization is the answer, but only if it is built on the right inputs. A severity score on its own does not tell you whether anyone is attacking a vulnerability, or whether the system it sits on matters to your business. Both of those things change the answer completely.
This article explains the methodology SecOps uses to turn raw vulnerability data into a ranked, defensible remediation order. It covers which signals go in, how they are combined, and why each design decision was made the way it was.
Prioritization used to be about working efficiently. At current disclosure rates it is about capacity, and the gap between what is published and what any team can fix is now very wide.
At its 2026 peak, disclosure reached nearly ten thousand CVEs in a single month, roughly one every six minutes. Remediation capacity has not grown to match. The 2026 Verizon Data Breach Investigations Report found median time to patch moving in the wrong direction, from 32 days to 43, which means teams are falling behind rather than catching up.
Three recent developments have made this harder still.
Exploitation increasingly precedes the patch. Google Threat Intelligence tracked 90 exploited zero-days during 2025, and 43 of them, a record share, targeted enterprise technology. They concentrated in exactly the places that are hardest to monitor: security appliances, networking infrastructure, VPNs and virtualization platforms, which offer privileged access and rarely support endpoint detection.
The National Vulnerability Database stopped scoring most vulnerabilities. Under a 2026 policy change, NIST enriches only CVEs that appear in CISA's Known Exploited Vulnerabilities catalog, affect federal government software, or are designated critical under Executive Order 14028. Everything else is tagged Lowest Priority, with no CVSS score, no product mapping and no weakness classification. Any pipeline that waits on the NVD now stalls on the large majority of CVEs.
Vulnerability discovery has begun to operate at machine scale. In 2026 Anthropic's Claude Mythos autonomously identified more than ten thousand previously unknown flaws across every major operating system and web browser, including bugs that had survived decades of human review. The number of vulnerabilities that can be found is no longer limited by how many researcher hours are available, and disclosure volumes should be expected to rise further.
Under these conditions prioritization stops being a way to work more efficiently and becomes the main lever a security team still controls.
The Common Vulnerability Scoring System gives the industry a shared vocabulary for how serious a vulnerability is, and it does that job well. Problems start when severity alone is used to decide what gets fixed first.
Of CVEs published in the first half of 2026 that carry a score, 10.0% are rated Critical and 39.1% High. A policy of fixing everything scored 7.0 and above therefore puts close to half of all published vulnerabilities into the queue, which leaves a team with very little narrowing to work with.
It is worth being precise about the limitation, because CVSS is often criticized for things it never claimed to do. CVSS v4.0 does include Threat and Environmental metric groups specifically so organizations can account for exploit maturity and their own environment, and the specification explicitly tells implementers to enrich scores with factors that sit outside CVSS entirely. The accurate statement is narrower:
CVSS measures the severity of a vulnerability. It does not measure the risk that vulnerability presents to a particular organization, and was not designed to.
That leaves an obvious question. If severity alone cannot decide what gets fixed first, what else belongs in the decision, and where does each part of it? Exploitation evidence is one piece, but it describes the vulnerability rather than your environment. Business importance and internet exposure describe the machine, not the flaw. Neither tells an executive whether the organization as a whole is getting safer or worse. These are three separate questions, and trying to answer all of them with a single number is what makes most scoring feel arbitrary.
SecOps scores risk at three levels, each answering one of those questions. Every layer is built from the one below it, so a change in exploitation activity on a single CVE propagates all the way up to the organizational view.
Keeping the layers separate is deliberate. A vulnerability score on its own cannot tell you what to fix first, because the same CVE carries very different risk on a domain controller than on a spare workstation. An asset score on its own cannot tell you whether the program is improving over time. And a single organization-wide number gives a remediation team nothing to act on. Each layer answers its own question, and none of them replaces the others.
Layer 1 draws on three kinds of data, and the difference between them shapes the whole model. They are not interchangeable, and averaging them together does not work.
Each category behaves differently, so each is handled separately. A confirmed observation and a probability belong on the same axis, because both describe exploitation. A severity rating belongs on a separate axis, because it describes consequence rather than likelihood. Business context belongs at the asset layer, where it multiplies rather than adds.
CISA KEV is the catalog of vulnerabilities confirmed to be exploited in the wild. Appearing in it is evidence rather than a prediction, which makes it the strongest single signal available.
EPSS, the Exploit Prediction Scoring System, estimates the probability that a vulnerability will be exploited within the next 30 days. It scores every published CVE daily, which gives a forward-looking reading even on vulnerabilities that have no exploitation history yet.
Public exploit availability is whether working attack code exists and how usable it is. A proof of concept published to a code repository, an entry in a public exploit database, and a ready-made module in an exploitation framework are all different points on that scale. Each one lowers the skill and effort needed to attack the vulnerability, which widens the set of attackers capable of using it.
The Context Prioritization Rating, or CPR, is the per-vulnerability score, reported on a 0 to 100 scale. It answers two questions separately, then combines them.
Three independent indicators that a vulnerability will be attacked, each expressed as a value between 0 and 1.
EPSS is the modelled probability that a vulnerability will be exploited within the next 30 days, refreshed daily for every published CVE. It enters as its published value, unmodified.
CISA KEV contributes a fixed 0.70 when a vulnerability appears in the catalog. A listing is confirmed observation rather than prediction, which is why it is the strongest constant in the model.
Exploit availability asks whether working exploit code exists and how easy it is to use. This matters because it decides who is capable of running the attack. A vulnerability that requires original research is a very different proposition from one packaged inside an exploitation framework. It is graded on a single scale, taking the strongest evidence found:
A weighted average, giving each signal a share of the total, has a limitation that matters here. Under a weighted average, no signal can contribute more than its own weight, so a vulnerability with an EPSS score of 0.90 and nothing else is capped at whatever share EPSS was given. A 90% chance of imminent exploitation would come out looking moderate. Changing the weights does not fix this, because the limitation is structural.
The signals are combined as independent indicators instead. Read the formula as the chance that at least one indicator is right. Each (1 - signal) is the chance that indicator is wrong, multiplying them gives the chance they are all wrong, and one minus that is the result.
Two useful properties follow. A single strong signal is enough on its own, so an EPSS score of 0.90 with nothing to back it up still produces a likelihood of exactly 0.90. And signals reinforce each other without the total ever passing 1, so a vulnerability that is in KEV, has a weaponized module available and scores 0.95 on EPSS comes out at 0.993.
CVSS, normalized to 0 to 1 by dividing by 10. This answers what an attacker gains if exploitation succeeds: whether they reach code execution, what data is exposed, whether the system remains usable.
Because CVSS coverage is uneven, impact is sourced through a fallback chain rather than a single lookup. Where an NVD score exists it is used. Where it does not, the score published by the CNA is used, then the vendor advisory. Anything still unscored is flagged for review rather than defaulted to zero, since after the NVD's 2026 policy change a missing score means the CVE fell outside NIST's enrichment criteria and says nothing at all about severity.
The likelihood and impact weights are the one part of the model an organization configures, and they must total 100. They express a real trade-off between how likely an attack is and how much damage it would do. The default leans toward likelihood, but a team working under a regime that emphasizes consequence can shift the balance and the score will follow.
Nothing else is exposed as a setting. How different kinds of exploitation evidence relate to each other is an empirical question rather than a matter of preference, and holding those values constant keeps scores comparable across organizations and over time.
Rows six and seven make the central point. A CVSS 7.5 that is confirmed exploited scores 72.7, while a CVSS 9.8 with no exploitation signal scores 41.6. Ordering by severity alone would place them the other way round, and would do so consistently across the whole backlog.
Row four is worth noting too. A vulnerability that appears in no catalog and has no published exploit code still ranks high on the strength of its EPSS score alone. Fewer than one in four hundred CVEs reaches an EPSS of 0.90, so a score at that level deserves attention without needing anything to back it up.
CPR is continuous and works best as a ranking rather than a set of bands, but the separation it produces is stark. Confirmed-exploited vulnerabilities carry a median likelihood of about 0.94, while everything else sits near 0.01, and that gap survives into the final score.
As broad guidance: values above 70 indicate substantial exploitation evidence and a genuine time constraint. Values between 40 and 70 represent the range in which severity is significant but exploitation evidence is partial, and asset context should determine sequence. Values below 40 indicate vulnerabilities suitable for remediation within routine patch cycles.
The same vulnerability does not carry the same risk on every machine. Two context factors modify the score.
Asset criticality is a 1 to 5 rating of how essential a system is to business operations, revenue and reputation. It is set per asset and is the primary way organizational knowledge enters the model, because it is the one thing no external data feed can tell you. A payroll database and a lab VM can run identical software with identical vulnerabilities and represent completely different risk.
It enters the calculation as criticality / 5, giving a multiplier from 0.2 at the lowest rating to 1.0 at the highest. A criticality 1 asset therefore carries a fifth of the risk weight of a criticality 5 asset with the same findings. Because this factor is powerful, an uncurated estate where everything sits at the default will produce a flat and largely useless ranking. Setting criticality accurately is the highest-value configuration work in the platform.
Internet exposure distinguishes systems reachable from the public internet from those that are not, and is derived automatically from the asset's addressing rather than being entered by hand. This is not a minor refinement. The 2026 DBIR found edge devices and VPNs jumped from 3% to 22% of exploitation-driven breaches in a single year, a sevenfold increase.
Exposure applies as a multiplier of 1.2 rather than as a fixed bonus, and the distinction matters. A bonus adds the same amount to every asset regardless of what else is true about it, so it barely moves a high-scoring asset and disproportionately inflates a low-scoring one. A multiplier scales with the risk already present, which is the correct behavior: internet exposure makes a dangerous vulnerability considerably more dangerous, and makes a harmless one only slightly less harmless.
The Asset Severity Rating, or ASR, expresses the risk carried by a single asset on a 1 to 1,000 scale, with four bands: Low below 251, Medium to 500, High to 750, and Critical above.
Three terms determine the result.
worst is the highest CPR among the asset's open findings, normalized back to 0 to 1. This is the dominant term, at 80% of the threat calculation. It reflects how a host actually gets compromised: an attacker needs one reliable way in, not fifty, and the easiest route onto the machine is what determines how exposed it is.
volume captures accumulated backlog, but deliberately saturates. The exponential form means the first few findings move it substantially while the hundredth barely registers, approaching but never reaching 1.0. This is what keeps asset risk from turning into a simple vulnerability count. Backlog is real hygiene debt and should stay visible, but a hundred low-severity findings should not outrank one vulnerability that is under active attack.
threat weights these at 80% and 20% respectively, then criticality and exposure scale the result into the final 1 to 1,000 rating.
The four bands are Low below 251, Medium from 251 to 500, High from 501 to 750, and Critical above 750. In practice an asset reaches the upper bands only through a combination of a materially dangerous finding and genuine business importance, which is the intended behavior. A Critical rating indicates that a business-important asset carries a vulnerability under active exploitation. A Low rating on a criticality 5 asset indicates that the asset is currently well maintained, not that it is unimportant.
The final two rows demonstrate that volume continues to register. A neglected host carrying hundreds of open findings remains visible in the ranking; it simply does not outrank a business-critical system carrying a single vulnerability under active exploitation.
The Infrastructure Score is a single number on the same 1 to 1,000 scale as the Asset Severity Rating, describing the risk carried by the estate as a whole. It is the number for a board pack, a quarterly review, or a trend line.
The obvious way to produce an organization-wide figure is to average the Asset Severity Ratings across the estate. It is also the wrong way. An average can be improved without fixing anything: onboard a few hundred well-maintained laptops and the number falls, the trend line looks healthy, and the exposed server from last quarter is still sitting there exposed. Any measure that divides by the number of assets can be moved by adding assets, and a security metric that rewards buying hardware is not measuring security.
Two terms drive the result. worst is the single most exposed asset in the estate, and it carries most of the weight. spread accounts for all the remaining risk, weighted so that business-critical systems count for more than peripheral ones, and saturating so that a larger estate does not mechanically produce a larger number. Between them they answer the two questions a board actually asks: how bad is the worst of it, and how far does it reach.
By quantifying and representing the severity levels of vulnerabilities and risks, these scores provide a standardized metric that enables security teams to prioritize their efforts effectively. The scores help identify critical assets, systems, or areas within the infrastructure that require immediate attention and mitigation. This score plays a vital role in assisting security professionals with risk-based recommendations and decision-making. With risk-based recommendations derived from these scores, security professionals can allocate resources, time, and efforts based on the severity levels indicated. They can focus on addressing vulnerabilities with higher scores, which indicate a greater potential impact on the organization's security posture and overall risk exposure.
These numerical scores provide a common language and framework for communication between security teams and other stakeholders. They facilitate informed discussions and enable decisionmakers to understand the urgency and significance of specific vulnerabilities concerning the organization's goals and objectives. Moreover, the scores allow security professionals to track progress over time. By regularly monitoring and reassessing the scores, they can measure the effectiveness of their risk mitigation strategies and prioritize ongoing security measures accordingly. This helps in demonstrating the value of investments in security and justifying resource allocations to management and stakeholders.
At SecOps Solution, we incorporated the EPSS scoring system which will give security teams and business leaders the information they desperately need to make smart risk-based decisions. We developed an EPSS calculator which is a tool that allows users to search for any vulnerability where users can quickly assess the exploit probability of any vulnerability along with their severity, impact, exploit activities, and potential remediation steps on a single platform. This can be a valuable tool for IT and cybersecurity professionals who need to stay informed about any latest vulnerabilities.
SecOps Solution is an agent-less Risk-based Vulnerability ManagementPlatform that helps organizations identify, prioritize and remediate securityvulnerabilities and misconfigurations in seconds.
To schedule a demo, drop us a note at hello@secopsolution.com
.jpg)
