By Doug Britton, CSO, RunSafe Security
AI coding tools have become a normal part of software development. In a 2025 RunSafe survey of more than 200 embedded systems professionals, 80.5% said they use AI tools in development, and 83.5% said they have already deployed AI-generated code to production. That code now runs in medical devices, industrial control systems, vehicles, and energy infrastructure.
Most organizations manage the security of that code with the same processes they use for code written by people. That approach misses how AI-generated vulnerabilities differ. They show up at a steady rate that newer models have not reduced, they are harder to track once they ship, and they tend to look trustworthy during review. Each of those differences deserves a closer look.
Better Models Haven't Meant More Secure Code
AI coding assistants do not understand secure coding the way experienced engineers do. They generate code based on probabilities, predicting what is likely to come next from patterns in their training data. That data largely comes from public code repositories, many of which contain security flaws. When a model sees both secure and insecure versions of the same function during training, it learns that both are valid answers. A vulnerability fixed years ago in one project can easily reappear in newly generated code, alongside new flaws of its own, including the kinds of memory-handling errors that led to incidents like Heartbleed.
The important point for GRC leaders is that many of these risks are not entirely unpredictable. The specific vulnerability may be unknown, but the classes of vulnerability associated with a technology stack often are not. Web applications face risks such as cross-site scripting; database-backed applications face SQL injection risks; and native C/C++ code carries persistent memory-safety risks. That creates an opportunity to proactively reduce exposure to entire classes of risk, rather than waiting to identify each individual vulnerability.
The models also work without context. They don't know an application's security requirements, its business logic, or how it fits into a larger system, so they produce code that does what was asked but lacks the controls a developer familiar with the system would add.
Newer models have not solved either problem. A report by Veracode found that AI models produced secure code 56% of the time, compared with 55% a year earlier, even as syntax errors all but disappeared. Larger, coding-focused models did no better on security, and even the top performer produced vulnerable code in roughly one in three tasks.
AI-Generated Flaws Are Harder to Track
Most applications are built from the same open-source libraries and components, so when a researcher finds a flaw in one of them, it receives a CVE identifier, scanners and Software Bills of Materials (SBOMs) match it to every affected product, and organizations know to patch. One discovery protects thousands of users because they all run the same code.
AI-generated code is causing us to lose the commons of vulnerability intelligence. When teams build software using AI prompts, the assistant often writes custom code similar to an open-source component, but not identical. If every team works this way, vulnerabilities become one-offs. A flaw in your product may exist nowhere else, while another organization carries a slightly different version of the same flaw without knowing it. Organizations that stop using the same components lose the ability to share what they learn about them, and respondents in RunSafe's survey rated this loss of shared vulnerability intelligence as a significant concern.
Without shared components, there is no community-driven detection, no coordinated patching, and no visibility into risk exposure across the ecosystem. Each organization ends up on its own island of unknown code.
Even when AI-generated flaws do surface, they are hard to trace back to their source. Researchers at Georgia Tech had confirmed 74 public CVEs linked to AI-generated code through March 2026, and they estimate the real number is several times higher because few organizations record which code came from an AI tool.
As vulnerability intelligence becomes less complete, organizations need controls that do not depend on knowing the identity of every vulnerability in advance.
AI-Generated Code Is Easy to Trust
AI-generated code is usually clean, well-formatted, and documented, and it often compiles on the first attempt. Those qualities make it look like the work of a careful engineer, and reviewers tend to give it the benefit of the doubt.
Research on developer behavior suggests that trust is misplaced. A Stanford study found that developers using an AI assistant wrote less secure code than developers working without one, and were also more likely to believe their code was secure. The assistant raised their confidence without improving the security of their work.
Teams are relying on tools and review processes built for code written by people, at a human pace. Few have tested whether those processes hold up when code changes are measured in thousands of lines per sprint.
What GRC Leaders Can Do Now
AI tools save teams real time, and most security and engineering groups have already fully adopted them. The practical goal is to assume some vulnerable AI-generated code will reach production and layer vulnerability discovery with controls that proactively mitigate the classes of risk most likely to occur in each type of code.
Know where AI-generated code lives. Require teams to record which components were written with AI assistance and how they were reviewed. A risk that can't be located can't be assessed or explained to an auditor.
Ask suppliers about AI. Add questions to third-party risk assessments about which AI coding tools suppliers use and how they check the output. Much of the AI-generated code in your environment will arrive through vendors.
Review AI-assisted code with extra care. Apply additional testing to AI-assisted components, especially for error handling and edge cases, rather than relying on how clean the code looks.
Plan for flaws you won't find. Some vulnerabilities will never receive a CVE, and testing will never identify every flaw before deployment. Pair vulnerability discovery with proactive controls targeted at the dominant risk classes in each technology stack. For web applications, that may mean controls designed to prevent cross-site scripting; for database-backed applications, protections against SQL injection; and for native code, memory-safe languages where practical and runtime protections make memory-safety vulnerabilities harder to exploit in existing software. The objective is to reduce exposure to entire classes of risk, even when the specific vulnerability is unknown.
Track metrics that show resilience. Move beyond counting discovered vulnerabilities. Measure what percentage of deployed software has controls addressing its highest-risk vulnerability classes, how much of the attack surface those controls cover, and how quickly the organization can reduce exposure when new vulnerabilities are discovered. Test whether those controls work as intended. Together, these measures help GRC leaders assess the exposure that remains when detection misses a flaw.
AI-generated code will contain vulnerabilities, and some of them will never be cataloged. GRC programs cannot rely exclusively on finding and fixing individual flaws. Combining discovery with proactive mitigation leads to understanding the classes of risk inherent in each software environment, applying controls that reduce those risks by design, and assessing the remaining exposure. The goal is resilience even when vulnerabilities remain unknown.
Latest News
