Vibe coding is exposing AppSec gaps in AI-driven software delivery

At a glance

What this is: This analysis argues that vibe coding changes where and how application security must intervene, with the biggest gap appearing when AI-generated code outpaces traditional AppSec gates.

Why it matters: IAM and NHI practitioners should care because the same context-driven control problems now show up in agentic workflows, service identities, and policy enforcement across the software lifecycle.

By the numbers:

• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.

👉 Read Backslash Security's analysis of vibe coding and AppSec for AI-driven development

Context

Vibe coding is a development style where AI helps generate and revise code inside the IDE while developers move quickly and make fewer upfront design decisions. That speed is useful for delivery, but it also expands the attack surface and weakens the usefulness of controls that assume slower, more linear software creation.

For NHI governance, the lesson is straightforward: when code changes faster, secrets, tokens, service accounts, and agent permissions tend to change faster too. Existing AppSec models that rely on broad scanning and delayed triage do not map well to that pace, which is why the security problem now looks much closer to lifecycle governance than point-in-time review.

Backslash Security frames this as a shift in where AppSec must operate, not a replacement of security teams. That starting position is increasingly typical across organisations trying to secure AI-assisted development without breaking developer flow.

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 vibe coding increase application security risk?

A: Because it increases the volume and speed of code changes faster than traditional review and scanning can absorb. That compresses decision time, expands dependency usage, and makes exposure harder to track. The risk comes from scale and timing, not from AI alone.

Q: What is the difference between scanning code and governing AI-generated code?

A: Scanning finds problems after they exist, while governance shapes the conditions that produce the code in the first place. For AI-generated code, teams need policy, context, and remediation in the developer workflow. Otherwise the organisation only learns about risk after it has already spread.

Q: When does AI-assisted development create more risk than it reduces?

A: It becomes net risk when code volume grows faster than ownership, review, and fix capacity. That is especially true when secrets, dependencies, and business logic are handled in separate tools. If teams cannot prioritise by reachability and impact, speed turns into hidden debt.

Technical breakdown

Why vibe coding changes the AppSec control point

Vibe coding pushes security decisions earlier into the IDE, where AI suggestions can shape insecure patterns before they become committed code. In practice, the control point moves from after-the-fact scanning to inline policy enforcement, prompt shaping, and context-aware suggestion filtering. This matters because many failures are no longer isolated vulnerabilities. They are combinations of code, dependency choice, secret handling, and business logic that only become visible when execution context is known. A static scanner can still find defects, but it cannot reliably infer intent or risk in a fast-moving AI-assisted workflow.

Practical implication: Security teams need controls that influence code generation and editing, not just scans that run after the fact.

How security debt grows at AI scale

Security debt accumulates faster when AI increases code volume without a matching increase in review capacity. Each new package, function, and service adds maintenance overhead, and vulnerable dependencies often remain in circulation long after they were introduced. The problem is not just volume. It is time lag, because findings, fixes, and revalidation happen too slowly relative to the pace of delivery. That creates a widening gap between the state of code in development and the state of code in production, especially where secrets, packages, and policy checks are handled separately.

Practical implication: Treat remediation as a continuous workflow with automated guidance, not as a ticketing problem.

What an AppSec modeling engine has to understand

A modelling engine in this context must connect static analysis, software composition analysis, secret discovery, and code-path reachability into one view of exposure. That is different from stacking tools side by side. The key is understanding whether a finding is reachable, whether the package is active, whether the secret is live, and whether the code path matters to the business service. Without that joined-up context, teams get noise instead of prioritisation, and autonomous fixes become risky because the system cannot distinguish cosmetic issues from material exposure.

Practical implication: Unify code, dependency, and secret context before you try to automate remediation decisions.

Threat narrative

Attacker objective: The attacker aims to reach live application code, secrets, or service paths before defenders can detect and remediate the exposure.

1. Entry occurs when AI-assisted development introduces vulnerable patterns or exposed secrets into code faster than security review can keep pace.
2. Escalation happens when those weaknesses spread across packages, repos, or services before teams notice the pattern.
3. Impact is the accumulation of reachable exposure, longer-lived security debt, and a larger blast radius for later exploitation.

Breaches seen in the wild

• DeepSeek breach — DeepSeek breach exposed 1M+ log lines and sensitive secret keys.
• JetBrains GitHub plugin token exposure — CVE-2024-37051 in JetBrains IntelliJ GitHub plugin exposed GitHub access tokens.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Vibe coding is not primarily a code-quality problem. It is a governance problem created by compressed decision cycles. When developers and AI systems generate more code in less time, the real control gap is not whether a scanner exists. It is whether policy, review, and remediation can operate at the same speed as the IDE. Practitioners should treat this as a lifecycle governance issue, not a tooling refresh.

AppSec has to move from gatekeeping to continuous influence. The article’s strongest point is that security teams cannot wait until CI or post-commit review to intervene. They need to shape prompts, defaults, and remediation options while code is still in motion. That is the only way to reduce rework without creating developer friction that gets bypassed.

Security debt now behaves like identity debt in NHI programmes: it compounds when ownership, scope, and expiry are unclear. AI-assisted coding makes unresolved issues spread faster across repositories and environments, which means teams must manage exposure as a living inventory. The practical conclusion is to measure risk by reachability and business impact, not by raw finding counts.

AppSec MCP-style integration signals where the market is heading: toward context-sharing layers instead of isolated scanners. The important shift is not the protocol label itself but the operating model behind it. Security tools that can share context with IDEs, CI systems, and remediation workflows will define how teams govern AI-generated code. Practitioners should expect platform convergence around context, policy, and automation.

The central mistake is assuming AI will replace AppSec rather than re-balance it. Human security judgment still matters, but its value moves upward into policy design, exception handling, and risk acceptance. The day-to-day work becomes more automated, while the governance burden becomes more explicit. Teams that recognise that shift will be better prepared for agentic software development.

From our research:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.
• Use DeepSeek breach to examine how exposed secrets and sensitive records can scale when governance fails across development and data flows.

What this signals

AppSec programmes should expect the governance burden to move closer to the developer desktop. The practical change is that policy has to become contextual, embedded, and faster than the commit cycle. Teams that still rely on post-hoc review will struggle as AI-assisted delivery keeps compressing time between code creation and exposure.

With 27 days as the average estimated time to remediate a leaked secret, the gap between detection and action is already wide enough to matter for NHI programmes, according to The State of Secrets in AppSec. That lag will become more painful as AI-generated code increases the number of secrets, dependencies, and privilege decisions per release. The programme response is to combine discovery, ownership, and automated routing before the backlog grows further.

Context-sharing architectures will matter more than isolated security tools. As AI-assisted development spreads, the useful question is no longer which scanner found the issue. It is whether the IDE, CI pipeline, and remediation workflow share enough context to act on the issue correctly the first time.

For practitioners

• Push security rules into the IDE Define policy-compliant prompts, safe defaults, and blocked patterns before code reaches review. The goal is to influence generation, not simply reject bad code later. This is where secure-by-default behaviour reduces rework.
• Automate dependency risk triage Use reachability, package usage, and known vulnerability data to prioritise fixes that affect real execution paths. Do not treat every dependency alert as equal, because AI-driven coding inflates alert volume quickly.
• Shorten the remediation loop Offer guided fixes in the developer workflow so teams can patch, upgrade, or replace risky components while the issue is still fresh. The value is in compressing time between detection and action.
• Unify secrets and code visibility Bring secret discovery, code analysis, and ownership data into one operating view so teams can see which exposures are active and where they live. Fragmented views make AI-scale debt harder to contain.
• Measure risk by reachability and impact Replace raw issue counts with metrics that show whether a finding is exploitable, business-relevant, and still present in production-facing services. That is the only way to triage at AI speed.

Key takeaways

• Vibe coding raises application security risk by compressing the time available to review, prioritise, and remediate code changes.
• Secrets, dependencies, and code paths now need to be governed together because isolated scanning cannot keep up with AI-assisted delivery.
• Security teams should move policy into the IDE and measure exposure by reachability and impact, not by issue counts alone.

Key terms

• Vibe Coding: A rapid software development style in which developers rely on AI-generated suggestions, iterative prompting, and fast feedback loops rather than heavy upfront design. It increases delivery speed, but it also changes how security controls must operate because code creation, review, and remediation happen much faster.
• 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.
• AppSec Modeling Engine: A security analysis layer that combines code context, dependency information, secret discovery, and execution reachability into one view of risk. It is meant to help teams distinguish material exposure from noise so they can prioritise fixes and automate only where the context is strong enough.
• AppSec MCP Server: A context-sharing interface that connects application security tools, IDEs, CI pipelines, and policy systems through the Model Context Protocol. In practice, it helps security functions exchange state and guidance in a form that can support automation and inline developer assistance.

Deepen your knowledge

Vibe coding and secure-by-default AppSec are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your team is trying to govern AI-assisted development without slowing delivery, it is worth exploring.

This post draws on content published by Backslash Security: Vibe-Securing: 4+1 Pillars of AppSec for Vibe Coding. Read the original.