Key Takeaways
- CVSS tells you how bad a flaw could be. It says nothing about whether anyone is actually going after it.
- A real vulnerability risk scoring framework blends severity, exploit likelihood, and business context into one number your team can act on.
- Asset criticality, attack surface, cloud exposure, and internet facing status all change what “high risk” means for a specific vulnerability in your environment.
- CISA KEV and EPSS exist because CVSS alone was never built to answer “what should I fix today.”
- Secure.com’s Infrastructure Security Teammate applies this kind of layered scoring automatically, inside the scope and approvals your team sets.
More than 48,000 CVEs were published in 2025, a 21% jump from the year before, and that pace has only picked up in 2026<cite index=”26-1″>since 48,185 CVEs were published in 2025, a 20.6% increase from 2024’s 39,962</cite>. Most security teams cannot patch a fraction of that. If your process still ranks vulnerabilities by CVSS score alone, you are not prioritizing. You are just sorting a spreadsheet.
What Is a Vulnerability Risk Score
A vulnerability risk score is a number meant to answer one question: how urgently does this specific flaw, on this specific asset, in this specific environment, need to get fixed. That sounds simple. It rarely is, because most teams still calculate it using one input: CVSS.
CVSS was built to measure severity, not urgency. It looks at things like attack complexity and potential impact and produces a score from 0 to 10. What it does not look at is whether anyone is actually exploiting that flaw right now, whether the affected system is exposed to the internet, or whether it even matters to your business. <cite index=”6-1″>CVSS measures the severity of a vulnerability based on static characteristics, while EPSS predicts the likelihood it will be exploited, so CVSS tells you how bad it could be and EPSS tells you how likely it is to happen</cite>.
So how does vulnerability scoring without context mislead remediation teams? A scanner hands you a list of 400 “critical” CVEs. Your team can realistically close 40 this month. If severity is the only filter, you end up patching low-risk systems while a moderately scored but actively exploited flaw sits untouched on an internet-facing server. The backlog does not shrink. It just moves around.
The NVD backlog makes this worse. Only 28% of CVEs disclosed in 2025 received full NVD enrichment<cite index=”27-1″>since a record 48,185 CVEs were published in 2025 while the NVD analysis backlog meant only 28% of those received full enrichment</cite>. If your framework leans on NVD data alone to fill in severity, a growing share of your vulnerabilities show up with incomplete or delayed scores. That is not a small gap. It is a blind spot that grows every quarter.
How to Build a Vulnerability Risk Scoring Framework
A working framework does not throw out CVSS. It stops treating CVSS as the whole answer and starts stacking other signals on top of it. Here is the order that holds up in practice.
1. Start with severity, but treat it as a floor, not a verdict. Pull the CVSS base score for every finding. Use it to sort the noise, not to make the final call.
2. Add exploit likelihood with EPSS. EPSS estimates the probability a vulnerability will be exploited in the next 30 days, on a scale from 0 to 100%. <cite index=”5-1″>The EPSS model assigns a score between 0 and 1, corresponding to the likelihood that a vulnerability will be exploited within 30 days, with scores closer to 1 indicating a higher probability of exploitation</cite>. A finding with a mid-range CVSS score and a high EPSS score deserves attention sooner than a “critical” CVE nobody is actively targeting.
3. Cross-check against CISA KEV. The Known Exploited Vulnerabilities catalog lists CVEs with confirmed, real-world exploitation. If something on your list is already in CISA’s KEV catalog, it moves to the top regardless of what CVSS says.
4. Layer in asset and environmental context. This is the step most teams skip, and it is the one that changes the answer the most. More on this below.
5. Assign a composite risk score and route it. Combine the layers above into one score your team can act on, then route the ticket to the right owner with an SLA attached. A score that does not lead to a routed, owned action is just a report nobody reads.
Do this once and it looks like a project. Do it as a standing process and it becomes the backbone of how your team decides what gets fixed this week, this sprint, this quarter.
The Context Layers That Make a Score Actually Mean Something
Two organizations can have the exact same CVE, the exact same CVSS score, and completely different real risk. The difference is context. Here are the four layers that matter most.
Asset Context: What a Server Is Actually Worth
Not every server carries the same weight. A flaw on a decommissioned test box is not the same problem as the identical flaw on your production database. Asset criticality asks a simple question: if this system went down or got compromised, what would it cost you.
How to apply asset context to vulnerability risk scoring comes down to your inventory. You need it tied to business function, not just a hostname list. Tag systems by what they touch: customer data, payment flows, authentication, source code. A vulnerability on a high-value asset should always outrank the same vulnerability on a low-value one, even if the CVSS score is identical.
Attack Surface: What an Attacker Can Actually Reach
Attack surface is everything an attacker could actually reach and try to use. A vulnerability buried three network hops behind a firewall, with no direct path in, carries different real-world risk than the same flaw sitting on a system an attacker can reach in one step.
How does attack surface affect vulnerability risk scoring? It shifts the priority toward reachability, not just theoretical severity. Mapping attack paths, not just individual assets, shows you which vulnerabilities sit on an actual route to something valuable.
Cloud Context: Same CVE, Different Blast Radius
Cloud environments move fast, and that speed changes how a vulnerability behaves. A misconfigured storage bucket or an overly permissive IAM role can turn a moderate vulnerability into a direct path to sensitive data.
How does cloud context change vulnerability risk scores? The same CVE can carry low risk in one account and critical risk in another, depending on what it sits next to. Cloud context also means accounting for ephemeral assets. A container that spins up and down in minutes still needs to be scored while it exists, not ignored because it will not be there tomorrow.
Internet Exposure: The Multiplier Most Teams Underweight
An internet-facing asset is reachable by anyone, anywhere, at any time. That single fact should raise the risk score of almost anything running on it. Internally-facing systems still matter, but they require an attacker to already have a foothold first.
How does internet exposure affect vulnerability risk scores? It removes the barrier an attacker would otherwise need to clear, which is why exposure belongs in the formula and not as an afterthought.
Put these four layers together and you get something CVSS alone was never designed to produce: a score that reflects what could actually happen to your specific environment, not just what could theoretically happen to any environment running that software.
Where Secure.com’s Infrastructure Security Teammate Fits In
Building this framework by hand is doable. Keeping it current every day, across every scanner, every cloud account, and every asset change, is where most teams fall behind. That is the gap the Infrastructure Security Teammate is built to close.
It pulls in CVSS, EPSS, and CISA KEV data alongside your actual asset inventory, cloud posture, and exposure status, then produces a composite risk score per finding instead of a flat severity list. From there it can open the ticket, route it to the right owner, and keep the evidence trail so your next audit is not a scramble.
That is the idea behind Governed Defense, Powered by Offense. Your team sets the scope, the permissions, and the approvals. The teammate does the recurring work: pulling context, scoring, routing, and proving the fix landed. Nothing here augments your team. It gives them back the hours that used to go into stitching CVSS, EPSS, and asset spreadsheets together by hand.
If you already have a prioritization process and want to see how the scoring and routing pieces connect, our post on exposure prioritization in practice walks through the decision logic step by step. And if ticketing and patch workflows are your current bottleneck, how to automate vulnerability management covers what to hand off first.
FAQs
Is EPSS meant to replace CVSS?
How often should a vulnerability risk score be recalculated?
Do small security teams need all four context layers, or just CVSS and EPSS?
What is the biggest mistake teams make when building a scoring framework?
Conclusion
A vulnerability risk score is only useful if it changes what your team does next. Severity alone will not get you there. Exploit likelihood, real-world exploitation data, and the context of your own environment will. Build the layers in that order, tie the output to an owner and a deadline, and the backlog stops being a wall of red numbers and starts being a list your team can actually work through.
