The illusion of secure code is growing

Not long ago, writing software meant lines of code, deep expertise and hours of manual effort. Today, a simple prompt can do the same job in seconds.

 

“Vibe coding” – where developers instruct AI models to generate code rather than writing it themselves – is rapidly reshaping how software is built and has exploded in popularity in recent months. What was once a specialist skill is becoming more accessible and significantly faster, allowing organisations to accelerate development in ways that were previously out of reach.

 

For many, the appeal is undeniable. Faster releases, greater efficiency and the ability to innovate at speed. But as we hand more of that process over to machines, the implications extend far beyond productivity. Because code is not just functionality – it’s a potential vulnerability.

 

But if we’re no longer writing the code ourselves, can we really trust that it’s secure?

 

From code creation to risk generation

As AI-generated code becomes more widespread, so too does the volume of vulnerabilities entering an organisation’s environment. What was once commonly introduced through human error is now being generated systematically and at scale.

 

Recent research from Armis Labs highlights just how significant this issue is. Across a range of critical development scenarios, 100% of leading generative AI models failed to produce secure code. Even the newer, most advanced models, such as Gemini and Claude, generated vulnerable outputs in more than 30% of cases, exposing weaknesses in areas such as authentication, file handling and memory management.

 

But the risk is not just in the code itself. It’s in how that code is trusted. As AI-generated and third-party components become more deeply embedded into development workflows, organisations are relying on outputs they didn’t write and often don’t fully validate. It creates a widening gap between perceived and actual security, where vulnerabilities are introduced at scale and frequently go unchallenged. In fact, 77% of organisations say they trust the integrity of third-party code used in their most critical applications, while the same proportion believe AI-assisted code is thoroughly checked for high-severity vulnerabilities, despite many lacking full visibility into how that code is produced or assessed.

 

This confidence sits uneasily with reality. Concerns remain high around the reliability of models, from hallucinations in large language models to automation errors that are difficult to detect at scale. Even major cloud providers have faced near misses involving coding vulnerabilities that could have triggered widespread supply chain disruption.

 

It results in a dangerous dynamic: code is being generated faster than it can be secured, and trusted faster than it can be verified. At the same time, AI is not just accelerating development; it’s transforming how exposure is created. Every generated function, integration or dependency introduces a potential pathway for exploitation. These vulnerabilities don’t exist in isolation either. They connect across applications, environments and supply chains, creating a vast web of risk that’s increasingly difficult to map and understand.

 

This is where traditional application security approaches fall short. Legacy AppSec models were built for a slower, more predictable development lifecycle, where code was written, reviewed and deployed in controlled stages. In contrast, AI-native development introduces continuous generation, rapid iteration and an ever-expanding volume of code.

 

The result is not just more vulnerabilities, but less clarity. Security teams are faced with a growing volume of findings, but limited context on how those weaknesses connect or where they introduce real risk. Without that understanding, organisations are left reacting to isolated issues – while the broader exposure across their software supply chain continues to expand.

 

Risk in an AI-native development world

This is where a different approach is needed.

 

Rather than focusing on scanning for every possible flaw, organisations need to understand which vulnerabilities actually matter. That means prioritising risk based on real-world impact, identifying which weaknesses are most likely to be exploited, which systems they affect and how they could be used to move across environments. Application security must evolve from “scanner management” to true cyber-exposure management. That means shifting away from simply detecting vulnerabilities to understanding their context and business impact.

 

In practice, this requires greater awareness across the software supply chain. Not only that, but organisations need to understand how applications are built, what external components they rely on and how those components connect into broader environments. This includes not only AI-generated code, but also open-source libraries, third-party integrations and the infrastructure that supports them. Every new piece of code has the potential to introduce new exposure, often in ways that are not immediately visible.

 

This shift is becoming increasingly urgent, too, as the volume and complexity of AI-generated code only continue to grow. Traditional tools struggle to keep pace, so to operate effectively in this environment, organisations must move toward a more contextual AI-powered understanding of their attack surface. One that reflects how software is developed, deployed and connected.

 

Ultimately, the real challenge security teams are up against is not the number of vulnerabilities, but how they connect. Therefore, without understanding how weaknesses relate across applications, components and environments, organisations risk addressing isolated issues while broader exposure will only continue to grow.

 

Rethinking trust in AI-generated code

The way software is built has changed. And so too must the way it’s secured. In an AI-native development model, risk is no longer introduced line by line; it’s created across systems, components and connections that are often invisible until something goes wrong. This is what makes the current moment so critical.

 

Which means the question is no longer whether organisations can trust the machines writing their code, but how they manage the risk that comes with that trust. Because in this environment, security depends on understanding where exposure exists, how it connects and what it impacts — not just assuming the output is secure.

 

---

 

Nadir Izrael is Group Vice President at Armis from ServiceNow

 

Main image courtesy of iStockPhoto.com and Vertigo3d