Notifications
Clear all
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.
NHIMG editorial — based on content published by ArmorCode: Vulnerability Risk Scoring: Why CVSS Alone Isn’t Enough Blog
By the numbers:
- An enterprise with 600 developers and 5 AppSec engineers reported reducing security team triaging effort by 90% after implementing normalized risk-based scoring across its scanning ecosystem.
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.
Questions worth separating out
Q: How should security teams prioritise patches when CVSS no longer drives the schedule?
A: Start with exploitability, exposure, and business impact.
Q: When does a lower-severity vulnerability become the higher-priority fix?
A: A lower-severity issue becomes higher priority when it is exposed to the internet, connected to sensitive data, reachable through privileged access, or already being exploited in the wild.
Q: What do security teams get wrong about vendor risk scoring?
A: The common mistake is treating the score as documentation instead of a decision trigger.
Practitioner guidance
- Replace severity-only queues with contextual risk bands Define remediation bands using exposure, data sensitivity, business criticality, and privilege reach so a low-scored flaw in a critical production path is not buried behind noisy high-severity findings.
- Weight internet-facing and privileged assets first Apply higher urgency to vulnerabilities on externally reachable systems, identity-linked services, and workloads that can access secrets or regulated data, because those issues create the fastest blast radius.
- Inject active exploitation into escalation rules Automatically raise priority when a vulnerability appears in known exploited catalogs, exploit frameworks, or threat intelligence feeds, even if its base CVSS score has not changed.
What's in the full article
ArmorCode's full blog covers the operational detail this post intentionally leaves for the source:
- Adaptive Risk Scoring workflow logic for combining CVSS, exploitability, and asset tags
- Exception Management module behaviour for documenting deferred remediation and approvals
- Runbook and automation examples for turning risk thresholds into tickets, owners, and SLA enforcement
- Asset-centric weighting approach for exposure, sensitivity, and business criticality
👉 Read ArmorCode's blog on why CVSS alone is not enough for vulnerability prioritisation →
CVSS prioritization: what security teams need to change now?
Explore further
19/08/2026 4:36 pm
CVSS-only prioritisation creates a context gap, not a measurement problem. Security teams do not fail because they cannot score vulnerabilities; they fail because the score does not encode exposure, privilege, or business criticality. That gap becomes decisive when the vulnerable asset sits on a production path, supports regulated data, or influences identity and access flows. The practical conclusion is that severity must be subordinate to business context, not the other way around.
A question worth separating out:
Q: Who should own risk-based remediation decisions?
A: Vulnerability prioritisation should be shared between security, asset owners, and operations because context lives in the business, not only in the scanner. Security can define the scoring model, but asset owners must confirm criticality, exposure, and exception handling so remediation reflects real operational risk.
👉 Read our full editorial: Why CVSS alone fails risk-based vulnerability prioritization
