Topic starter
18/08/2026 2:16 pm
TL;DR: AI-driven vulnerability sprawl is forcing appsec teams to sort by exploitability and business impact instead of treating every finding as equal, according to Kusari. Reachability and production breadth now decide where remediation effort actually reduces risk.
Editorial analysis by NHI Mgmt Group, based on content published by Kusari: “Surviving the vulnpocalypse with Kusari”.
Key questions
Q: Why do reachable vulnerabilities deserve higher priority than generic scan results?
A: Reachable vulnerabilities matter more because the application actually invokes the vulnerable function, which means the issue can move from abstract weakness to practical exposure.
Q: What breaks when dependency lifecycle is not governed tightly?
A: Teams inherit risk from software they do not control, including libraries that no longer receive fixes or versions that are left in production too long.
A: Start by validating exploitability, not by chasing every finding in the scanner queue.
Practitioner guidance
- Implement reachability-based triage Filter dependency findings by whether the vulnerable code path is actually invoked in production, then route only reachable items into remediation queues.
- Prioritise production-impacting vulnerabilities first Weight findings by deployed environment, data integrity risk, and blast radius rather than treating development and test environments as equal to production.
- Set dependency cooldown policies Delay immediate adoption of newly released packages so maintainers have time to identify malicious updates and downstream issues before rollout.
Bottom line: AI-driven vulnerability sprawl forces appsec teams to prioritise exploitability and business impact instead of treating every finding as equal.
Glossary terms: Vulnerability sprawl, Reachability analysis, Dependency Cooldown, End-Of-Life Dependency
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 1 day ago by NHI Mgmt Group
18/08/2026 3:09 pm
AI-driven vulnerability sprawl is now a governance problem, not just a tooling problem. When both defenders and attackers use AI to increase throughput, the control question changes from how many issues exist to which ones can actually change risk. Teams that keep prioritising by raw severity will drown in noise, while teams that prioritise exploitability and production impact can still make measurable progress.
A few things that frame the scale:
- Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to the State of Secrets in AppSec.
A question worth separating out:
Q: How should appsec teams decide whether to fix or mitigate a vulnerability first?
A: Mitigate first when a simple configuration change, firewall rule, or feature toggle can remove immediate harm, then schedule full remediation based on reachability and business impact. This sequencing preserves capacity for the issues that need code change, dependency replacement, or release coordination. It is especially useful when production systems carry the most customer and data risk.
👉 Read our full editorial: Vulnerability sprawl and AI-driven attack chains are reshaping appsec