The rating systems for identifying security vulnerabilities and assessing threat risk need to be overhauled, Aram Hovespyan, co‑founder and CEO of Codific, warned — a blunt diagnosis that resonates in security operations centers and executive briefings. The issue he points to is not primarily technical failure, but a failure of signals: the numbers meant to guide scarce resources are often misunderstood, gamed, or simply ill‑suited for the job. That flawed signal—often the Common Vulnerability Scoring System—too frequently becomes the decision rather than a starting point for thoughtful risk management.
Common Vulnerability Scoring System: why a single number falls short
For more than a decade the Common Vulnerabilities and Exposures (CVE) list and the Common Vulnerability Scoring System (CVSS) have been staples of vulnerability management. CVE assigns identifiers to disclosed flaws; CVSS translates those flaws into numerical scores intended to reflect severity and help organizations prioritize patching. The simplicity is seductive: if vulnerability A scores 9.8 and B scores 5.6, patch A first. In practice, that arithmetic collapses under complexity.
CVSS was designed to provide a consistent baseline, but it was never meant to capture exploitability trends, attacker intent, network topology, or business impact — the context that determines whether a vulnerability actually leads to an incident. Treating the Common Vulnerability Scoring System as the definitive guide encourages rote triage and masks real‑world risk.
Common complaints from practitioners illustrate why the score misleads:
– A single axis for diverse realities. A high base score reflects technical severity in a vacuum, not the likelihood of exploitation in a given environment. A critical flaw in an isolated appliance can receive the same score as a wormable bug in internet‑facing servers, but operational priorities differ wildly.
– Noisy and inconsistent scores. Different vendors and databases may assign different CVSS vectors or base scores to the same CVE. The National Vulnerability Database (NVD), MITRE, and other feeds sometimes diverge because of interpretation differences or incomplete information.
– Perverse incentives. Vendors often downplay risk to protect reputations; researchers may emphasize impact to attract attention. Security teams under time pressure may ingest automated feeds without contextual analysis, letting imperfect numbers decide remediation priorities.
These are not academic complaints. Studies and reporting show mismatches between assigned scores and observed exploitation. Many high‑scoring vulnerabilities never become weaponized; conversely, widespread, lower‑scoring flaws frequently underpin major incidents. Attackers pick high‑reward, low‑effort paths — a calculus that hinges more on exploit availability, ease of chaining, and business context than on a CVSS base score.
Better use of CVSS: integrate context, threat intelligence, and asset value
FIRST, the organization that maintains CVSS, and the wider community have introduced temporal and environmental modifiers to make scores more actionable. But many organizations ingest only base scores from feeds like the NVD, ignoring temporal factors (exploit code availability) and environmental factors (asset criticality) that could materially change priorities.
Policymakers and executives understandably want a universal metric. CVSS offers a tidy, reportable number that boards and regulators can measure and compare. But this convenience risks incentivizing good‑looking metrics over genuine risk reduction. A report that shows how many critical CVEs were patched last quarter may look impressive while leaving real exploitable paths open.
Technologists and threat teams argue for richer contextualization. Practical improvements include:
– Integrating exploit and threat intelligence: Real‑time indicators of active exploitation should feed prioritization pipelines so teams address the vulnerabilities attackers are actually using.
– Improving metadata and provenance: Standardized, richer descriptions of affected configurations and exploitability reduce interpretation variance across feeds.
– Shifting incentives for transparency: Policies and incentives that encourage vendors and researchers to share timely, detailed technical information — without fear of reputational or regulatory backlash for higher severity ratings — would improve the ecosystem.
– Moving to contextualized risk scores: Combine CVSS with asset criticality, exposure, business impact, and existing mitigations to produce organization‑specific priorities rather than one‑size‑fits‑all rankings.
None of these fixes are trivial. They require coordination among standards bodies like FIRST, vendors, researchers, government agencies, and commercial vulnerability feeds. They also require cultural change inside security teams: accepting that a score should start a conversation, not end it.
Practical obstacles: data quality, latency, and scale
Operationally, three recurring issues make reliance on a single score risky:
– Data quality. CVE entries can be incomplete. Critical exploitability details may not appear until vendors publish advisories or proof‑of‑concept code is released.
– Latency. It can take days or weeks for additional context — POCs, exploit kits, vendor patches — to surface, during which static scores can mislead prioritization.
– Scalability. Large organizations manage tens of thousands of assets and thousands of CVEs monthly. Human review for each item is impossible; automation without nuance produces poor prioritization at scale.
Adversaries exploit these weaknesses. Predictable, score‑driven prioritization creates blind spots attackers can weaponize. They deliberately target overlooked, lower‑scoring but widely deployed weaknesses, or design campaigns that exploit the gaps between scoring and real operational exposure.
Conclusion: use the Common Vulnerability Scoring System as a starting point, not a verdict
The Common Vulnerability Scoring System remains a useful tool when used properly: it provides a consistent baseline, helps categorize technical severity, and enables reporting. But left uncontextualized, it misleads. Security teams should treat CVSS as the opening move in a broader, context‑rich process that blends threat intelligence, asset value, exposure, and mitigation state. Regulators and boards should avoid metrics that reward tidy numbers over actual security posture. Only by evolving CVSS into part of an ecosystem that values context, transparency, and timely intelligence can organizations stop chasing high scores while attackers walk through unguarded doors. A single number will never be enough to keep us safe — but a better conversation about risk will.
