Severity scores quantify the maximum damage a flaw could cause if triggered, while exploitability assesses the practical difficulty of triggering it. You must weigh both factors to prioritise remediation efforts effectively. High severity with low exploitability often ranks lower than moderate severity with high exploitability in real-world risk assessments.
The Disconnect Between Score and Reality
Security tools frequently report vulnerabilities using numeric scores that seem definitive. These scores, often derived from the Common Vulnerability Scoring System, measure the potential impact of a flaw. They assume the worst-case scenario where an attacker has full access to the vulnerable component. This theoretical maximum rarely matches the operational reality of your environment. A score of 9.8 does not mean you face imminent danger. It means the code has a serious defect.
You must separate the defect from the danger. The defect is the code error. The danger is the likelihood of an attacker exploiting that error to achieve their goals. Exploitability bridges this gap. It introduces practical constraints such as network accessibility, required credentials, and the complexity of the attack chain. Without considering exploitability, you treat every theoretical flaw as an immediate emergency. This leads to alert fatigue and wasted engineering time.
The Moving Parts of Risk Assessment
Risk assessment relies on two distinct dimensions. The first dimension is severity. This measures the consequence of a successful attack. It considers confidentiality, integrity, and availability impacts. The second dimension is exploitability. This measures the effort required to achieve the attack. It considers the attack vector, the required privileges, and the user interaction needed.
These dimensions operate independently. A flaw can have catastrophic consequences but require physical access to the server. Another flaw might cause minor data leakage but be exploitable by any unauthenticated visitor. You must evaluate both axes. Ignoring severity leads to accepting dangerous flaws. Ignoring exploitability leads to panic over unreachable flaws. The intersection of these two metrics determines your actual exposure.
| Stage | What happens | Where it can be stopped |
|---|---|---|
| Identification | Scanners detect code patterns or misconfigurations. | False positives are filtered out during initial triage. |
| Severity Scoring | Tools assign a base score based on impact potential. | Contextual data adjusts the score to reflect local topology. |
| Exploitability Assessment | Analysts evaluate access controls and attack complexity. | Network segmentation or WAF rules block the attack vector. |
| Prioritisation | Teams rank issues based on combined risk value. | Remediation efforts focus on high-risk, high-exploitability items. |
Reading the Severity Metric
Severity metrics provide a standardised language for discussing impact. They allow different teams to compare flaws across different systems. However, these metrics often rely on generic assumptions. A base score assumes the vulnerable service is directly accessible from the internet. It assumes no additional authentication is required. It assumes the attacker can run arbitrary code.
You must adjust these assumptions for your specific environment. If the service runs on an internal network, the attack vector changes from "Network" to "Local" or "Adjacent". This adjustment significantly lowers the effective severity. If the service requires multi-factor authentication, the required privileges increase. The score should reflect this added barrier. Static scores ignore these contextual factors. They treat a database exposed to the public web the same as a database hidden behind three layers of firewalls.
Assessing Practical Exploitability
Exploitability looks at the path an attacker must take. It asks whether the attacker can reach the vulnerable code. It asks whether the attacker needs to trick a user into clicking a link. It asks whether the attacker needs to guess a password. A flaw that requires social engineering has lower exploitability than one that can be triggered automatically.
Consider the complexity of the attack. Some flaws require precise timing or specific memory conditions. These are difficult to exploit reliably. Other flaws work every time with a simple request. Reliable exploitation increases the exploitability score. You must also consider the attacker's starting position. An attacker who already has a foothold in your network faces fewer barriers. They can exploit internal flaws with higher success rates.
The Hidden Cost of Pure Severity Sorting
Sorting vulnerabilities by severity alone creates a dangerous illusion of progress. Teams patch the highest scores first. They assume this reduces risk the most. In reality, they may be patching flaws that are impossible to exploit in their current configuration. Meanwhile, lower-severity flaws with high exploitability remain open. These flaws are easier to attack and may provide the initial foothold for larger breaches.
This approach also ignores the concept of attack chains. A low-severity flaw might allow an attacker to read a configuration file. This file might contain credentials for a higher-severity system. The initial flaw has low impact on its own. But it enables access to critical assets. Pure severity sorting misses these dependencies. It treats each flaw in isolation. You must map the connections between flaws to understand the true risk.
See also: Cloud patch management: automating updates without breaking production · Risk-Based Vulnerability Management: Prioritise Fixes That Matter
Applying the Combined Model
To apply this model, you must enrich your vulnerability data. Add contextual information to each finding. Document the network location of the affected asset. List the authentication requirements. Note any compensating controls such as web application firewalls. Use this data to adjust both severity and exploitability ratings.
Create a matrix that plots severity against exploitability. Items in the top-right corner represent high impact and high ease of attack. These require immediate attention. Items in the bottom-left corner represent low impact and low ease of attack. These can be deferred. Items in the other quadrants require nuanced handling. High severity with low exploitability might be accepted as residual risk. Low severity with high exploitability might need quick mitigation to prevent foothold establishment.
A Worked Illustration of Prioritisation
Imagine you have two vulnerabilities. The first is a remote code execution flaw in an internal legacy system. It has a severity score of 9.8. However, the system is not connected to the internet. Access requires physical presence and a specific employee badge. The exploitability is extremely low. The second is a cross-site scripting flaw in a public-facing blog. It has a severity score of 6.1. It allows attackers to steal session cookies. The exploitability is high because any visitor can trigger it.
If you sort by severity, you address the legacy system first. You spend weeks isolating and patching a system that no external attacker can reach. You leave the blog vulnerable. Attackers harvest session cookies and impersonate users. The damage is real and immediate. By weighing exploitability, you prioritise the blog. You mitigate the XSS flaw quickly. You accept the residual risk of the legacy system because the attack path is blocked by physical security.
Integrating with Broader Strategies
This approach aligns with broader security frameworks. It supports responsible disclosure by helping vendors understand which flaws need urgent patches. It complements risk-based vulnerability management by providing a structured way to weigh technical data. It also helps in understanding complex threats like Rowhammer attacks, where physical proximity matters.
You must also consider related vulnerabilities. For instance, insecure file permissions might allow an attacker to escalate privileges after exploiting a low-severity flaw. WordPress theme vulnerabilities often have high exploitability due to their widespread use and public availability. Web cache poisoning can amplify the impact of minor flaws by serving malicious content to many users. NoSQL injection flaws might have different exploitability characteristics depending on the database configuration. Understanding these interactions helps you build a more resilient defence.
Key takeaways
- CVSS base scores often ignore network topology and authentication requirements, inflating perceived risk.
- Exploitability metrics account for the attacker's required privileges and the complexity of the attack vector.
- Combining both dimensions prevents wasting resources on theoretical flaws that cannot be reached from the internet.
Severity measures potential damage while exploitability measures practical access. Prioritise flaws that are both damaging and easy to reach.
Frequently asked questions
How do I calculate exploitability manually?
Evaluate the attack vector, required privileges, user interaction, and attack complexity. Assign a weight to each factor based on your environment's controls.
Does this apply to all types of vulnerabilities?
Yes, but the weight of each factor varies. Network flaws depend heavily on topology. Application flaws depend on input validation and authentication.
How this guide was produced: written by the AppSec Scoop editorial team with AI assistance, checked against the public references listed below, and reviewed when the facts change. See our editorial policy or report an error.
