Vulnerability Severity Ratings: How to Read and Apply Scores
Severity scores measure technical exploitability, not business impact, forcing you to bridge the gap between automated data and actual risk.
Vulnerability severity ratings quantify the difficulty of exploiting a flaw. They rely on standardized metrics like attack complexity and privileges required. These scores help prioritize patching but ignore context like asset value or exposure. You must combine scores with business logic to determine true risk.
What is a vulnerability severity rating?
A vulnerability severity rating is a numerical score that estimates how difficult it is to exploit a specific security flaw. This number allows you to compare different vulnerabilities against a common scale. The score does not tell you whether the vulnerability affects your specific system. It only describes the potential impact if an attacker successfully exploits the flaw.
How are these scores calculated?
Scoring systems use weighted metrics to calculate a final value. Attackers must meet certain conditions, such as requiring network access or user interaction, to exploit the issue. The system subtracts points for higher requirements and adds points for greater impact. Impact includes loss of confidentiality, integrity, or availability of the affected system.
Why do two tools show different scores for the same flaw?
Different tools may use different versions of the scoring methodology. Older methods weighted impact heavily, while newer versions weight exploitability more strongly. Some tools also apply environmental adjustments automatically, while others only show the base score. You must check which version the tool uses to understand the number.
What is the difference between base and temporal scores?
The base score represents the intrinsic severity of the vulnerability across all platforms. It never changes because the flaw itself does not change. The temporal score adjusts the base score based on current factors. These factors include the availability of proof-of-concept exploits and the maturity of the fix.
How do environment factors change the risk?
Environmental scores modify the rating based on your specific infrastructure. You can lower the score if you have compensating controls, such as a firewall blocking the vulnerable port. You can raise the score if the affected asset contains sensitive data. Many automated scanners ignore these factors, leaving you with an incomplete picture.
Does a high score mean I am under attack?
A high score indicates that the flaw is easy to exploit or has severe consequences. It does not mean attackers are currently targeting you. Many high-severity flaws require specific conditions that may not exist in your environment. You should verify exposure before assuming immediate danger.
| Score Range | Technical Meaning | Action Priority |
|---|---|---|
| 9.0 - 10.0 | Critical | Immediate patching or mitigation |
| 7.0 - 8.9 | High | Patch within standard maintenance windows |
| 4.0 - 6.9 | Medium | Plan patching based on asset exposure |
| 0.1 - 3.9 | Low | Address during routine updates |
Why are scores sometimes misleading?
Scores cannot account for business context or unique application logic. A low-severity flaw in a public-facing login page may be more dangerous than a high-severity flaw in an internal tool. Automated scores also miss business logic flaws because they cannot understand intent. You must review how the application functions to spot these gaps.
How do I handle zero-day vulnerabilities?
Zero-day vulnerabilities have no known fix and often lack an official score. You must assess the risk manually based on the affected component. If the component is exposed to the internet, treat it as critical. Implement temporary controls, such as input validation or output encoding, to reduce the attack surface.
Should I prioritize by score or by asset value?
You should prioritize by a combination of both. A high score on a non-critical server is less urgent than a medium score on a database holding customer records. Review your inventory to identify which systems hold sensitive data. Focus your resources on protecting those high-value assets first.
How do I track fixes for scored vulnerabilities?
You need a systematic approach to track when vendors release patches. Automated scanners will flag the vulnerability until the fix is applied. You must verify that the patch resolves the issue and does not introduce new problems. Refer to guides on change management for security patches to implement this process safely.
What if the vendor says the score is wrong?
Vendors may dispute scores if they believe the flaw is not exploitable in practice. However, the scoring system is public and standardized. You cannot change the official score, but you can adjust your internal risk rating. Document your reasoning for accepting or declining the risk. This documentation helps auditors understand your decision-making process.
How do scores relate to exploit availability?
The availability of code to exploit the flaw affects the temporal score. When proof-of-concept exploits appear online, the risk of exploitation increases. Attackers do not need to write their own tools. This makes the vulnerability more likely to be tested against your systems. You should monitor security feeds for new exploit code.
Can scores predict attack success?
No, scores predict difficulty, not success. An attacker might fail to exploit a high-severity flaw due to poor skill or bad luck. Conversely, they might succeed with a low-severity flaw if they have insider access. Scores are a starting point for triage, not a guarantee of safety. You must layer defenses to reduce the chance of success.
How do I explain scores to non-technical stakeholders?
Translate scores into business risk rather than technical metrics. Explain that a high score means the door is wide open and easy to kick in. A low score means the door is locked but might have a weak lock. Focus on the potential impact to revenue or reputation. This helps stakeholders understand why immediate action is needed for certain flaws.
What about vulnerabilities in custom code?
Custom code often lacks official severity scores. You must assess these flaws using the same metrics as the scoring system. Consider attack vector, privileges required, and impact. Treat un-scored flaws as high risk until you can verify their severity. This prevents attackers from targeting your unique applications.
How do I handle complex dependencies?
Modern systems rely on many third-party components. Each component may have its own vulnerabilities and scores. You must track the versions of all dependencies. Use a software bill of materials to list every component. This helps you identify which vulnerabilities affect your specific stack.
What is the role of human judgment?
Human judgment bridges the gap between automated scores and real-world risk. Tools can miss context, such as whether a service is internet-facing. You must review the environment and the data at risk. Combine this context with the score to make informed decisions. This ensures you are patching what matters most.
Key takeaways
- Base scores measure intrinsic flaw severity, ignoring your specific environment.
- Environmental scores adjust for mitigations, but vendors often omit this data.
- High severity does not always mean immediate danger if exploitation requires rare conditions.
Severity scores are tools for triage, not measures of actual business risk. Combine these scores with an understanding of your environment and asset value to prioritize effectively.
Frequently asked questions
Can I ignore low-severity vulnerabilities?
You should not ignore them entirely. Low-severity flaws can be chained with other issues to create a critical path for attackers.
Do all scoring systems use the same scale?
Most systems use a 0 to 10 scale, but the weighting of metrics may vary between versions. Check the methodology used by your scanner.
How often are severity scores updated?
Scores are updated when new information becomes available, such as exploit code or patches. Vendors may also update scores based on user feedback.
Is a higher score always worse?
A higher score indicates greater potential impact or easier exploitation. It does not account for your specific defenses or exposure.
How this guide was produced: written by the RedTeam Tribune 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.
