Notifications
Clear all
Topic starter
10/07/2026 9:21 pm
TL;DR: Vulnerability remediation time worsened from 171 days in 2020 to 252 days in 2025, while Verizon’s DBIR tracked 22,052 incidents and 12,195 confirmed breaches and found vulnerability exploitation as an initial-access vector tripled in two years, according to JupiterOne and cited research. The issue is not prioritisation alone but the industry’s fixation on finding-level work instead of exposure paths and closure outcomes.
NHIMG editorial — based on content published by JupiterOne: The Vulnerability Management Industrial Complex
By the numbers:
- In 2020, the average time to remediate a software vulnerability was 171 days.
- In 2025 it was 252 days, a 47% increase in five years.
Questions worth separating out
Q: How should security teams measure whether vulnerability management is actually reducing risk?
A: Security teams should measure exposure reduction, not just remediation activity.
Q: Why do identity and privilege controls matter in vulnerability management?
A: Identity and privilege controls determine whether a vulnerability is reachable and exploitable.
Q: What do teams get wrong when they prioritise vulnerabilities only by score?
A: They assume a high score equals the right work.
Practitioner guidance
- Shift the primary metric from tickets closed to paths closed Replace SLA-heavy dashboards with measures such as internet-exposed assets removed, crown jewels with zero reachable paths, and validated closure in the asset graph.
- Map identity and privilege into every exposure review Add service accounts, workload permissions, and privileged trust relationships to remediation analysis so a vulnerable asset is judged by who or what can reach it.
- Route remediation to the true asset owner Send cases to the platform team, SaaS admin, developer, or IAM owner who can actually remove the path, rather than dropping everything on a generic patch queue.
What's in the full article
JupiterOne's full analysis covers the operational detail this post intentionally leaves for the source:
- How the JupiterOne graph model groups findings into remediation cases by ownership rather than category
- How Blast Radius Risk Factor identifies when a vulnerable asset sits on a path to a customer-defined crown jewel
- How bidirectional ITSM closure re-checks the path after remediation instead of relying on ticket status alone
- How application-level coverage extends the model into transitive dependencies and software CPE resolution
👉 Read JupiterOne's analysis of why vulnerability management metrics are failing →
Vulnerability management is failing the exposure problem teams need to solve?
Explore further
10/07/2026 9:44 pm
Activity metrics have become a proxy for security, and that proxy is now failing. The article’s central argument is that vulnerability management has drifted into measuring scanner coverage, ticket throughput, and SLA compliance instead of exposure reduction. That is a governance failure, not just an operational one, because the programme optimises the wrong unit of work. For identity leaders, the parallel is obvious: access reviews that count completions but miss standing privilege are just as hollow.
A question worth separating out:
Q: Who is accountable when a vulnerability creates a real exposure path?
A: Accountability should sit with the owner of the asset, platform, or identity path that makes the weakness reachable. Security can detect and coordinate, but remediation must land with the team that can remove the path and validate the fix. Governance should require evidence of closure, not just evidence that a ticket was opened or updated.
👉 Read our full editorial: Vulnerability management is failing because the metric is wrong
