Vibe coding is exposing an AppSec review gap in AI-assisted code

At a glance

What this is: This is an analysis of how GenAI-assisted development is changing code review expectations, with the key finding that speed gains are outpacing security validation.

Why it matters: It matters because AppSec, IAM, and platform teams must decide how to govern human and AI-driven code creation without letting the same workflow author and approve risk.

By the numbers:

• 70% of AI-generated code was found to be, to be insecure or flawed when evaluated using secure coding baselines.
• Developers using GenAI tools achieve a 35% productivity boost, often matching the output of 3–5 engineers.
• 27 days

👉 Read Checkmarx's analysis of vibe coding, AppSec review gaps, and GenAI risk

Context

GenAI-assisted development is creating a governance gap in application security because code generation is now faster than code validation. In practice, that means the person or system producing code can push more volume than review processes were designed to inspect, which is a change in control design as much as a change in tooling. For AppSec teams, the issue is not whether AI can write code, but whether security review, policy enforcement, and remediation still happen before risk reaches production.

This is also where identity and access governance intersects with software delivery. AI assistants are increasingly part of the build path, while human developers remain accountable for the code that ships, creating a separation-of-duties problem that is closer to privileged workflow control than simple productivity tooling. When code suggestions, policy checks, and approval steps blur together, organisations lose a clear boundary between authoring, validation, and sign-off.

Key questions

Q: What breaks when AI-generated code is reviewed without security gates?

A: What breaks is the assumption that a clean-looking diff is a safe diff. AI-generated code can hide unsafe defaults, dependency issues, and weak validation that basic review misses. Without CI-enforced tests and security checks, the merge process becomes a distribution channel for defects rather than a control point.

Q: Why do AI coding assistants increase AppSec governance risk?

A: They increase risk because they optimise for speed and plausible output, not for context-aware security validation. In practice, that means developers can accept more code with less scrutiny, which raises the chance of vulnerable functions, exposed secrets, and compliance failures entering the repository and CI/CD pipeline.

Q: What do security teams get wrong about review loops in AI-assisted development?

A: Teams often assume a review loop automatically means control is preserved. In practice, the agent may still make substantial changes before the developer sees them, especially when planning is hidden or optional. The control issue is not whether review exists, but whether review happens early enough to constrain the change path.

Q: How should organisations govern AI-assisted development in secure pipelines?

A: They should treat AI-assisted coding as a controlled workflow with explicit owners, enforced policy checks, and measurable outcomes. Put controls in the IDE, pull request, and CI/CD stages, then monitor whether remediation time, flaw density, and exception rates improve. Governance should focus on who approved the change and what policy prevented unsafe code from merging.

Technical breakdown

Why AI code generation is not code review

Large language model coding assistants optimise for suggestion quality, speed, and developer convenience. They do not natively enforce application security policy, validate against organisational standards, or reliably assess whether a snippet is safe in the context of the surrounding repository. That is a structural limitation, not a tuning problem. Secure code review requires policy context, dependency awareness, auditability, and consistent enforcement across the delivery pipeline. A generated snippet can look plausible while still introducing insecure logic, vulnerable dependencies, or licence issues.

Practical implication: treat AI code generation as an input to review, not as a substitute for AppSec validation.

How vibe coding changes the attack surface in CI/CD

Vibe coding describes a workflow where developers accept AI-generated code with limited scrutiny, often to preserve speed. The risk is not only flawed code but also expanded blast radius, because insecure changes can move quickly from IDE to repository to build pipeline. Once that happens, downstream scanning has to catch issues that should have been blocked earlier. This changes the control point from post-commit detection to pre-commit enforcement, where context, policy, and developer feedback matter most.

Practical implication: shift critical checks left into the IDE and pull request path so risky code is stopped before merge.

Why secrets and malicious packages need policy enforcement, not just scanning

AI-assisted code often introduces hidden operational risk through embedded secrets, unsafe dependencies, or copied patterns that bypass human review. Scanning alone can detect some of this after the fact, but policy-based controls decide whether risky artefacts are allowed into the pipeline at all. That distinction matters for secrets management and software supply chain security. When AI-generated code can include credentials or dependency drift at scale, governance must cover detection, approval, remediation, and audit trail together.

Practical implication: enforce pre-commit policy gates for secrets, dependencies, and high-risk code paths rather than relying on later remediation.

Threat narrative

Attacker objective: The objective is to turn development speed into persistent software risk by getting insecure or secret-bearing code into trusted repositories and release paths.

1. Entry occurs when developers accept AI-generated code into the delivery workflow with limited scrutiny, often inside the IDE or during rapid prototyping.
2. Escalation happens when that code introduces insecure logic, exposed secrets, or vulnerable packages that move through CI/CD without meaningful human validation.
3. Impact follows when flawed code reaches production, creating exploit paths, compliance exposure, and repeated remediation work across the software estate.

NHI Mgmt Group analysis

Vibe coding is creating a separation-of-duties problem inside software delivery. When the same workflow can both generate and accelerate acceptance of code, human review becomes less reliable as a control boundary. That is a governance failure, not just a tooling gap. AppSec programmes should treat authoring and approval as distinct control functions, with policy gates between them.

AI-assisted development does not reduce the need for identity-bound accountability, it increases it. The more code is generated by assistants, the more important it becomes to know who approved the change, which policy applied, and which system enforced it. This is where IAM and auditability intersect with AppSec, because approval authority must remain explicit even when code production becomes machine-assisted.

Code generation is becoming a high-volume NHI-like workflow risk. The underlying pattern is similar to other non-human execution problems: a software system is producing artefacts that move through trusted pipelines faster than people can review them. That creates governance debt, especially where secrets, dependencies, and remediation actions are involved. The practical conclusion is that security teams should govern AI-assisted coding as a controlled machine workflow, not an informal productivity aid.

Pre-commit enforcement is now more important than post-commit detection. If insecure code is already merged, the organisation has accepted avoidable risk and created downstream cleanup work. Security teams should prioritise controls that prevent risky code, secrets, and dependencies from crossing the repository boundary in the first place.

AI-assisted code review needs measurable policy outcomes, not confidence statements. Organisations should track whether AI-generated changes are raising or lowering flaw density, remediation time, and policy exceptions. The useful question is no longer whether teams are using GenAI, but whether the delivery system can still enforce secure code standards at machine speed.

What this signals

Code governance is becoming an identity governance problem by another name. When AI tools can generate production-bound changes, the control question shifts from who typed the code to who authorised the resulting risk. That means organisations need clearer approval chains, stronger audit evidence, and pre-commit policy enforcement tied to trusted identities and workflow roles. The relevant standard is not just secure coding guidance, but also the control discipline reflected in NIST SP 800-53 Security and Privacy Controls.

The operational signal for practitioners is that speed metrics can hide control decay. If merge volume rises while exception handling, remediation time, and secret exposure rates deteriorate, AI assistance is amplifying governance debt rather than reducing it. Teams should align code security controls with the NIST AI 600-1 GenAI Profile where AI systems shape development outcomes, and with NIST SP 800-53 Rev 5 Security and Privacy Controls for access control and auditability.

Secure-by-policy development is the new threshold for machine-speed engineering. The practical test is whether a generated change can be stopped, explained, and traced before it reaches production. If that answer is no, the organisation has not operationalised AI in software delivery, it has only accelerated risk. For identity and AppSec leaders, that is a governance signal, not a tooling preference.

For practitioners

• Separate code generation from code approval Require a human approver who is not the author of the change, and make that approval explicit in the pull request workflow. Keep policy checks independent from the assistant that generated the code so review remains a real control, not a formality.
• Move AppSec enforcement into the IDE and pull request path Block high-risk code paths, vulnerable dependencies, and secret patterns before merge, not after deployment. Use pre-commit controls so the repository never becomes the first place security sees the issue.
• Treat secrets and package risk as pipeline policy events Apply enforced rules for credential exposure, dependency approval, and licence compliance so AI-generated suggestions cannot bypass organisational standards. Connect those checks to audit trails and exception handling.
• Measure whether AI assistance is changing flaw density Track remediation time, security flaw rates per fix, and policy exception volume for AI-assisted changes. If productivity rises while flaw rates stay flat or worsen, the delivery model is not improving security.

Key takeaways

• AI-assisted coding changes the AppSec problem from code creation to code governance, because speed now outpaces manual validation.
• The benchmark data cited in the article shows that insecure or flawed AI-generated code remains common, which means review gaps are a control issue, not a rare exception.
• Practitioners should enforce independent approval, pre-commit policy gates, and measurable remediation outcomes before AI-generated code is allowed into production.

Key terms

• Vibe Coding: A development pattern where engineers accept AI-generated code with limited scrutiny because speed is prioritised over validation. In security terms, it creates a governance gap between code production and code review, which can allow insecure logic, secrets, and vulnerable dependencies to move through trusted pipelines.
• Segregation of Duties: Segregation of Duties is a control principle that prevents one person or role from combining incompatible permissions that could create fraud, error, or undetected change. In ERP environments, it must account for roles, transactions, approvals, and compensating controls across business processes.
• Pre-commit Enforcement: Security controls that block risky code, credentials, or dependencies before they are merged into a repository. This is more effective than relying only on post-commit scanning because it stops unsafe artefacts at the point where they first enter the trusted software supply chain.
• AI-Assisted Code Review: The use of AI tools to help evaluate code quality, risk, or remediation options. It is useful for prioritisation and explanation, but it should not be confused with independent validation, because code generation systems are not inherently designed to enforce policy or guarantee security.

What's in the full article

Checkmarx's full analysis covers the operational detail this post intentionally leaves for the source:

• Benchmark methodology behind the AI-generated code quality comparisons and remediation cost assumptions
• Product workflow details for pre-commit detection, policy gating, and audit trail generation
• Examples of how security fixes are proposed without breaking surrounding application logic
• Performance and risk metrics used to compare remediation outcomes across development scenarios

👉 Checkmarx's full post covers the benchmark data, remediation economics, and workflow controls in more detail

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 security practitioners connect identity controls to broader governance and delivery risk.