Vibe coding security vulnerabilities are creating a new AppSec blind spot

At a glance

What this is: AI coding assistants are introducing a fast-growing application security blind spot by shipping insecure patterns, phantom dependencies, and outdated libraries into production.

Why it matters: This matters because AppSec teams now have to govern AI-generated code with the same rigor as third-party code, while also accounting for identity, privilege, and supply chain risks.

By the numbers:

• 85% of organizations have adopted AI coding assistants, yet only 9% consider AI-driven AppSec analysis a must-have capability.
• Only 38% of organizations use AI to support code review in pull requests, leaving most AI-generated code without automated security feedback.
• Research from the Cloud Security Alliance and Endor Labs found that 62% of AI-generated code contains design flaws or vulnerabilities.
• Veracode reported that 45% of AI-produced code fails against the OWASP Top 10.

👉 Read Kusari's analysis of vibe coding security vulnerabilities and AI-generated code risk

Context

Vibe coding security vulnerabilities arise when AI assistants generate code from natural-language prompts with minimal manual review, allowing insecure patterns and unvetted dependencies to enter the software supply chain. The primary issue is not that AI writes code, but that teams often accept generated output without equivalent security scrutiny, especially when the code touches authentication, authorization, data handling, or package management.

For application security teams, the governance gap is clear: code creation has been automated faster than code verification. That creates an identity and privilege intersection as well, because AI-generated application logic often shapes access control, token handling, and service-to-service trust. This post frames the problem through AppSec, but the implications reach IAM, PAM, secrets management, and workload identity when generated code controls privileged paths.

The starting position described in the article is increasingly typical, not exceptional. AI coding tools are now common in development workflows, while formal security review for AI-generated code remains uneven.

Key questions

Q: How should security teams implement controls for AI-generated code in pull requests?

A: Security teams should make pull request scanning the default control point for AI-generated code. Combine SAST for insecure logic and SCA for dependencies, then block merges when the pipeline finds severe issues. The goal is to move review from informal human judgement to enforceable policy before code reaches the main branch.

Q: Why do AI coding agents increase supply-chain risk?

A: AI coding agents can choose tooling, install packages, and edit lock files in ways that may bypass the controls humans expect in a managed environment. That widens the blind spot around untracked software and makes package provenance harder to enforce. The practical response is to restrict agent permissions, inventory their workspaces, and review their install behaviour like any other privileged automation.

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 organisations reduce risk without stopping AI-assisted development?

A: Organisations should keep AI assistance but make the secure path the easiest path. That means secure prompt guidance, mandatory scanning, dependency allowlists, and extra review for security-critical code paths. The aim is not to ban speed, but to make sure productivity gains do not bypass the controls that protect production systems.

Technical breakdown

How hallucinated dependencies become a software supply chain risk

Large language models can invent package names that look real, especially when the prompt asks for libraries by function rather than by registry name. In vibe coding workflows, developers may copy the suggestion directly into a build file, which creates an opening for dependency confusion or typosquatting if an attacker registers the phantom package. The core issue is trust in generated references without registry verification, not just insecure code. This is a software supply chain problem because the attack enters through package selection, then propagates through CI/CD and deployment pipelines.

Practical implication: block unknown dependencies at pull request time and require registry validation before any new package enters the build.

Why AI-generated code maps so often to OWASP Top 10 failures

AI models learn from a huge mix of clean examples, insecure samples, and outdated patterns, so they frequently reproduce broken access control, injection flaws, weak cryptography, and misconfiguration. The model is optimising for plausibility and task completion, not for the application’s threat model. That is why generated code can look correct while still violating core security properties. The risk is especially high in authentication and authorization logic, where small mistakes become systemic privilege exposure.

Practical implication: tune SAST rules to prioritise access control, injection, and identity handling in AI-generated code paths.

How pull request scanning closes the review gap for AI code

Pull request scanning changes the control point from post-merge discovery to pre-merge prevention. SAST finds insecure logic patterns, while SCA catches vulnerable or untrusted dependencies before they are merged. For AI-generated code, this matters because the review burden shifts from the developer remembering every security rule to the pipeline enforcing them consistently. Without that gate, the code review process depends too heavily on human vigilance and familiarity with generated output patterns.

Practical implication: require automated SAST and SCA gates on every pull request that includes AI-generated changes.

Threat narrative

Attacker objective: The attacker wants malicious code or exploitable logic to reach production through trusted development workflows.

1. Entry occurs when a developer accepts AI-generated code that includes a hallucinated dependency or insecure pattern.
2. Escalation follows when the dependency is installed or the flawed code is merged into a trusted branch and deployed.
3. Impact appears as supply chain compromise, access control weakness, or exploitable application logic in production.

NHI Mgmt Group analysis

AI-generated code is now a governance problem, not just a productivity trend. Once developers accept model output into production, the security model must treat generated code as untrusted input until verified. That means AppSec, IAM, and platform teams need shared ownership of review gates, dependency policy, and sensitive-path controls. The practical conclusion is simple: code provenance now belongs in security governance.

Hallucinated dependencies create a new form of supply chain trust gap. The problem is not only that the package may be malicious. It is that developers are delegating dependency choice to a model that has no authoritative view of what exists in the registry or what is approved internally. This is a direct challenge to software composition management and a useful reminder that identity and trust must extend to code inputs. The practical conclusion is to validate every new package as if it were an external principal.

Access control failures in AI-generated code are especially dangerous because they compound downstream identity risk. When generated code weakens authorization, token handling, or session logic, the flaw is not isolated to the application layer. It can expose service accounts, API keys, and privileged workflows that sit behind the application. That makes this an NHI-adjacent problem as well as an AppSec problem, because compromised application logic can become a path to privileged non-human identities. The practical conclusion is to review AI-generated code that touches authentication and secrets as high risk by default.

AI code review needs to be engineered as a default control, not a discretionary check. Kusari's figures show adoption racing ahead of security maturity, which is exactly how blind spots form. The gap is not awareness but enforcement, and enforcement only happens when scanning, policy, and developer workflow are integrated at the pull request layer. The practical conclusion is to make automated review unavoidable for code generated by AI assistants.

What this signals

AI-generated code now sits on the boundary between application security and identity governance. When generated logic controls authentication, token handling, or secret retrieval, teams need to treat code review as a trust control, not just a developer productivity step.

Generated-code trust gap: the gap between code creation and code verification is now large enough to be a governance category of its own. Teams that instrument pull request policy, dependency approval, and identity-sensitive code review will have a clearer line of defence than teams that rely on developer judgement alone.

For NHI and IAM programmes, the practical signal is that application code can create or expose privileged service accounts just as easily as it can expose user access. That makes secrets handling, workload identity, and privilege boundaries part of the same control conversation.

For practitioners

• Implement pull request gates for AI-generated code Require SAST and SCA scans on every pull request that contains AI-assisted changes, with policy blocking merges until severe findings are resolved.
• Block unvetted dependencies by default Use an allowlist or approval workflow for any new package reference, and validate package names against trusted registries before build execution.
• Tag AI-assisted changes in the delivery pipeline Use commit metadata, IDE plugins, or repository labels so security teams can measure where AI-generated code enters the codebase and whether it passes review.
• Treat generated auth and secrets logic as high risk Apply manual review to AI-generated code paths that handle authentication, authorization, token validation, session creation, or secret retrieval.
• Feed recurring patterns back into developer guidance Create internal prompt guidance that requires secure defaults such as parameterized queries, explicit authorization checks, and approved libraries in AI prompts.

Key takeaways

• AI-assisted development is expanding the AppSec attack surface faster than manual review can scale.
• The biggest near-term failure mode is trust in invented dependencies and plausible but insecure code patterns.
• Automated pull request controls are now the most practical way to govern AI-generated code before it reaches production.

Key terms

• Vibe Coding: A software development approach where natural-language prompts drive much of the implementation and AI produces the code. In practice, the term covers a wide range of control levels, from no-review prototyping to structured engineering with tests, review, and architecture held by humans.
• Hallucinated Dependency Provenance Gap: The hallucinated dependency provenance gap is the difference between a package name that appears credible and a package origin that has never been verified. It becomes dangerous when model suggestions, automation, and install-time execution let plausibility outrun source validation.
• Pull Request Security Gate: An automated control that blocks code from merging until it passes checks such as SAST, SCA, policy validation, and dependency approval. For AI-generated code, this gate matters because it shifts security review earlier, before flawed or unvetted code reaches the main branch.
• AI-Generated Code Risk: AI-generated code risk is the possibility that model-produced output introduces insecure credential handling, hidden secrets, or repeated patterns that weaken control design. The risk is operational, because the output can be merged quickly and at scale before humans catch the problem.

What's in the full article

Kusari's full report covers the operational detail this post intentionally leaves for the source:

• Survey methodology behind the 85% adoption and 9% must-have figures, useful for benchmarking your own programme.
• Per-language failure patterns, including where Java and other stacks showed the highest secure-generation failure rates.
• Practical examples of pull request scanning rules that target transitive dependencies, typosquatting packages, and insecure patterns.
• Developer workflow examples for secure prompt design and dependency policy enforcement.

👉 Kusari's full post covers the adoption gap, dependency threat patterns, and review controls in more implementation detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, secrets management, workload identity, and agentic AI identity. It helps practitioners connect code security with the identity controls that protect production systems.