Short on time?

Here are our key takeaways from Dr. Paxton-Fear’s presentation, so you can glean the important parts now and catch up with the rest later on.

The largest security challenge in vibe coding is often a lack of visibility rather than a lack of functionality.

Developers and vibe coders approach software from fundamentally different perspectives, leading to distinct security risks.

Modern applications rely on extensive “invisible glue” including APIs, libraries, cloud services, and integrations.

Many vulnerabilities originate from AI-generated implementation decisions rather than deliberate user actions.

Security debt accumulates rapidly as applications become more complex.

Large language models struggle to maintain context across large, evolving projects.

The “set it and forget it” mindset may be one of the most significant risks associated with AI-generated software.

Organisations should prioritise visibility, monitoring, and governance rather than attempting to ban AI-assisted development.

In discussions about AI-generated software, security conversations often begin with the technology itself. Commentators debate whether large language models write secure code, whether AI can replace developers, or whether generative AI introduces entirely new categories of vulnerability. While these questions are important, they can obscure a more fundamental issue.

The greatest security challenge associated with vibe coding is not necessarily the AI. It is the visibility gap between the person building an application and the technology powering it.

During the “Hack Before You Launch” workshop, cybersecurity researcher Dr. Katie Paxton-Fear argued that many of the security problems appearing in AI-generated applications stem from a simple reality: the people creating these applications often view software differently from traditional developers. Their objective is not to engineer maintainable systems or architect resilient infrastructure. Their objective is to solve a problem as quickly as possible.

That distinction may seem subtle, but it has profound implications for security.

Traditional software developers are typically trained to think beyond immediate functionality. They consider how code will be maintained, how systems interact with one another, how future features might affect existing functionality, and how security controls should be incorporated into the design process.

Vibe coders approach software from a different perspective. They begin with a business need, a personal challenge, or an idea they wish to test. AI tools allow them to focus on outcomes rather than implementation. The application becomes a means to an end rather than a product requiring long-term stewardship.

Dr. Paxton-Fear illustrated this distinction by contrasting developers and vibe coders directly: developers are focused on building software, while vibe coders are focused on solving problems; developers think about functions, architecture, and maintainability, while vibe coders think about features and outcomes.

Neither approach is inherently wrong. In fact, the accessibility of AI-assisted development is one of its greatest strengths. The problem emerges when applications created with a problem-solving mindset are deployed into environments that require an engineering mindset. Of course, security is one of those environments.

Modern software is rarely built from scratch. Even relatively simple applications depend on an extensive ecosystem of supporting technologies. Authentication systems validate users. Cloud platforms host services. Third-party APIs provide data and functionality. Open-source libraries accelerate development. Databases store information. Monitoring tools collect operational metrics.

Most users never see these components. Increasingly, many builders do not see them either. This is what Dr. Paxton-Fear described as the “invisible glue” holding modern applications together. While AI tools can assemble these components automatically, they do not necessarily help users understand what has been assembled.

A prompt requesting a customer portal may generate authentication mechanisms, database integrations, user management workflows, session handling logic, and third-party dependencies. The resulting application may appear deceptively simple from the user’s perspective, but the underlying architecture can be remarkably complex.

This complexity creates opportunities for security weaknesses to emerge in places that builders never knew existed. A vulnerability hidden inside a dependency, a misconfigured permission setting, or an exposed API endpoint may have little visible impact on functionality. The application continues to work exactly as intended. The risk only becomes apparent when an attacker begins exploring those unseen components.

One of the more surprising observations from the workshop was that the vibe coder does not directly introduce many common vulnerabilities. Instead, they emerge from decisions made during the AI generation process itself.

Dr. Paxton-Fear grouped common issues into two broad categories. Some vulnerabilities, such as business logic flaws and authorisation issues, are often linked to the requirements provided by users. Others are more likely to be introduced by the AI system, including vulnerable dependencies, exposed secrets, insufficient rate limiting, debugging information leakage, and various injection-related weaknesses.

This distinction matters because it challenges a common assumption about AI-generated software. Many people assume that if they did not explicitly create a vulnerability, the vulnerability does not exist. In reality, software development has always involved inherited risk. Developers regularly introduce third-party code into projects through frameworks, libraries, plugins, and integrations. AI accelerates this process by making those implementation choices automatically.

The result is a form of security debt that can accumulate rapidly. Every new feature potentially introduces additional dependencies, additional interactions, and additional attack surface. As applications grow, understanding those relationships becomes increasingly difficult.

Large language models perform best when they have access to sufficient context. They can reason effectively about a single feature, a specific bug, or a contained workflow. Problems begin to emerge when projects grow beyond the model’s ability to maintain a coherent understanding of the entire application.

This challenge is not unique to AI. Human developers struggle with complexity as well. The difference is that experienced engineers develop mental models that help them understand how systems fit together. They recognise architectural patterns, identify unusual behaviours, and anticipate the consequences of changes.

AI models lack this persistent understanding. Their awareness is constrained by the context available during a given interaction. As Dr. Paxton-Fear noted during the workshop, increasing complexity can cause AI systems to rewrite existing functionality, introduce inconsistencies, or generate excessive documentation in an attempt to compensate for limited context. Security often suffers as a consequence.

The issue is not that AI becomes careless (if, at that, this sentence actually makes any sense at all). The issue is that security requires a comprehensive understanding of relationships across an entire application, and that understanding becomes increasingly difficult as projects evolve.

Perhaps the most important security blind spot discussed during the workshop has little to do with coding at all.

Traditional software development assumes that applications require ongoing maintenance. Dependencies must be updated. Vulnerabilities must be monitored. Security controls must be reviewed. New threats must be assessed as technologies change.

Many vibe coders approach software differently. Once the application solves the original problem, attention moves elsewhere. The software becomes a completed task rather than a living system.

This mindset is understandable. Someone who builds an internal workflow automation tool may never intend to become a software maintainer. Their goal was simply to solve a business challenge. Unfortunately, attackers do not care whether an application was intended to be temporary.

A vulnerable application remains vulnerable whether it was built by a professional engineering team or by an employee experimenting with AI prompts during a lunch break. This creates one of the most significant risks associated with AI-generated software. The danger is not necessarily that applications are deployed insecurely. The danger is that they remain insecure long after deployment because nobody recognises the need for ongoing maintenance.

The solution proposed throughout the workshop was not to discourage vibe coding. Dr. Paxton-Fear repeatedly argued that banning AI-assisted development is unlikely to succeed. The benefits are too significant, and adoption is already too widespread.

Instead, organisations should focus on improving visibility. Users need better insight into the components that make up their applications. They need tools that expose dependencies, integrations, permissions, and data flows. They need security information presented in a format that non-specialists can understand.

Most importantly, they need systems that make security concerns visible before vulnerabilities become incidents. The future of secure vibe coding may depend less on teaching every user to become a software engineer and more on creating tools that expose the hidden complexity beneath modern applications.

The security risks associated with vibe coding are often described as technical problems. In reality, many of them are visibility problems. AI has dramatically expanded the number of people capable of building software. What it has not done is eliminate the complexity of the systems being built. Modern applications still rely on countless interconnected components, each carrying its own risks and dependencies.

As applications grow, those dependencies become increasingly difficult to understand. Security weaknesses emerge not because builders are careless, but because the systems beneath the surface become harder to see.

The challenge facing organisations is therefore not simply to secure AI-generated code. It is to make the invisible visible. Without that visibility, vulnerabilities remain hidden until attackers find them first.

OWASP Top 10 Web Application Security Risks

OWASP Top 10 for LLM Applications 2025

OWASP GenAI Security Project

OpenSSF Secure Supply Chain Resources

NIST Secure Software Development Framework (SSDF)

UK National Cyber Security Centre Secure Development Guidance

Copyright (C) 2025 Packt Publishing. All rights reserved. 

Our mailing address is: 

Packt Publishing, Grosvenor House, 

11 St Paul's Square, Birmingham, 

West Midlands, B3 1RB, United Kingdom 

Want to change how you receive these emails? 

You can update your preferences or unsubscribe.