TL;DR: AI coding assistants have driven a 10x surge in monthly security findings within six months, while legacy SAST still struggles with cross-file logic, hallucinated dependencies, and false positives, according to Apiiro. The practical shift is from pattern matching to reachability, exploitability, and architectural context as the real filters for risk.
At a glance
What this is: This is an analysis of why AI-generated code is overwhelming legacy SAST, with the key finding that volume, cross-file logic, and hallucinated dependencies are exposing scanner limits.
Why it matters: It matters because AppSec teams now need reachability, exploitability, and architectural context to separate real risk from the flood of findings generated by AI-assisted development.
By the numbers:
- Enterprise repositories adopting AI coding assistants saw a 10x surge in monthly security findings within six months.
Context
AI coding assistants change the economics of application security by increasing output faster than human review processes can absorb. In this environment, legacy static analysis starts to fail as a governance control because it was built for slower release cycles, simpler code paths, and narrower change sets.
The issue is not just more code. AI-generated code often spreads logic across multiple files and introduces dependencies that scanners cannot validate in context, which creates a genuine intersection between application security, software supply chain risk, and identity governance for agentic development workflows. When the code generator itself becomes part of the delivery chain, security teams have to govern the output as well as the pipeline.
Key questions
Q: What should AppSec teams do first when SAST findings overwhelm review capacity?
A: Start by filtering findings through reachability and runtime context before they reach a human. That turns triage into a prioritisation control, not a manual sorting exercise. Once you know which issues are actually exploitable, you can reserve engineering time for the findings that change real risk instead of just adding backlog.
Q: Why do AI-generated code findings create more risk than a higher alert count alone suggests?
A: Because the core problem is not just volume, it is the mismatch between scanner logic and the structure of agentic code. AI-generated code often spreads trust decisions, data flow, and sanitization across multiple files, so a single-file match can miss the real security outcome. That means prioritization has to incorporate runtime exposure and architectural context.
Q: Why do legacy SAST tools struggle in AI-assisted development environments?
A: Because they were built for slower delivery cycles and rule sets that assume predictable code patterns. AI-generated code can arrive faster than traditional scanners can contextualise it, which inflates false positives and leaves teams with alert queues they cannot trust or clear efficiently.
Q: How should teams respond when AI coding tools generate hallucinated package references?
A: Treat invented dependencies as supply chain risk, not just a code-quality defect. Validate that every referenced package exists, that its provenance is legitimate, and that build pipelines reject unapproved additions. If attackers can later register the same name, the assistant’s output can become an entry point into the software supply chain.
Technical breakdown
Why single-file static analysis misses AI-generated logic flaws
Traditional SAST engines usually inspect files or functions in isolation and apply pattern-based rules to identify known vulnerability shapes. That works poorly when AI-generated code distributes logic across middleware, helper functions, and database layers. A dangerous path can look safe in each fragment while remaining exploitable only when the call graph is reconstructed end to end. In practice, the scanner sees syntax, but not the architectural relationship between entry point, transformation, and sink.
Practical implication: Treat multi-file taint tracking and call-graph reconstruction as the minimum requirement for AI-generated code review.
Reachability and exploitability matter more than raw alert volume
Legacy scanners often report every match to a vulnerable pattern, even when a control in a preceding layer neutralises the issue. That creates alert fatigue and teaches teams to distrust findings. More advanced approaches test whether the path is actually reachable in the deployed architecture and whether an attacker can exploit it as written. This shifts analysis from theoretical presence to operational risk, which is the only threshold that matters when findings are arriving at machine speed.
Practical implication: Prioritise tools that suppress non-reachable findings and evidence exploitability before the issue reaches the backlog.
Hallucinated dependencies create a new supply chain blind spot
AI coding assistants can invent package names or dependency references that do not exist, and those false references can later be registered by attackers. That turns dependency generation into a security concern, not just a quality issue. The risk is especially sharp when developers accept AI-produced code without validating the provenance of imported libraries or the legitimacy of transitive dependencies. Supply chain checks therefore need to extend into code generation workflows, not stop at repository scanning.
Practical implication: Add dependency provenance checks and package validation to the same review flow that handles AI-generated code.
Threat narrative
Attacker objective: The attacker aims to turn AI-assisted development speed into exploitable software defects or supply chain footholds before AppSec teams can distinguish real risk from noise.
- Entry occurs when AI-generated code introduces a weak or misleading dependency reference into the application change set.
- Credential or control abuse follows when that code path is accepted as legitimate and merged without validating reachability or provenance.
- Impact comes when the resulting flaw becomes exploitable in the deployed architecture, or when false positives delay the team’s ability to find the real issue.
Breaches seen in the wild
- Amazon Q Developer extension compromise 2025: An over-scoped CI token let an attacker ship a prompt telling Amazon Q's AI coding agent to wipe files and AWS resources (CVE-2025-8217).
- tj-actions/changed-files compromise 2025: A stolen bot token let attackers poison tj-actions/changed-files so pipelines printed their CI/CD secrets to public logs (CVE-2025-30066).
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
Legacy SAST is becoming a capacity problem before it is a detection problem: the flood of AI-generated findings is exposing a mismatch between human-paced review models and machine-paced code production. The control failure is not just missed bugs, but the inability to decide which findings deserve attention. AppSec teams now need governance over triage, not only detection, because false certainty is as dangerous as missed vulnerabilities.
Reachability analysis is the real discriminator in agentic development: a pattern match tells you that a code shape resembles a vulnerability, but not whether the deployed application can actually be reached through that path. That means architectural context, runtime exposure, and data-flow validation now matter more than scanner coverage alone. The practical conclusion is that security teams should score findings by exploitability, not by scanner count.
Package hallucination creates a distinct software supply chain exposure: AI-generated references to non-existent packages are not harmless noise when attackers can register the same names later. That is a code-generation governance issue, not just a developer productivity issue. The named concept here is hallucinated dependency exposure, and it shows why supply chain validation must move upstream into the coding assistant workflow.
Agentic development changes the security boundary around the developer workflow: the code author may be human, but the effective system now includes an AI assistant that can create, refactor, and remediate at speed. That puts AI governance, code security, and developer experience in the same control plane. Teams that keep treating the assistant as a productivity add-on will under-control the risk it introduces.
ASPM becomes the organising layer when scanners outnumber decisions: individual tools can detect fragments of risk, but only orchestration can deduplicate findings, correlate them with runtime exposure, and preserve developer throughput. The field is moving away from isolated scanners toward risk validation across the application lifecycle, which is the only scalable posture for AI-assisted software delivery.
From our research library:
- Claude Code-assisted commits leaked secrets at a rate of 3.2%, more than double the human-only baseline of 1.5%, with peaks reaching 31 secrets per 1,000 commits in August 2025, according to the State of Secrets Sprawl 2026.
- Developers using GenAI tools like GitHub Copilot are reporting 35% productivity gains, according to IDC’s 2024 Generative AI Study.
- Read next: AI Agent Observability, Audit and Incident Response Guide
What this signals
Hallucinated dependency exposure: AI-generated package references are now a governance issue because invented names can become real supply chain targets once published. Security teams should move provenance checks into the same workflow that approves assistant-generated code, not leave them to downstream review.
AppSec programmes need to reclassify scanner output as a validation problem, not an alert-management problem. Once development velocity rises faster than human triage, the decisive control is whether the organisation can prove exploitability and runtime relevance before a finding consumes developer time.
For practitioners
- Adopt reachability-based triage Require every high-severity SAST finding to be validated against architectural context, data flow, and deployment reach before it enters remediation queues.
- Validate AI-generated dependencies Block merges when assistant-generated code introduces new packages unless the dependency is confirmed to exist and is approved by supply chain policy.
- Consolidate scanner outputs through ASPM Deduplicate SAST, SCA, and secrets alerts in a single orchestration layer so teams can prioritize by exploitability and business criticality instead of tool noise.
- Measure tool quality with exploitability Use false-positive rate, time to context, and proof of exploitability as acceptance criteria when evaluating AI-era application security tools.
Key takeaways
- AI coding assistants are exposing a mismatch between machine-speed code production and human-speed security review.
- Legacy SAST struggles most where AI-generated code distributes logic across multiple files and where hallucinated dependencies enter the software supply chain.
- Security teams need reachability, exploitability, and architectural context to separate real application risk from noise at scale.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP API Security Top 10 | API10 — Unsafe Consumption of APIs | AI-generated code often introduces unsafe package and dependency consumption paths. |
| Recommendation — Validate assistant-generated dependencies before merge and reject unsafe or unverified consumption paths. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Context-aware risk validation depends on knowing whether code paths are actually authorised and reachable. |
| Recommendation — Apply PR.AA-05 to align code path access and runtime authorisation with the deployed architecture. | ||
| CIS Controls v8 | CIS-16 — Application Software Security | The article is fundamentally about strengthening software security controls in CI/CD and pull requests. |
| Recommendation — Use CIS-16 to enforce secure code review, scanning, and remediation gates for AI-generated changes. | ||
| MITRE ATT&CK | TA0006; TA0010 — Credential Access; Exfiltration | The breach examples and workflow compromises revolve around credential theft and secret exposure. |
| Recommendation — Map pipeline secret exposure and poisoned workflows to TA0006 and TA0010 to focus detections. | ||
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.
- Hallucinated Dependency Exposure: Hallucinated dependency exposure occurs when an AI system invents package names or library references that do not exist. The risk is not limited to code correctness, because attackers can later register the same names and turn a false reference into a supply chain entry point.
- Agentic workflow: An agentic workflow is a sequence of tasks executed by an AI agent with some level of tool access and decision authority. In security terms, the workflow matters because it can span multiple systems, identities, and permissions, which makes attribution and revocation harder than with ordinary automation.
- Architectural context: Architectural context is the information that explains how code, services, data flows, and ownership relate to one another. It helps teams judge whether a scanner finding is isolated, exposed, or part of a business-critical workflow.
Deepen your knowledge
The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, agentic AI identity, and machine identity security. It helps practitioners align identity controls with the broader security and delivery workflows their programmes depend 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