TL;DR: AI-assisted development and AI-assisted exploitation are accelerating vulnerability volume, supply chain risk, and remediation pressure, while teams still need to decide which flaws are reachable, widespread, and worth fixing first, according to Kusari. The practical shift is from chasing every finding to prioritising exploitability, production impact, and dependency lifecycle risk.
At a glance
What this is: Kusari argues that AI-driven vulnerability sprawl is amplifying application security noise, while reachability and production impact are becoming the only practical triage filters.
Why it matters: IAM and security teams should care because AI-accelerated software change alters how risk is prioritised across code, dependencies, and release pipelines, especially where identity-bound access and supply chain trust are involved.
Context
Application security breaks down when teams treat every reported flaw as equally urgent. AI-assisted development increases the number of code changes, while AI-assisted exploitation increases the number of paths attackers can explore, which turns triage into a governance problem as much as a technical one.
The identity angle appears in the software supply chain and in the way developers use AI assistants inside delivery workflows. That makes vulnerability management a broader control issue, spanning code, dependencies, and the access paths that allow AI-enabled tooling to influence what gets shipped.
Key questions
A: Start by validating exploitability, not by chasing every finding in the scanner queue. The immediate task is to determine which weaknesses can be chained into real access, privilege gain, or data exposure in your environment. That lets teams focus remediation on exposures that an attacker can actually use, instead of on findings that look severe but are not practically reachable.
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. A scan result that never touches runtime code is noise until evidence proves otherwise. Security teams should spend remediation effort where execution paths make exploitation plausible.
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. Over time, this creates an unpatchable exposure window and makes supply chain compromise more likely to become operational impact. Governance should treat dependency age as a security variable, not a release convenience.
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.
Technical breakdown
Why reachability is the first useful filter
Reachability asks a simple question: can an attacker actually trigger the vulnerable code path in this environment? A flaw in a dependency does not matter equally if the application never calls that function, never enables that configuration, or only uses the library in a limited context. In modern appsec, reachability analysis helps separate theoretical exposure from exploitable exposure. That distinction matters more when AI tools inflate the number of reported issues faster than teams can review them.
Practical implication: use reachability to suppress unexploitable findings before they consume engineering and risk-review time.
How attack chains turn single bugs into compound risk
AI-assisted attackers do not need one dramatic flaw when they can combine several small ones into a working chain. A low-severity issue in one component may become meaningful when paired with an authentication weakness, an unsafe configuration, or a dependency that is widely deployed. This is why vulnerability volume is only part of the problem. The more important question is whether multiple weak signals can be composed into a path to data loss, service abuse, or supply chain compromise.
Practical implication: score vulnerabilities by how they combine with surrounding controls, not by severity labels alone.
Why dependency lifecycle now carries security weight
Open source dependency management is no longer just a software hygiene task. If teams adopt packages blindly, delay updates without a policy, or keep end-of-life components in production, they inherit the security posture of software they do not control. That creates residual exposure even when internal code is well managed. Lifecycle decisions around versioning, cooldowns, and replacement are therefore part of appsec governance, not just engineering convenience.
Practical implication: treat dependency age, update lag, and end-of-life status as security risk indicators in release governance.
Threat narrative
Attacker objective: The attacker aims to turn high vulnerability volume into exploitable application and supply chain paths that create disproportionate operational and data impact.
- Entry begins with AI-assisted discovery of weaknesses in exposed or widely deployed application components and dependencies.
- Credentialed or unauthenticated access to reachable code paths allows attackers to combine multiple low-level flaws into a practical exploit chain.
- Escalation occurs when the chain reaches production systems, third-party libraries, or supply chain components that affect many applications.
- Impact is broader remediation pressure, code compromise, supply chain exposure, or data loss across multiple environments.
Breaches seen in the wild
- postmark-mcp malicious MCP server 2025: A fake Postmark MCP server on npm quietly BCC'd every email AI agents sent through it to an attacker, using victims' own Postmark tokens.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
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.
Reachability analysis is becoming the decisive triage concept for appsec programmes. A vulnerability that cannot be reached in the deployed environment is not the same as a vulnerability that can be exploited on demand. This distinction matters more as AI accelerates finding, reporting, and chaining flaws across dependencies and internal code. Practitioners should make reachability part of the risk language used by security, engineering, and governance teams.
Dependency lifecycle is now a security control surface. End-of-life components, delayed updates, and uncontrolled package sprawl create predictable exposure windows that attackers can exploit at scale. The security programme no longer only governs code quality; it governs what software is allowed to remain in production and for how long. Practitioners should treat dependency age and replacement policy as part of appsec accountability.
AI assistants amplify both code creation and attack creation, which compresses the time available for review. That compression creates a new form of security debt: more findings arrive before teams can validate them, and more exploit paths appear before remediation can finish. The right response is not to review harder, but to redesign prioritisation so that exploitability, breadth, and business impact decide what gets fixed first.
From our research library:
- 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.
- Read next: AI Coding Agents Security Guide
What this signals
Reachability-first triage should become the default operating model for appsec teams facing AI-accelerated defect inflow. The old assumption that security can review everything in sequence no longer holds when both code creation and exploit discovery are moving faster than human review capacity.
Dependency age is now a governance signal: once a package reaches end-of-life or sits too long without cooldown, it becomes a measurable exposure multiplier. Teams should watch package freshness, production breadth, and update lag as leading indicators of whether vulnerability sprawl is getting ahead of control.
The strongest programmes will stop asking which vulnerability looks worst in isolation and start asking which one can realistically be reached, repeated, and amplified across the environment. That shift changes how appsec, engineering, and risk teams share accountability for what ships.
For practitioners
- 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.
- Replace end-of-life dependencies on a fixed schedule Track packages that no longer receive fixes and remove them before they become unpatchable sources of future exposure.
- Use proof-of-concept evidence in severity reviews Require reproducible demonstrations before escalating internal reports, especially where the issue only exists in theory or in undocumented edge cases.
Key takeaways
- AI-driven vulnerability sprawl forces appsec teams to prioritise exploitability and business impact instead of treating every finding as equal.
- Reachability and production breadth are the practical filters that keep remediation aligned with actual risk.
- Dependency lifecycle decisions, including cooldowns and end-of-life replacement, now function as core security controls.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while CIS Controls v8, NIST CSF 2.0 and SLSA set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | TA0006; TA0010 — Credential Access; Exfiltration | The article centers on chained exploitation and downstream impact, which maps to adversary tactics. |
| Recommendation — Map chained exploitation to TA0006 and TA0010, then hunt for reachable paths that enable compound abuse. | ||
| CIS Controls v8 | CIS-16 — Application Software Security | The article is about appsec prioritisation, dependency risk, and fixing exploitable weaknesses. |
| Recommendation — Use CIS-16 to govern which application vulnerabilities and dependencies enter remediation first. | ||
| NIST CSF 2.0 | PR.PS-03 — Integrity Verification | Dependency integrity, exposure breadth, and production protection are central to the article's controls. |
| Recommendation — Apply PR.PS-03 to verify software integrity and reduce the impact of vulnerable or compromised dependencies. | ||
| SLSA | L3 — Build integrity | Supply chain attacks and dependency trust are part of the article's risk model. |
| Recommendation — Raise build provenance and dependency controls to SLSA-aligned levels before vulnerable code reaches production. | ||
Key terms
- Reachability analysis: Reachability analysis checks whether a vulnerability can actually be exploited in the application’s real code paths and dependency graph. It helps teams distinguish theoretical findings from issues that an attacker can reach, which makes prioritisation far more accurate for both AppSec and identity risk management.
- Vulnerability sprawl: Vulnerability sprawl is the operational overload that occurs when the volume of findings grows faster than the team can triage, validate, and fix them. In practice it turns security review into a prioritisation problem, especially when automation and AI increase both code output and attack discovery.
- Dependency Cooldown: A dependency cooldown is a deliberate waiting period before adopting a new upstream package version into production. It gives defenders time to observe malicious releases, unstable updates, or supply chain tampering before trust is extended to the change.
- End-Of-Life Dependency: A dependency that no longer has active support, regular fixes, or a realistic upgrade path that preserves the original application design. These components often create lifecycle risk because remediation may require migration, not a simple patch or version bump.
Deepen your knowledge
NHI Mgmt Group's NHI Foundation Level course covers NHI governance, machine identity security, and secrets management through the industry's only accredited NHI security programme. It helps practitioners connect identity control to the broader security programme that appsec depends on.
Published by the NHIMG editorial team on August 18, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org