The vulnerability scanners can generate thousands of findings. But with just severity information, teams can not decide - what to fix first. A better and accepted approach is to combine multiple risk signals such as CVSS, EPSS, KEV, DREAD, pentesting, and business context.
Do you remember Log4Shell (CVE-2021-44228)?
NIST rated the vulnerability as 10.0 Critical on CVSS v3.1. This was because it had potential for remote code execution (RCE). But organizations still checked on their end which systems were actually vulnerable, whether they were exposed, whether exploitation actually occurred, and what business impact it could have.
Together, these factors helped security teams prioritize this vulnerability based on actual risk.
Vulnerability severity means how serious the potential security impact of a vulnerability is.
Most security programs use these categories:
|
Severity |
Meaning |
|
Informational |
Security observation without a direct exploitable impact |
|
Low |
Limited security impact or a difficult exploitation |
|
Medium |
Meaningful security weakness with restricted impact |
|
High |
Significant compromise or data exposure is possible |
|
Critical |
Severe compromise, major data exposure, or system control may be possible |
However, severity should not automatically be interpreted as business risk. Let us see why.
Severity describes how serious a vulnerability is. Risk describes how much that vulnerability matters in a specific environment.
For example, a critical vulnerability in an isolated development server may pose less immediate risk than a high-severity authorization flaw in a production application containing sensitive customer information.
A vulnerability risk score is a numerical representation of the risk associated with a security weakness.
Risk assessment typically considers two fundamental questions:
How likely is the vulnerability to be exploited?
and
What happens if it is exploited?
Simply put: Risk = Likelihood × Impact
However, organizations may consider additional factors as well:
So, a raw vulnerability score should not automatically determine remediation order.
CVSS is a standardized framework to communicate the severity of vulnerabilities.
CVSS ranges from 0.0 to 10.0.
|
CVSS Score |
Rating |
|
0.0 |
None |
|
0.1–3.9 |
Low |
|
4.0–6.9 |
Medium |
|
7.0–8.9 |
High |
|
9.0–10.0 |
Critical |
CVSS evaluates characteristics of a vulnerability such as attack complexity, privileges required, user interaction, and potential impact.
CVSS is particularly useful when organizations need a consistent way to compare technical vulnerability severity across systems and products.
However, a CVSS score is not the same as an organization's actual business risk.
The same vulnerability can have different levels of risk depending on where it exists and what it protects.
CVSS v4.0 provides a more detailed framework for vulnerability assessment.
It separates different aspects of vulnerability characteristics and allows organizations to incorporate environmental context.
For example, there is a vulnerability affecting:
The technical vulnerability may be identical. But its organizational risk can be very different.
Therefore, security teams should combine standardized severity with environmental context.
Security teams often make the mistake of sorting findings from 10.0 downward and fixing them in that order.
A better approach considers additional context:
DREAD is an older risk-rating model that evaluates vulnerabilities across five dimensions:
The model was designed to provide a broader assessment than simply asking how technically severe a vulnerability was. Here is a detailed description of risk rating and DREAD score:
A security team might evaluate a vulnerability as:
|
Factor |
Score |
|
Damage |
8 |
|
Reproducibility |
9 |
|
Exploitability |
7 |
|
Affected Users |
8 |
|
Discoverability |
6 |
The organization can then calculate an overall score according to its selected methodology.
CVSS provides a more standardized approach to vulnerability severity. On the other hand, DREAD measures and considers broader risk dimensions.
Note: For modern vulnerability management programs, organizations should be clear about which methodology they use. They should avoid treating scores from different frameworks as directly interchangeable.
EPSS (Exploit Prediction Scoring System) answers a different question from CVSS.
CVSS asks: How severe is the vulnerability?
EPSS asks: How likely is the vulnerability to be exploited?
This difference is extremely useful for vulnerability prioritization.
A vulnerability can have a high CVSS score but a low probability of exploitation.
Another vulnerability may have a lower CVSS score but a higher chance of exploitation.
|
Area |
CVSS |
EPSS |
|
Primary purpose |
Measures severity |
Estimates exploitation probability |
|
Focus |
Vulnerability characteristics |
Likelihood of exploitation |
|
Score |
0–10 |
Probability-based |
|
Key question |
How serious? |
How likely to be exploited? |
Neither replaces the other. CVSS tells you about severity. EPSS adds information about exploitation likelihood.
Another important prioritization signal is whether a vulnerability is known to be exploited in the wild.
The CISA Known Exploited Vulnerabilities (KEV) Catalog tracks vulnerabilities that have evidence of active exploitation. This provides a practical signal: Is this vulnerability merely theoretically exploitable, or are attackers already using it?
A vulnerability with high severity, high exploitation probability, and confirmed inclusion in the KEV Catalog may deserve substantially higher remediation priority than a vulnerability that has never been observed being exploited.
Automated scoring cannot always determine the real-world consequences of a vulnerability.
This is where penetration testing adds important context.
A pentester can validate:
A typical assessment considers exploitability, technical impact, authentication requirements, privileges required, affected assets, data sensitivity, business impact, and attack-chain potential.
This produces a risk assessment grounded in observed attack behavior, rather than theoretical severity alone.
Note: Exact severity definitions vary by testing methodology and organization.
These two ratings can differ, and that is fine.
For example, imagine a vulnerability with a CVSS score of 7.5.
During a penetration test, the tester discovers that the vulnerability can be combined with another weakness to bypass authorization, access an administrative function, extract customer records, and then move into an internal system.
The pentester may therefore assign the finding a higher business risk than its standalone CVSS score suggests.
This illustrates an important principle: A vulnerability should be evaluated both individually and as part of the broader attack path.
Security teams can combine multiple signals instead of relying on one score.
|
Signal |
Question |
|
CVSS |
How severe is the vulnerability technically? |
|
EPSS |
How likely is exploitation? |
|
KEV |
Is it already being exploited? |
|
Asset criticality |
How important is the affected system? |
|
Business impact |
What happens if it is compromised? |
|
Pentest evidence |
Can it actually be exploited? |
|
Attack path |
Can it be chained with other weaknesses? |
This creates a more complete risk picture.
|
Scoring System |
Measures |
Answers |
How it Helps Prioritize |
|
CVSS |
Technical vulnerability severity |
How severe is the vulnerability? |
Provides a standardized severity score based on factors such as exploitability and potential impact. |
|
EPSS |
Exploitation probability |
How likely is it to be exploited? |
Adds an exploitation-likelihood signal that CVSS does not provide. |
|
CISA KEV |
Confirmed exploitation |
Is it being exploited in the wild? |
Highlights vulnerabilities with evidence of active exploitation, making them higher-priority candidates. |
|
DREAD |
Risk across five dimensions |
How damaging and exploitable could this vulnerability be? |
Considers Damage, Reproducibility, Exploitability, Affected Users, and Discoverability. |
|
Pentest Severity |
Real-world exploitability and impact |
What can an attacker actually achieve? |
Uses hands-on testing to validate exploitation, attack paths, privilege escalation, data access, and business impact. |
When a vulnerability is disclosed and receives a CVE, it may be accompanied by a CVSS score that communicates its technical severity. NVD (National Vulnerability Database) explains that CVSS is a measure of severity, not risk, and that its scores range from 0 to 10.
But the risk picture can change, for example:
Day 1: A newly disclosed vulnerability receives a CVSS score of 8.8 (High).
Later: A working public exploit becomes available, increasing concern about exploitation.
As Exploitation Data Changes: Its EPSS score can change because EPSS estimates the probability of exploitation in the wild over the following 30 days.
If Active Exploitation is Confirmed: The vulnerability may appear in CISA's Known Exploited Vulnerabilities (KEV) Catalog, making it a much higher remediation priority. NVD incorporates KEV information into its CVE data.
Within an Organization: A pentest or internal assessment may reveal that the vulnerability provides a path to sensitive data or privileged access, further changing its business risk.
1. Do Not Rely on Just CVSS: Use technical severity with environmental and business context.
2. Check Exploit Likelihood: EPSS can provide additional information about exploitation probability.
3. Monitor Any Active Exploitation: Known exploitation should influence remediation priority.
4. Validate Vulnerabilities: Where possible, confirm whether a vulnerability can actually be exploited.
5. Consider All Attack Chains: Multiple lower-severity weaknesses can create a serious attack path.
6. Prioritize Critical Assets First: A vulnerability affecting a critical production system deserves more attention than the same vulnerability on an isolated asset.
7. Re-test the Fixes: A finding should not simply be marked resolved. Validate that the vulnerability has actually been closed.
For penetration testing, the goal should not be to produce a spreadsheet containing hundreds of scores.
The goal is to help security teams understand which weaknesses matter, how they can be exploited, and what attackers could achieve.
Siemba's expert-led penetration testing can validate vulnerabilities and investigate how they connect across applications, MCP servers, AI agents and chatbots, LLMs, or APIs, and other infrastructure.
This can help organizations move from:
“We have 200 vulnerabilities.”
to:
“These five attack paths represent the greatest risk to our business.”
Findings can then be independently re-tested after remediation to verify that vulnerabilities have actually been addressed because with Siemba's PTaaS, remediation doesn't end when a finding is marked "resolved."
Ready to see how your security holds up against an attacker? Book a demo with Siemba.
No. CVSS provides a standardized measure of vulnerability severity. A broader risk score may incorporate business impact, asset criticality, exploitation likelihood, and other environmental factors.
They answer different questions. CVSS measures severity, while EPSS estimates exploitation probability. Using both can provide a more useful basis for prioritization.
Not necessarily. Remediation priority should also consider asset exposure, business impact, exploitation activity, existing controls, and attack-chain potential.
Yes. A vulnerability's practical risk can increase significantly when it is combined with other weaknesses, affects a critical asset, or provides a path to sensitive data or privileged access.