TL;DR: A global survey of 2,350 CISOs, AppSec managers and developers across 14 countries found that 49% of production code is now AI-generated, 81% of organisations were breached twice or more in the past year, and only 9% fix more than 90% of vulnerabilities within 90 days, according to Checkmarx. The result is an AppSec model where detection is plentiful but risk still survives the decision chain.
At a glance
What this is: Checkmarx’s research says AI-generated code, repeated breaches, and slow vulnerability closure are combining to create an AppSec model that spots problems but fails to remove them fast enough.
Why it matters: For AppSec, IAM, and platform teams, the issue is not only code quality but governance: if vulnerabilities survive long enough to reach production, decision latency becomes a security control failure.
By the numbers:
- 49% of production code is now AI-generated.
- 81% of organisations were breached twice or more in the past year.
- Only 9% of organisations fix more than 90% of vulnerabilities within 90 days.
Context
Application security is now defined as much by decision speed as by detection coverage. When AI-generated code expands faster than remediation workflows, the practical control gap shifts from finding vulnerabilities to preventing them from surviving long enough to matter.
This article sits at the intersection of secure SDLC governance, developer experience, and identity-adjacent risk around AI-assisted tooling. The core problem is that security findings still move through human approval chains that are too slow for modern code velocity, especially where AI tooling is changing authorship and review assumptions.
Key questions
Q: Where does AppSec fail when teams can detect issues but still ship vulnerable code?
A: It fails at the decision layer between finding a vulnerability and enforcing remediation. If findings are filtered, delayed, or deprioritised until after release, detection has no security value. The practical failure is not absence of visibility but absence of a control that prevents known risk from surviving the delivery process.
Q: Why do AI-generated code changes increase application security risk?
A: AI-generated code can increase risk because it accelerates output faster than review, testing, and secret hygiene can keep up. The issue is not only flawed logic. It is also the possibility that tokens, credentials, unsafe dependencies, or insecure defaults are reproduced at scale across the delivery pipeline.
Q: What are the signs that vulnerability remediation is not holding up in practice?
A: Warning signs include high recurrence rates, slow validation after fixes, and vulnerabilities that reappear after patches or configuration changes. If teams close tickets without retesting, they can create false confidence while exposure remains. Recurring issues usually point to patching gaps, configuration drift or weak follow through, so continuous testing and retesting are essential.
Q: Should organisations prioritise continuous security feedback over end-of-cycle checkpoints?
A: Yes, when development velocity is high and AI-generated code is common. Checkpoints can still help with governance, but they are too late if vulnerabilities are being introduced and shipped continuously. Continuous feedback only works when it is paired with clear release authority and fix accountability.
Technical breakdown
Why AI-generated code changes the vulnerability baseline
AI-assisted coding changes the volume, origin, and consistency of application code. That matters because security controls built around human-authored code assume predictable review patterns, stable ownership, and slower change rates. When code is generated faster than teams can inspect it, the attack surface grows even if tooling coverage appears high. The problem is not that AI code is automatically insecure, but that it increases the probability of weak patterns, copied flaws, and overlooked dependencies entering production.
Practical implication: Shift AppSec control points left into generation and review workflows, not just post-commit scanning.
Why detection does not equal remediation
Modern AppSec stacks can surface far more findings than organisations can realistically resolve. Detection creates visibility, but remediation turns that visibility into risk reduction. If feedback arrives late, gets filtered by ranking logic, or is suppressed in favour of delivery pressure, the control loop breaks. In that state, vulnerability discovery becomes a reporting function instead of an operational safeguard.
Practical implication: Treat remediation throughput, not scan volume, as the real measure of AppSec effectiveness.
How security findings get neutralised in delivery pipelines
Security findings are often delayed by workflow design, not just by lack of effort. Findings can be deprioritised by severity triage, hidden behind tooling noise, or deferred because development and security teams are measured on different outcomes. That creates a governance problem: the organisation can know about a flaw and still fail to act before release. In practice, the control failure is decision latency across product, security, and engineering ownership.
Practical implication: Redesign escalation paths so vulnerable code cannot bypass review simply because the pipeline is busy.
Threat narrative
Attacker objective: Exploit known application weaknesses faster than the organisation can remove them, turning slow remediation into a durable exposure window.
- Entry occurs when AI-generated code introduces vulnerable patterns or insecure dependencies into the software delivery process.
- Credential or code-path abuse follows when those weaknesses are deployed and become reachable inside production workflows or exposed services.
- Escalation happens when slow remediation leaves known flaws active long enough for adversaries or automated exploit tooling to take advantage of them.
- Impact is sustained breach exposure, because known vulnerabilities remain live while organisations continue shipping code.
Breaches seen in the wild
- Checkmarx KICS supply chain attack 2026: Credentials stolen via Trivy let attackers poison Checkmarx KICS Docker images, VS Code extensions and Actions to steal developer secrets.
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-generated code has turned AppSec into a governance problem, not just a tooling problem. The article shows that security visibility is no longer the limiting factor; organisational response is. When code authorship shifts toward AI and developers act more as editors, the old assumption that human review pace can keep up no longer holds. The practitioner conclusion is that control design must account for machine-paced code creation.
Remediation latency is the new exposure window. The most important risk in this article is not the existence of findings but the time they remain unresolved. That creates a practical similarity to non-human identity governance: if a risky object remains active after detection, the issue is lifecycle control, not discovery. The practitioner conclusion is to treat unresolved vulnerabilities as live access paths, not static defects.
There is a decision-chain failure between detection and enforcement. The article describes a system where teams can see the risk, agree it is real, and still fail to act. That is a named control gap in its own right: the visibility-to-action gap. The practitioner conclusion is that security programmes need enforcement mechanisms that reduce the chance of known issues surviving release.
Application security now needs agentic response patterns, but only with constrained governance. The report’s mention of agentic security points to a future where routine triage and prioritisation can be accelerated by AI-assisted workflows. That does not remove human accountability; it changes where human judgement is applied. The practitioner conclusion is to use agentic assistance for throughput, while keeping policy, approval, and exception handling tightly governed.
From our research library:
- Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
- 96% of security operations teams report critical blind spots, most commonly in cloud infrastructure (74%) and identity and access behaviour (67%).
- Read next: Agentic AI Security Guide
What this signals
Decision latency is now an AppSec risk category of its own. When organisations can identify flaws yet still ship them, the meaningful control question becomes how quickly policy can convert findings into release-blocking action. That shifts AppSec from a scanner-centric model to a governance model where enforcement speed matters as much as detection coverage.
AI-assisted development is exposing a visibility-to-action gap that security teams should measure directly. The practical signal is not how many findings exist, but how many survive past the point where they should have been closed or blocked. Teams that cannot prove rapid closure will find that breach exposure persists even when tooling coverage looks mature.
For practitioners
- Map AI code risk to remediation throughput Track how much AI-generated code is entering production against the percentage of findings closed within the organisation’s service-level targets. When code volume rises faster than fix rates, severity scoring alone is no longer a usable control.
- Enforce release gates for known vulnerabilities Block promotion of code that still contains acknowledged high-risk findings unless an explicit exception process is approved by the right owner. The goal is to stop known issues from surviving the decision chain simply because delivery pressure is high.
- Reduce feedback latency for developers Push findings into the IDE, pull request, and build stages while they are still actionable, and remove duplicate or low-value alerts that train teams to ignore security feedback. Late feedback is a control failure, not a communication issue.
- Measure AppSec by closure rate, not scan volume Use metrics such as time to fix, percentage of vulnerabilities resolved within 90 days, and backlog ageing to judge whether the programme is actually reducing exposure. High detection without closure is only documentation of risk.
Key takeaways
- AI-generated code has changed the AppSec baseline, but the larger failure is organisational. Detection is widespread, yet vulnerabilities still survive because remediation and enforcement are too slow.
- The article’s evidence points to a widening gap between security visibility and actual risk reduction. In practice, a known vulnerability that remains open is still an active exposure.
- AppSec teams should treat remediation throughput and release gating as first-class controls. If known flaws can still reach production, the governance model is failing regardless of scan coverage.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | TA0006; TA0040 — Credential Access; Impact | The article cites exploitation of long-standing vulnerabilities that can lead to compromise and impact. |
| Recommendation — Map exploit paths to credential access and impact tactics so detection and response can prioritise exposed code paths. | ||
| NIST CSF 2.0 | ID.RA-01 — Asset Vulnerabilities Are Identified and Recorded | The report is fundamentally about known vulnerabilities surviving long enough to matter. |
| Recommendation — Record and prioritise vulnerable code as active risk until closure is verified. | ||
| OWASP ASVS | V15 — Secure Coding and Architecture | Generated code and delayed remediation both point to weak secure coding governance. |
| Recommendation — Verify secure coding rules before code reaches production, including code generated by AI tools. | ||
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | AI-generated code and weak review can expose secrets and sensitive material in application artifacts. |
| Recommendation — Scan generated code and pipelines for leaked secrets before they become persistent exposure. | ||
Key terms
- AI-generated code: Software produced wholly or partly by an AI model or agent rather than a human developer. The security concern is not authorship alone, but whether the resulting logic, access control, and dependency choices have been independently verified before release.
- Remediation Latency: The time between identifying a security issue and fully removing or reducing the risk. For NHIs and SaaS access, this metric matters because stale credentials, over-shared files, and dormant integrations stay usable until the control finally acts.
- Decision-chain failure: A breakdown in the sequence that turns detection into action. The issue is not whether a tool found a problem, but whether the organisation can escalate, approve, block, or fix it before the flaw survives into production or remains open long enough to be exploited.
- Application Security: Application security is the practice of protecting software across development, deployment, and runtime. It covers code, dependencies, secrets, infrastructure, and execution behaviour, because any one of those layers can expose data or access if it is not governed as part of the same lifecycle.
Deepen your knowledge
NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and secrets management for practitioners who need to connect identity control to broader security operations. It gives identity and security teams a shared foundation for governing high-risk access patterns across modern environments.
Published by the NHIMG editorial team on August 1, 2026.
Updated on October 13, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org