What Every CISO Needs to Know About AI-Assisted Development 

There’s a conversation happening in boardrooms, security operations centers, and developer standups that I find both thrilling and concerning: the conversation about AI-assisted development. Engineering teams are shipping features in hours that once took months. Products that would have required six-month roadmaps are being prototyped in a weekend. The sheer velocity is staggering — and if you’re a CISO who hasn’t fully grappled with what that means for your security program, this post is for you. 

I’ve spent my career building security programs at organizations like Dow Jones/WSJ, J2 Global, and CarGurus. I’ve seen security evolve from a checkbox function to a business-critical discipline. But nothing has accelerated that evolution — or stress-tested the programs we’ve built — quite like the rise of AI-assisted development. The question I keep coming back to is this: if your developers are using AI to write code at 10x the speed, is your security program running at 10x the speed to match? For most organizations, the honest answer is no. If that’s you, here’s what you need to know. 

The New Reality: AI-Assisted Development Is Already Here 

Let me be direct: AI-assisted development is no longer a pilot program or a forward-looking experiment. It is the default mode of software production for a growing majority of engineering teams. Coding assistants, AI pair programmers, and generative code completion tools are embedded in developer IDEs across every industry. Developers are not just accepting AI suggestions — they are prompting AI to generate entire functions, modules, and in some cases, complete application scaffolds. 

This shift is, in many ways, genuinely positive for business. Delivery cycles are compressing. Developer capacity is expanding. Organizations are able to respond to market demands with a speed that was simply not achievable two years ago. The problem is that speed is a one-sided gift unless you apply it to security too. And right now, most organizations are letting that one-sidedness compound into real exposure. 

Key Stats at a Glance 
– 45% of AI-generated code contains known security vulnerabilities when no security guidance is provided 
– 55% average security pass rate across 150+ LLMs tested — flat for two years running  
– 82% of organizations carry security debt, up 11% in one year  

The Hard Truth About AI-Generated Code Security 

Here’s the data point that should fundamentally shape every CISO’s strategy for AI-assisted development: according to Veracode’s ongoing research program — covering over 150 large language models — only 55% of AI code generation tasks result in secure code. That means in 45% of cases, the model is introducing a known security flaw into your codebase. 

Let that number sit for a moment. Nearly half the code your developers are accepting from AI tools may contain vulnerabilities. 

And before you ask: no, upgrading to the latest flagship model doesn’t automatically solve the problem. In our Spring 2026 testing of the most hyped releases — GPT-5.1 and 5.2, Gemini 3, and Claude 4.5 and 4.6 — security pass rates remained flat compared to their predecessors. GPT-5.1 and 5.2 showed no meaningful security gains over GPT-4.1. Gemini 3 clustered in the same 55–60% pass rate band we’ve seen for years. Claude 4.5 and 4.6, while genuinely excellent at producing syntactically correct code, showed no improvement in security performance. 

Syntax correctness now exceeds 95% across models. Security pass rates haven’t moved. The models are getting better at writing code that compiles and runs — they are not getting better at writing code that is secure. 

There is one notable exception: OpenAI’s reasoning-focused models, where extended reasoning capabilities appear to meaningfully elevate security pass rates to the 70–72% range. That’s a meaningful step forward. But it still means roughly 28–30% of outputs contain security issues even in the best-case scenario, and most organizations aren’t exclusively using those models. 

The practical implication for security leaders is clear: AI-assisted development cannot be trusted to self-regulate from a security standpoint. The human element, the tooling overlay, and the programmatic guardrails you put in place around AI-generated code are not optional enhancements — they are the primary security layer. 

What Makes AI-Assisted Development Uniquely Risky 

If AI simply replicated the security profile of human-written code, the risk calculus would be straightforward. It doesn’t. There are several characteristics of AI-assisted development that create specific and amplified risks that CISOs need to understand. 

Volume and velocity compound existing vulnerabilities. The security debt problem in most organizations is already severe. According to Veracode’s 2026 State of Software Security report, 82% of organizations are carrying security debt — a figure that has grown 11% in a single year. Now introduce an AI-assisted development pipeline that multiplies code output by an order of magnitude, and the math becomes unforgiving. The same failure rate applied to ten times as much code means ten times as much vulnerable code entering your systems. 

AI can frequently introduce OWASP Top 10 vulnerabilities. The vulnerability classes that AI-assisted development produces are not obscure or exotic — they are the foundational categories that security professionals have been prioritizing for decades. In almost half of test cases, AI models introduced detectable OWASP Top 10 vulnerabilities, including SQL injection (CWE-89) and Cross-Site Scripting (CWE-80). These are well-understood, heavily documented vulnerability classes. The fact that AI is reproducing them at scale tells us something important: these models are trained on code from the public internet, and a significant portion of that code is insecure. The models are learning from — and replicating — the security mistakes of the past. 

Third-party dependencies are an accelerating blind spot. AI-assisted development doesn’t just write first-party code — it pulls in libraries, frameworks, and open-source components at a pace that outstrips human review. Developers may not even realize what their AI tool has imported, let alone whether those transitive dependencies carry known vulnerabilities. Also, AI tools can even hallucinate packages which attackers then typosquat on with a malicious package. The software supply chain risk associated with AI-assisted development is, in many ways, the most insidious dimension of the problem, because it is the least visible. 

“Vibe coding” introduces novel logic vulnerabilities. There’s a style of development that has emerged alongside AI-assisted development where developers describe what they want in natural language and accept the output with minimal review. The functionality works. The tests pass. But the business logic embedded in that code may contain flaws that no static analyzer would catch — because they’re not strict coding errors, they’re architectural or flow-level decisions that only become apparent in a running application under real-world conditions. 

The CISO Imperative: Match Security Momentum to Development Velocity 

So what does all of this mean for how CISOs should be running their programs? In my view, the answer is not to slow down AI-assisted development — that ship has sailed, and frankly, the competitive benefits of AI adoption are too significant to forfeit. The answer is to transform your security program so it operates at the same velocity. 

Here’s how I think about it. 

Shift from volume-based metrics to risk-based prioritization. One of the most persistent failures in vulnerability management is the reliance on traditional metrics: how many vulnerabilities were found, how many were patched, what’s the backlog count. These metrics made more sense in an era where code was written slowly enough that the numbers were manageable. In an AI-assisted development environment, the raw volume of findings will expand dramatically. You cannot patch your way to security if you’re measuring patches per sprint. What matters is whether you’re addressing the vulnerabilities with the highest business impact — the ones that are exploitable, that touch critical systems, that represent real exposure to the organization. 

This is a mindset shift as much as a process change. It requires your team to stop counting and start contextualizing. 

Build security into the AI-assisted development pipeline, not onto it. There’s a critical difference between security that is integrated into the development workflow and security that is applied as a post-hoc gate before deployment. The first creates continuous feedback loops that developers can act on in real time. The second creates a bottleneck that development teams are incentivized to route around. 

For AI-assisted development specifically, this means deploying Static Application Security Testing (SAST) directly in the IDE — so that when a developer accepts an AI suggestion, the security scan is happening immediately, before the code is even committed. It means Software Composition Analysis (SCA) that automatically identifies and evaluates the open-source dependencies pulled in by AI-generated code. It means that a Package Firewall blocks malicious packages before they enter production. And it means Dynamic Application Security Testing (DAST) integrated into the CI/CD pipeline so that AI-generated applications are tested in a running state, catching the runtime flaws and business-logic vulnerabilities that static analysis can miss. 

Not one of these in isolation — all three, layered, continuous, and embedded where developers actually work. 

Use AI to fix what AI breaks. This might sound counterintuitive, but one of the most powerful levers available to security teams right now is the use of AI-powered remediation to address the vulnerabilities that AI-assisted development introduces. The data here is compelling: automated remediation guidance can yield a 200% faster Mean Time to Remediate (MTTR) compared to traditional methods, and teams using these approaches have reported a 50% reduction in flaw density. Rather than letting AI-introduced security debt accumulate into an ever-growing backlog, you use AI to burn it down at a comparable pace. 

The key distinction is that not all AI remediation is equivalent. Generic large language models trained on the public internet — the same models that are producing insecure code in the first place — are unreliable for security remediation, precisely because they’ve learned from the same insecure patterns. Purpose-built remediation tools trained on verified, curated security fixes operate at a fundamentally different level of trustworthiness. That’s a distinction worth interrogating carefully when evaluating your tooling options. 

Don’t forget the supply chain. In my experience, the instinct when an organization adopts AI-assisted development is to focus on the first-party code being generated. That’s the right place to start, but it’s not sufficient. The AI tools themselves are part of your software supply chain. The open-source components they pull in are part of your software supply chain. The models those tools are built on introduce their own provenance and integrity questions. A robust AppSec program in the AI era has to address the full supply chain — not just the code your developers write, but everything that code depends on and everything that produced it. 

The Organizational Dimension 

I want to address something that often gets lost in the technical conversation about AI-assisted development: the organizational and cultural dimension. 

Security teams and development teams are not natural allies. That’s an uncomfortable truth, but it’s a real one. Development teams are rewarded for shipping. Security teams are rewarded for not having incidents. These incentive structures create friction, and AI-assisted development has a tendency to amplify that friction — because the developers who are most excited about AI productivity gains are often the ones most frustrated when security gates slow them down. 

CISOs who are going to succeed in the AI-assisted development era are the ones who reframe security not as a barrier to velocity, but as an accelerant of it. When developers have real-time feedback from IDE-integrated scanning, they’re not slowing down — they’re catching issues before they become costly defects. When AI-powered remediation offers a one-click fix rather than a weeks-long investigation, developers are more likely to engage with the security process rather than defer it. When security debt is measured by risk impact rather than raw volume, teams can focus their energy on what actually matters rather than grinding through a never-ending backlog. 

That reframe is fundamentally a leadership challenge. It’s the CISO’s job to make the case — to the board, to the CTO, to the engineering organization — that the value proposition of integrating security into AI-assisted development is not about adding friction. It’s about enabling sustainable velocity. 

A Moment of Honest Assessment 

I’ve been in security long enough to have lived through several waves of “this changes everything” technology: cloud computing, DevOps, mobile, and more. Each of them created genuine disruption to security programs, and each time, the organizations that came out ahead were the ones that moved fast to adapt rather than trying to hold the line with existing approaches. 

AI-assisted development is one of those inflection points. The 45% failure rate on security tasks isn’t going to improve on its own through model scaling — the data makes that clear. The security debt crisis isn’t going to resolve itself — it’s getting worse. And the competitive pressure on development teams to adopt AI tooling and move faster is only going to intensify. 

The window for CISOs to get ahead of this is now. Not by slowing down AI-assisted development — but by building the security infrastructure, the tooling, the processes, and the organizational culture that allows your business to move fast and stay secure at the same time. 

Want to go deeper on securing AI-assisted development at your organization? Watch our on-demand webinar, Defending Against AI-Powered Attacks Without Slowing Down Innovation, where I join CyberEdge’s CEO, Steve Piper, for an in-depth conversation on breaches, budgets, and more in the AI era.