When AI writes the code, security must be rethought

AI-generated code is rapidly changing the way software is developed. Not so long ago, software development required deep technical expertise, many hours of work, and lines of manually written code. Today, a simple prompt can do much of the same work in seconds.

What is sometimes called vibe coding, where developers instruct AI models to generate code instead of writing it themselves, is rapidly changing the way software is built. It makes development faster, more accessible, and more efficient. For many organizations, it’s a given: faster launches, higher productivity, and a pace of innovation that was previously difficult to achieve.

But as more and more code creation is handed over to machines, a crucial question also arises: if we no longer write the code ourselves, how do we know it is secure?

Code is never just functionality. It is also a potential vulnerability.

As AI-generated code becomes more common, the risk of vulnerabilities being introduced into organizations' environments also increases. What was previously often a matter of human error can now be created systematically and at scale.

Research from Armis Labs shows how serious the problem really is. In a number of critical development scenarios, all leading generative AI models failed to produce secure code. Even newer and more advanced models, such as Gemini and Claude, generated vulnerable code in more than 30 percent of cases. The weaknesses were in areas such as authentication, file handling and memory management. However, the problem is not only in the code itself, it is also in how quickly we start to trust it.

As AI-generated code, third-party components, and open libraries become an increasingly important part of the development workflow, many organizations rely on code they didn’t write and often can’t fully review, creating a growing gap between perceived and actual security.

Research we commissioned shows that 77 percent of organizations trust the integrity of third-party code used in their most critical applications. An equal number believe that AI-assisted code is properly vetted for serious vulnerabilities. At the same time, many organizations lack full visibility into how the code was created, what components it is built on, and how it has actually been reviewed.

It's a dangerous combination. Code is generated faster than it can be secured and trusted faster than it can be verified.

This also changes the threat landscape. Every new feature, integration or dependency can create a new route for attackers. Vulnerabilities rarely exist in isolation. They connect applications, environments, vendors and systems in ways that are difficult to see and where traditional application security is not enough. Many older ways of working are based on a development model where code is written, reviewed and deployed in clear steps. AI-based development works differently – it is based on continuous generation, rapid iteration and a rapidly growing amount of code.

The result is not only more vulnerabilities, but less clarity. Security teams are presented with more findings to deal with, but often too little context to understand which weaknesses actually matter the most.

This means that organizations need to move from simply looking for flaws to understanding actual exposure. It is not enough to know that a vulnerability exists, you need to understand which systems it affects, how it connects to other weaknesses and what actual business risk it creates, which requires better visibility into the entire software chain. Organizations need to know how applications are built, what external components they use and how these connect to other environments. This applies to AI-generated code, open source code, third-party integrations and the infrastructure that all of this rests on.

So the real challenge is not just the amount of vulnerabilities. It's how they are interconnected.

As AI changes how software is built, security must also change. In an AI-based development environment, risk is no longer created line by line, but through systems, components, and connections that are often invisible until something goes wrong.

The question is therefore not whether we can trust the machines that write the code, but how we manage the risk that comes with that trust. Security can no longer be based on the assumption that the code is secure. It must be based on understanding where the exposure is, how it is connected, and what it can actually affect.

Nadir Israel, CTO and co-founder, Armis