Topic starter
19/08/2026 3:59 pm
TL;DR: CVSS-based scoring reduces vulnerabilities to theoretical severity, so ArmorCode argues teams end up chasing “critical” labels while business-relevant exposure is left behind. The real shift is toward contextual risk scoring that combines exploitability, asset exposure, data sensitivity, and active threat intelligence.
Editorial analysis by NHI Mgmt Group, based on content published by ArmorCode: “Vulnerability Risk Scoring: Why CVSS Alone Isn’t Enough”.
Key questions
Q: Why does CVSS alone create weak vulnerability prioritisation for modern security teams?
A: CVSS measures severity, but severity is only one part of real risk.
Q: Why should security teams combine exploit intelligence with vulnerability scoring?
A: Because static scores age quickly while attacker behaviour changes continuously.
Q: What are the signs that a vulnerability prioritization model is failing?
A: The clearest signs are long delays on known exploited vulnerabilities, tickets that lack ownership, duplicate findings across tools, and high-severity work that never maps to real attack paths.
Practitioner guidance
- Define contextual risk inputs for every asset Record exposure, data sensitivity and business criticality for assets that receive vulnerability findings so scoring reflects the environment, not just the flaw.
- Separate active exploitation from static severity Escalate findings with proof-of-concept code, weaponised exploits or confirmed exploitation in threat feeds, even when base severity is not extreme.
- Normalise findings across scanners Map findings from SAST, DAST, SCA, cloud scanners and infrastructure tools into one risk model so they can be compared consistently.
Bottom line: CVSS alone is a severity signal, not a business-risk model, so it cannot tell teams which vulnerabilities deserve immediate attention.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
19/08/2026 4:36 pm
Context-less severity creates prioritisation debt: CVSS-only programmes accumulate a backlog of technically labelled problems that do not map cleanly to business risk. The result is remediation effort spent on the loudest score rather than the most consequential exposure. This is a governance failure, not a tooling failure, because the organisation has no contextual decision model. Practitioners should treat prioritisation debt as a measurable risk in its own right.
A few things that frame the scale:
- The average time to mitigate a leaked secret is 36 hours, highlighting the operational burden of manual remediation processes, according to the 2024 State of Secrets Management Survey.
- The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to the State of Secrets in AppSec.
A question worth separating out:
Q: How should teams govern vulnerability exceptions without losing accountability?
A: Use a formal exception process that records why remediation is deferred, what compensating controls are in place, who approved the decision and when it must be reviewed. That keeps risk decisions auditable instead of letting unresolved findings disappear into the backlog.
👉 Read our full editorial: Why CVSS alone fails risk-based vulnerability prioritization