Notifications
Clear all
Topic starter
14/09/2026 10:09 am
TL;DR: CVSS-only triage breaks down as FIRST projects roughly 66,000 CVEs in 2026, according to ArmorCode, because severity scores cannot separate exploitable production exposure from low-risk noise. Risk-based vulnerability management becomes the practical answer when remediation capacity, business context, and attackability all have to be weighed together.
NHIMG editorial — based on content published by ArmorCode: Building a Risk-Based Vulnerability Management Program for 2026
Questions worth separating out
Q: How should teams prioritise cloud vulnerabilities when CVSS and business risk do not match?
A: Use CVSS only as an initial severity label, then reorder findings by asset criticality, exploitability, runtime reachability, and attack-path exposure.
Q: Why do high CVSS scores often fail to reflect real business risk?
A: CVSS measures technical severity, but it does not know whether a vulnerable system is business-critical, internet-facing or protected by segmentation.
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
- Map remediation priority to exploitability and reachability Rank findings only after combining exploitability signals, external exposure, and whether the vulnerable code path is actually active at runtime.
- Tie business context to each critical asset Tag internet-facing services, payment flows, and privileged administrative systems so the same CVSS score does not drive identical SLA treatment.
- Separate low-value noise from production risk Create routing rules that push isolated, dead-code, or non-production findings into a lower-priority workflow with explicit compensating control checks.
What's in the full article
ArmorCode's full blog covers the operational detail this post intentionally leaves for the source:
- How its Context Risk Graph aggregates scanner, asset, threat, and cloud signals into a single prioritisation view
- How Anya Agents route findings into remediation workflows with ownership and SLA handling
- How composite scoring is applied to vulnerability chains, exploitability clusters, and attack paths
- How customers use the platform to measure MTTR by risk tier instead of by blended averages
👉 Read ArmorCode's blog on building a risk-based vulnerability management program for 2026 →
Risk-based vulnerability management at 2026 scale: what changes for teams?
Explore further
14/09/2026 10:10 am
Risk-based vulnerability management is now an exposure governance problem, not a scanner problem. The article is right to treat severity-only triage as structurally inadequate at enterprise scale. When finding volumes rise faster than analyst capacity, the control failure is not missing data but missing decision context. In identity-heavy environments, that context often includes privileged access paths, internet reachability, and whether a weakness can be exercised through a service account or administrative interface. Practitioners should treat prioritisation as a governed control, not an ad hoc queue discipline.
A question worth separating out:
Q: How do IAM and vulnerability teams work together on high-risk findings?
A: They should align on which assets have privileged access paths, SSO dependencies, or service accounts that change the impact of a flaw. A vulnerability on a system with broad access rights can create much more risk than the same flaw elsewhere. Joint review helps separate technical severity from actual blast radius.
👉 Read our full editorial: Risk-based vulnerability management is becoming mandatory at 2026 scale
