AI-assisted development is outpacing AppSec controls

At a glance

What this is: This is Veracode’s analysis of how AI-assisted development is changing software delivery speed and exposing a persistent gap in application security controls.

Why it matters: It matters because CISOs, AppSec leaders, and IAM teams need to govern faster code production without letting insecure code, dependency risk, and weak control placement expand the attack surface.

By the numbers:

• The average security pass rate across 150+ LLMs tested is 55%, and that figure has remained flat for two years.
• 45% of AI-generated code contains known security vulnerabilities when no security guidance is provided.
• 82% of organizations carry security debt, up 11% in one year.
• OpenAI’s reasoning-focused models lift security pass rates to the 70-72% range in testing.

👉 Read Veracode's analysis of AI-assisted development and AppSec risk

Context

AI-assisted development has moved from experiment to operating model, which means security teams are no longer judging a tool choice but a change in how code enters the estate. The primary issue is not that AI writes code, but that it can multiply vulnerable code faster than existing review and remediation loops can absorb.

For IAM and NHI programmes, the relevance is indirect but real. AI-generated applications often introduce new dependency chains, secrets handling patterns, and access paths that affect identity governance, privilege, and workload trust. The typical organisation is still trying to secure AI-assisted development with controls designed for slower pipelines, which is now an increasingly brittle assumption.

Key questions

Q: How should security teams control AI-assisted coding without slowing developers down?

A: Put policy into the IDE so security guidance appears during code creation, not after commit. Teams should use safe defaults, prompt shaping, and low-friction remediation paths. The goal is to reduce insecure output while preserving developer flow, because delayed controls create rework and encourage bypasses.

Q: Why does AI-assisted development increase application identity risk?

A: Because many applications implement identity controls in code, and AI tools can reproduce insecure login, token, and access patterns at scale. That means the risk is not limited to software defects. It extends to the trust boundaries that govern users, service accounts, and any downstream system that accepts those credentials as valid.

Q: What do security teams get wrong about AI-generated code risk?

A: They often focus on catching insecure output after code is written, which is too late for AI-native workflows. The more important control point is the moment the agent is allowed to initiate the action. If that step is not governed, testing becomes a detection layer rather than a prevention layer.

Q: How can security teams tell whether AI lifecycle controls are working?

A: They should look for evidence that access requests, policy enforcement, and usage visibility are centrally recorded and current. If those signals are fragmented across platforms, the programme may be documenting governance rather than enforcing it. Continuous traceability is the practical test.

Technical breakdown

Why AI-generated code keeps reproducing known vulnerabilities

AI code assistants are trained on large corpora of public code, which means they inherit the security habits, shortcuts, and mistakes embedded in that material. The result is often syntactically correct output that still contains common flaws such as injection risks, weak input handling, and insecure dependency use. When the model is prompted without security guidance, it optimises for plausibility and speed rather than secure construction. That is why better-looking code is not the same as safer code, and why security quality does not improve just because the model version changes.

Practical implication: treat model output as untrusted input and gate it with security checks before commit, not after release.

How AI-assisted development expands the software supply chain risk surface

AI tools do not just produce first-party code. They also suggest libraries, generate package references, and can introduce dependency choices that developers did not explicitly review. That creates supply chain exposure through transitive packages, unverified imports, and the risk of malicious typosquatting when hallucinated package names are later targeted by attackers. In practice, the attack surface is no longer limited to the code the developer sees. It extends to the provenance of every component the assistant helps assemble, which makes dependency governance part of AppSec, not a separate procurement concern.

Practical implication: pair source code scanning with automated dependency verification and package controls in the same pipeline.

Why runtime controls matter when velocity rises faster than review

Static analysis alone cannot catch every flaw introduced by AI-assisted development, especially when business logic is valid but unsafe. That is why runtime testing, continuous composition analysis, and feedback inside the IDE matter. The control objective is not simply to detect more issues. It is to move detection into the developer workflow early enough that insecure patterns are corrected before they become part of deployed services. In fast-moving environments, the timing of control placement is as important as the control itself.

Practical implication: shift from end-of-pipeline approval to continuous, developer-facing controls across IDE, build, and runtime stages.

Threat narrative

Attacker objective: The attacker objective is to exploit insecure AI-assisted development output to gain code execution, data access, or durable footholds through vulnerable applications and dependencies.

1. Entry begins when developers accept AI-generated code or dependency suggestions without security guidance or independent review.
2. Escalation occurs when insecure logic, vulnerable libraries, or malformed package references move into shared repositories and CI/CD pipelines.
3. Impact follows when vulnerable code reaches production at scale, increasing exposure to exploitation, remediation debt, and supply chain compromise.

NHI Mgmt Group analysis

AI-assisted development creates security debt faster than traditional AppSec can repay it. The core governance problem is not code generation itself, but the mismatch between output velocity and review capacity. When insecure code enters the pipeline at scale, vulnerability management stops being a backlog problem and becomes a throughput problem. That changes the operating model for AppSec, because control placement must move earlier and become continuous. Practitioner conclusion: security programmes should be measured by how quickly they intercept risky output, not by how many issues they count.

Secret exposure risk rises when AI tools participate in code creation. AI-assisted development often touches configuration, environment variables, package manifests, and integration code where credentials are introduced or copied. That makes NHI governance relevant even in an AppSec article, because service tokens, API keys, and deployment credentials are frequently embedded in the same workflows that AI accelerates. The security boundary now spans both code quality and identity hygiene. Practitioner conclusion: teams need one control plane for code, secrets, and runtime access, not separate oversight lanes.

Supply chain confidence is the named concept teams should watch. AI-assisted development encourages fast reuse, but fast reuse can hide unaudited dependencies, generated package names, and imported functionality that no developer fully reviewed. This is where security debt compounds into supply chain uncertainty, because the provenance of what gets shipped becomes harder to prove. That uncertainty is now part of software governance, not just engineering convenience. Practitioner conclusion: software provenance must be treated as a control objective alongside vulnerability remediation.

Security leaders should stop treating AI adoption as a tooling question and start treating it as a control architecture question. The article’s underlying message is that secure outcomes depend less on which model developers use and more on where the organisation inserts guardrails. IDE scanning, dependency controls, and runtime testing together form a governance stack that matches the speed of modern development. Practitioner conclusion: align security policy to the development workflow the business actually uses.

AI remediation will matter only if it is tied to trusted fixes and measurable risk reduction. AI can help reduce mean time to remediate, but generic model output is not enough when the same models can generate insecure code in the first place. This is a trust and governance issue, not just an automation problem. Practitioner conclusion: remediation automation should be evaluated by fix quality, repeatability, and risk reduction, not by speed alone.

What this signals

The practical signal for security programmes is that AI-assisted development will expose gaps in speed, ownership, and control placement long before it creates a headline breach. Teams that still rely on after-the-fact review will accumulate risk faster than they can measure it, which is why pipeline-integrated governance is becoming the default expectation. The broader lesson is that AppSec maturity now depends on response latency, not just control coverage.

Control-plane convergence: AI-assisted development, secrets handling, and dependency governance are starting to behave like one problem. That matters for identity teams because workload credentials, deployment tokens, and service access frequently move through the same delivery paths as generated code. When those paths are weak, identity governance becomes a software delivery issue as much as an access issue.

For practitioners

• Move security into the IDE Deploy immediate scanning where developers accept AI suggestions, so risky code is flagged before commit and not after merge. The goal is to reduce review lag at the point of creation, not at release.
• Gate generated dependencies with package controls Require automated verification for any library or package suggested by an AI assistant, including transitive dependencies and suspicious package names. This reduces exposure to hallucinated imports and typosquatting.
• Align SAST, SCA, and DAST in one workflow Use static analysis for source flaws, composition analysis for imported components, and dynamic testing for runtime behaviour. The control set should be continuous across the pipeline rather than isolated at release.
• Prioritise fixes by exploitable risk Replace raw vulnerability counts with severity, reachability, and business impact so teams can focus on issues that materially change exposure. That is the only workable response when AI expands code volume.

Key takeaways

• AI-assisted development is not a coding convenience problem, it is a governance problem created by security moving slower than code.
• The main evidence is blunt: AI code generation still produces vulnerable output at scale, while security debt and secret exposure remain stubbornly high.
• The right response is to embed continuous controls into the developer workflow and measure how quickly they reduce exploitable risk.

Key terms

• AI-assisted development: A development workflow where an AI system helps generate, refactor, test, or execute code inside the software delivery process. The security issue is not the assistance itself, but that the tool may operate in trusted contexts that also contain credentials, infrastructure access, and other sensitive assets.
• Security Debt: Accumulated risk that builds when vulnerabilities, unsafe dependencies, and policy gaps are left unresolved across the software lifecycle. In AI-assisted development, security debt grows quickly because more code is produced, more decisions are made automatically, and remediation often lags behind delivery.
• Software Supply Chain Risk: Software supply chain risk is the chance that code, build, deployment, or dependency paths are altered in ways that affect downstream systems. For AI code assistants, this risk rises when the tool can change source, trigger pipelines, or influence infrastructure definitions.
• Regression Testing: Regression testing re-runs selected tests after a change to confirm existing behaviour still works. In API programmes, it helps detect whether a code update, dependency change, or configuration shift has altered a path that previously behaved correctly.

What's in the full article

Veracode's full article covers the operational detail this post intentionally leaves for the source:

• Model-by-model security pass rate comparisons across GPT, Gemini, Claude, and reasoning-focused systems
• Examples of how SAST, SCA, and DAST should be layered into AI-assisted development workflows
• Specific remediation guidance for security teams trying to reduce AI-generated vulnerability backlog
• The article's discussion of how security teams can balance developer velocity with AppSec control placement

👉 Veracode's full post covers the model testing results, remediation strategy, and pipeline control implications.

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 in practical terms. It helps security and identity practitioners connect identity controls to real operational risk across modern delivery environments.