The rise of AI-assisted development has introduced a new category of security vulnerability that engineering leaders can no longer ignore. What makes this trend especially dangerous is its rapidly expanding scope. Ad hoc use of AI tools across functions such as marketing, operations, and even executive leadership increases the likelihood of unreviewed software entering production paths. When a CEO can rage-code an entire company website during a missed flight and publish it over the production site, the traditional boundaries of code review have collapsed entirely.
Vibe coding pushes security failures into production faster
Tanya Janca, OWASP distinguished member and project leader for the OWASP Top 10 2025, frames this risk with precision. She notes that vibe coding occurs when developers commit AI-generated code without understanding, verifying, or taking ownership of what they have produced.
"To me, vibe coding is the AI's writing everything, you have no time to review it, or you're not taking the time to review it, and you're just committing what the AI says."
This isn't theoretical. During a recent secure coding workshop with 60 participants, Janca demonstrated the problem in real time. Every attendee used the same security-focused prompt and the same build instructions. Fifty-nine received solid, secure code. For the sixtieth, the AI added a Python linter comment to ignore the following lines, and then intentionally leaked secrets into the code.
The example underscores a critical reality. Prompt quality alone cannot eliminate the need for secure code review. Even when developers use security-oriented prompts built from comprehensive secure coding guidelines, AI outputs can still introduce ignored lint checks, expose secrets, or silently remove essential protections during language transitions. The problem extends beyond obvious syntax issues to include missing error handling, hidden insecure changes, and the possibility of chained weaknesses that automated systems can combine faster than defenders expect.
Developer security now defines supply chain resilience
The conversation around supply chain security has historically focused on vulnerable packages, but Janca argues the scope must expand dramatically to include repositories, CI pipelines, secrets handling, deployment controls, and every stage involved in creating and maintaining software.
More importantly, she challenges how the industry categorizes incidents. Many so-called supply chain attacks are better understood as compromises of developer accounts as an attack surface. When security vendors claim to protect the supply chain but only scan for vulnerable dependencies, they are addressing perhaps one-nineteenth of the actual problem.
"But if you look at some of the things that they call a supply chain attack, what actually happened for some of the biggest ones is it was actually one software developer employee, one human being that was compromised."
A single highly privileged engineer can expose multiple systems at once. This reality demands a fundamental shift in how organizations approach supply chain security as both a technical problem of package management and a human problem of protecting the developers themselves.
Janca offers practical guidance that engineering leaders can implement immediately. First, disable post-install scripts by default across the entire organization. While this will break some things initially, teams will identify those dependencies quickly and can then examine each post-install script to determine whether it is trustworthy before running it.
Second, delay npm auto-updates long enough for ecosystem issues to surface. Making auto-updates apply only to packages seven days or older gives the npm ecosystem time to identify and address compromised packages, a process that typically happens within 24 to 48 hours.
Janca stresses that organizations must protect their developers. This means securing their workstations, locking down their online accounts, providing password managers, and actively teaching digital safety. Package compromise isn't new, but AI-driven development increases the speed and scale at which poisoned dependencies can spread across builds and environments. Protecting the supply chain is inseparable from protecting developers through stronger security habits. The software developer has become the target, and organizations must treat developer security as a first-class concern.
Security in code generation cuts review bottlenecks
The traditional AppSec model is breaking down under the pressure of modern development speed. Janca argues that many current application security programs are too slow, too noisy, and too expensive, making them easy to circumvent unless they are redesigned for how developers actually work.
The central recommendation is straightforward but represents a significant operational shift. Engineering teams must move security into code generation rather than relying on large downstream review queues that developers increasingly bypass under delivery pressure. Janca advises embedding as much security as possible directly into the code generation phase before moving on to code review and other standard steps.
This shift-left approach serves as both a security and cost strategy. Earlier constraints reduce rework, cut token waste in AI workflows, and prevent static analysis from becoming an unmanageable backlog. When developers are expected to produce 100x the code they previously did, running a static analysis tool that returns five trillion bugs creates a review queue that simply gets ignored.
Secure code review becomes more effective when it follows better generation practices, rather than serving as the first serious checkpoint after large amounts of code already exist. The conversation positions this not as replacing review, but as making review tractable and meaningful.
Janca treats OWASP Top 10 2025 as a useful awareness tool, but not a complete operating model. Once teams care about security and understand the fundamental reasons behind it, the priority should shift to actionable practices developers can apply earlier in the process. The goal is pattern recognition and good habits, not memorizing vulnerability lists.
Organizations that continue to rely on downstream security gates will find themselves fighting a losing battle. The water will flow around the obstacles, and the security team will lose visibility into what is actually being built and shipped.
AI coding stays secure when developers own every output
AI-assisted coding offers genuine value when used with clear guardrails, but only when developers maintain responsibility for the outputs. The expectation must be that developers still review code, understand what it does, and treat the result as their own work.
Janca has developed a prompt-based approach to embed security requirements into generation. This includes reusable prompts for APIs, threat modeling, and secure coding tasks that aim to improve results before code is written. The prompt library, available at securemyvibe.ca, provides a main system prompt that runs every time code is generated, plus specialized prompts for different scenarios such as code review, API development, and threat modeling.
The prompts guide developers through filling in context and create security requirements tailored to their specific needs. For instance, if building authentication from scratch, the prompts generate the security requirements necessary to avoid common pitfalls.
But even with these controls, AI can still produce unsafe outputs. Human verification remains essential. Janca notes that if developers are going to submit work as their own, they must thoroughly understand it. If a piece of generated code is confusing, they should ask the AI to walk them through it line by line.
Secure use of AI is linked to developer security training, especially teaching pattern recognition for core controls such as input validation, error handling, and safe defaults. Janca emphasizes teaching the defenses rather than memorizing attack vectors. Instead of learning 600 CVEs, developers should learn the patterns that prevent vulnerabilities. For example, teach them to always lock the door before leaving rather than memorizing every possible way a burglar might break in.
The overall message is that AI should augment disciplined engineering practices, not replace them. Organizations need to modernize workflows around how developers actually use these tools, but without abandoning the fundamental responsibility to understand and own the code being shipped.
Secure defaults make the fastest path the safest path
Security succeeds when the easiest path is also the safest one. This principle, often repeated but rarely implemented, becomes critical in an era of AI-assisted development where the volume and velocity of code creation has increased exponentially.
"Software developers are like water. They can go around any technical control we give them if they really want to."
Developers will route around friction, policy, or tooling that slows them down without clear value. This isn't malicious, it is pragmatic. When business incentives reward only feature throughput and leave no time for review, remediation, or threat modeling, developers optimize for what gets measured and rewarded.
Secure defaults work because they leverage behavioral design. Teams are more likely to follow protective practices when those choices are preselected in environments, workflows, and templates rather than left as optional effort. The organ donor analogy makes this concrete. Countries where organ donation is opt-out have 90-plus percent participation, while opt-in countries see dramatically lower rates. The goal is to re-architect systems so that developers are naturally guided by secure defaults, strong policies, and a supportive culture, making the happy path inherently the secure path.
Golden paths become especially important for security controls such as authenticated setup, package management, documentation, and review expectations. These reduce reliance on individual vigilance and make security the path of least resistance.
Janca warns that organizational incentives often undermine secure behavior. Companies claim to take security seriously while giving developers zero time to fix bugs, excluding security work from project schedules, and promoting only based on feature delivery. These perverse incentives reveal what organizations actually value, regardless of what they say.
A more pragmatic security culture distinguishes genuine business risk from low-value fights. Not every security standard requires a battle. A static webpage running TLS 1.2 instead of 1.3 doesn't warrant the same response as exposed authentication credentials. Dying on every hill means dying every day, damaging relationships, and ultimately getting less of what you want.
The path forward requires collaboration with developers to make secure practices realistic and durable. This means understanding why developers route around security controls, redesigning those controls to reduce friction, and aligning incentives so that secure behavior is also rewarded behavior. Security teams must meet developers where they are, not where security professionals wish they would be.
Shifting security left builds resilient organizations
The security challenges facing engineering organizations have never been more complex or more urgent. Vibe coding, supply chain vulnerabilities, and the speed of AI-assisted development have created a threat landscape that traditional security practices cannot address.
But the solution isn't more tools, more gates, or more compliance theater. It is about shifting security left into code generation, protecting developers as critical infrastructure, and redesigning workflows so that the secure path is the easy path. Engineering leaders who embrace these principles and treat security as a practice rather than a product will build more resilient organizations capable of shipping fast without breaking everything in the process.
To hear more of Tanya Janca's insights on vibe coding, securing the supply chain, and managing developer security, listen to her full episode on the Dev Interrupted podcast.
