AI-generated code is outpacing appsec controls, and attackers know it

At a glance

What this is: Checkmarx argues that AI-generated code is increasing vulnerability density and shrinking the time available for application security to catch up.

Why it matters: This matters because AppSec teams must secure code created at machine speed, where gaps appear before context, review, and remediation workflows can keep pace.

By the numbers:

• 81% of organisations knowingly ship software with vulnerabilities they have already identified.

Context

AI-generated code is software produced faster than most security programmes were built to inspect it. The core governance problem is not simply volume, but the loss of developer context and the widening gap between code creation and security validation.

In this article, the identity angle is indirect but real: developers, their credentials, package registries, and coding assistants have become part of the attack surface. That shifts AppSec from a late-stage review function to a control plane that has to operate at the point of code creation.

Key questions

Q: How should teams secure AI-generated applications before they reach production?

A: Treat security as a precondition of generation, not a review step at the end. Start with approved templates, shared authentication libraries, runtime secret retrieval, CI gates, and default-deny network policy. The goal is to make the safe path the easiest path, so generated code inherits controls instead of inventing them under pressure.

Q: Why do AI-assisted commits increase software supply chain risk?

A: AI-assisted development increases the number and speed of changes, which reduces the time available for human verification. The risk is not AI itself, but the possibility that unverified code reaches the repository before identity and provenance checks can stop it. That makes commit-time trust more important than post-commit inspection.

Q: What breaks when security review happens after code context is gone?

A: Review becomes slower, less accurate, and harder to remediate because developers no longer remember the trade-offs behind the change. That raises the chance that findings are ignored or deferred, which lets vulnerable code move into production with less resistance.

Q: How do AppSec and identity controls work together in AI coding workflows?

A: AppSec finds flaws in the code, while identity controls protect the systems that create and distribute that code. In AI coding workflows, both matter because access to source control, registries, and build systems determines whether risky code can be introduced at scale.

Technical breakdown

Why AI-generated code changes the AppSec threat model

AI coding assistants can produce large amounts of syntactically valid code without preserving the design intent, trade-offs, or hidden assumptions that human developers normally carry in their heads. That makes vulnerability density harder to predict, especially when generated code is mixed with existing application logic and third-party dependencies. In practice, the problem is not that AI writes code, but that it writes code faster than review, testing, and policy enforcement were designed to absorb. The result is a larger attack surface with less context attached to each change.

Practical implication: treat generated code as a higher-variance input to security review, not as a normal developer productivity gain.

Open source, package trust, and credential exposure

Modern software depends heavily on upstream packages, so AI-driven development inherits the same trust model as traditional software, only at greater speed. When coding tools hallucinate package names or developers pull in unvetted dependencies, attackers can register lookalike packages or poison the supply chain. The article also notes direct targeting of developer workflows, including package registries and compromised credentials, which turns the IDE and dependency chain into viable entry points. This is where identity and AppSec meet: access to code systems, registries, and build pipelines becomes a governance issue, not just a tooling issue.

Practical implication: tighten authentication and approval around developer tooling, registries, and build credentials before generated code expands the blast radius.

Why agentic AppSec has to act at creation time

The article’s key operational point is that security cannot rely on a human to inspect every finding after the fact. Once code moves on, the context that explains why it was written a certain way starts to disappear, and remediation gets slower. An agentic AppSec model means security tools are invoked automatically during development, combining deterministic checks such as SAST, SCA, and IaC analysis with faster triage and remediation support. That does not replace human judgment. It moves security earlier, where issues are still intelligible and cheaper to fix.

Practical implication: embed automated security checks into code creation workflows so review happens while context still exists.

Threat narrative

Attacker objective: The attacker objective is to insert malicious or vulnerable code into the software supply chain and exploit the resulting exposure before defenders can validate or remediate it.

1. Entry begins in developer workflows, where attackers target package registries, dependencies, and credentials used to produce and ship code.
2. Credential and dependency abuse then lets malicious packages or compromised access flow into the software supply chain, where untrusted code is introduced at build time.
3. Impact follows when vulnerable or poisoned code reaches production faster than AppSec can review it, creating exploitable gaps at scale.

Breaches seen in the wild

• Fake Dependabot commits 2023: Stolen GitHub tokens were used to push fake Dependabot commits to hundreds of repos, adding workflows that stole Actions secrets.
• 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 speed-matching problem. Traditional review models assume security can examine code after developers finish writing it. That assumption breaks when code is produced continuously, by assistants that do not carry organisational risk context. The practical consequence is that security must move into the creation path, not wait for downstream validation.

Developer identity is now part of the attack surface. The article makes clear that attackers are not only targeting code quality, but also the access paths that let developers publish, pull, and deploy code. Package registries, coding assistants, and source-control credentials become governance objects in their own right, which is why identity controls and AppSec controls now converge. Teams that still treat developer access as separate from software risk are carrying a false boundary.

Automation alone is not enough if it only creates more findings. AI-assisted scanning can increase noise unless deterministic controls validate what the model reports. That is the deeper governance lesson: speed without validation produces alert inflation, while validation without speed produces stale findings. Security programmes need an operating model that can both analyse and act at creation time.

Context loss is the new control gap. The article shows that risk is not only in code volume, but in the disappearance of the decision context that explains why code exists. Once that context is gone, developers and security teams spend more time reconstructing intent and less time fixing defects. The implication is that governance has to happen while the context is still attached to the change.

Agentic application security is becoming a baseline control model. As AI systems participate in coding, the security response cannot remain manually sequenced. Security needs to behave like part of the development system, with deterministic checks, prioritisation, and remediation support operating in-line. For practitioners, that means rethinking where control points sit in the software lifecycle.

What this signals

Context now matters as much as code quality. AI-assisted development reduces the time available to understand why a change was made, which means security controls have to fire earlier in the lifecycle. For teams, that shifts the operational priority from post-commit review to pre-merge enforcement.

Developer workflow controls are becoming security controls. Source control permissions, package registry governance, and build credentials are no longer just engineering hygiene. They are the practical boundary that determines whether generated code and dependencies can move from a prompt into production.

Agentic AppSec will need to be measured by remediation speed, not alert volume. If automation only produces more findings, the programme has not improved. The useful signal is whether security can validate, prioritise, and close issues while the developer still has enough context to act.

For practitioners

• Embed security at code creation time Shift AppSec checks into the IDE and CI pipeline so vulnerable code is analysed while the developer still has context for fixing it.
• Harden developer identity and registry access Require strong authentication, scoped credentials, and explicit approval paths for package registries, source control, and build systems.
• Validate AI findings with deterministic controls Use SAST, SCA, and IaC analysis to confirm or refute AI-generated findings before they are routed for remediation.
• Treat generated dependencies as supply-chain inputs Inspect hallucinated or newly introduced package names and block unapproved dependencies before they enter the build.

Key takeaways

• AI-generated code is changing AppSec by increasing vulnerability density and reducing the time available for review.
• The main exposure is not only in code quality but in the identity and supply-chain pathways that let code, dependencies, and credentials flow into production.
• Security teams need controls that operate at code-creation speed, because delayed review loses the context required to fix issues efficiently.

Key terms

• Agentic AppSec: An application security model that embeds detection, remediation, and policy enforcement into AI-assisted development workflows. It treats AI coding tools and remediation agents as part of the security control plane, not just productivity software that developers use informally.
• Code Creation Time: Code creation time is the point in the workflow when code is being written, generated, or first assembled. Security controls placed here are more effective because they can use the developer’s context, the build context, and the dependency context before those signals disappear.
• Developer Workflow Attack Surface: Developer workflow attack surface is the set of tools and access paths used to write, review, retrieve, and ship code. It includes source control, IDEs, coding assistants, package registries, and build credentials, all of which can be targeted to inject malicious or vulnerable software.
• Dependency Trust Drift: Dependency trust drift is the gap between the package a team believes it is approving and the code that actually executes in the build pipeline. It emerges when names, registries, and automation are treated as sufficient trust signals, even though attackers can manipulate each layer.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners connect identity controls to the broader software and security lifecycle.