Notifications
Clear all
Topic starter
18/08/2026 2:21 pm
TL;DR: CVSS-only triage leaves AppSec teams chasing volume instead of exploitable risk, as more than 48,000 CVEs were published in 2025 and roughly 3% of vulnerabilities account for 80% of exploitation activity, according to ArmorCode. The practical shift is toward exposure management, where reachability, business context, and automated routing decide what gets fixed first.
NHIMG editorial — based on content published by ArmorCode: Managing Application Security Vulnerabilities: Moving Beyond the CVE Backlog
By the numbers:
- Research on EPSS and CISA KEV data consistently shows that roughly 3% of vulnerabilities account for 80% of actual exploitation activity.
Questions worth separating out
A: Prioritise by exploitability, exposure, and business impact, not by severity alone.
Q: Why do application vulnerabilities become more dangerous when identity controls are weak?
A: A reachable flaw becomes much more damaging when it sits near privileged service accounts, exposed APIs, or leaked secrets.
Q: What do security teams get wrong about vulnerability management in complex environments?
A: They often treat the software flaw as the whole problem.
Practitioner guidance
- Normalize findings into one exposure model Consolidate SAST, DAST, SCA, CSPM, API, and secrets findings into a single deduplicated queue so each issue carries one owner, one severity view, and one remediation path.
- Prioritise by exploitability, not score alone Blend CVSS with EPSS, CISA KEV, reachability, asset sensitivity, and internet exposure before setting remediation order, especially for internet-facing APIs and authentication paths.
- Bind application risk to access governance Review whether vulnerable services sit behind standing privilege, over-permissive IAM roles, or unmanaged secrets, because those conditions convert routine flaws into high-impact access events.
What's in the full article
ArmorCode's full blog covers the operational detail this post intentionally leaves for the source:
- A full explanation of how its Context Risk Graph correlates scanner data with runtime and asset context for prioritisation
- Implementation detail on workflow routing to Jira, Slack, Teams, and CI/CD so findings reach the right engineering owner
- Examples of how AI workers are grounded in the platform's findings, threat intel, and documentation context
- The article's walkthrough of reducing mean time to remediation from 240 days to 7 days through workflow automation
👉 Read ArmorCode's analysis of moving beyond the CVE backlog →
CVE backlog triage is failing teams, so what should replace it?
Explore further
18/08/2026 3:13 pm
Exposure management is becoming the operating model AppSec actually needs. The article shows that the bottleneck is no longer discovery, but deciding what is truly exploitable in a live environment. That is a governance problem, not just a tooling problem, because the organisation must correlate scanner output, asset criticality, runtime context, and exploit intelligence before engineering sees the ticket. Teams that keep using CVSS as the primary decision rule will continue to misplace effort.
A question worth separating out:
Q: Which frameworks help teams move from vulnerability management to exposure management?
A: NIST CSF and NIST SP 800-53 help structure governance, while EPSS and CISA KEV inform exploitability. For application and dependency risk, CTEM-style processes work best when paired with runtime context, asset criticality, and automated ticket routing to engineering owners.
👉 Read our full editorial: Beyond the CVE backlog: why AppSec needs exposure management
