Secure Vibes Only?
How Security Teams Can Adapt to a World Where Everyone Builds Software
Short on time? Here are the big ideas, so you won’t miss out and can still come back later on to get the details.
Key takeaways
Banning AI-assisted development is unlikely to eliminate its use within organisations.
Security controls should be integrated directly into development platforms and workflows.
Visibility into dependencies, integrations, and application architecture is essential for governance.
AI systems require security context from existing security tools in order to make better decisions.
Agentic security workflows may allow security testing to occur continuously during development.
Organisations need formal processes for adopting AI-generated applications that become business critical.
Security must be treated as a lifecycle rather than a one-time activity performed before deployment.
The future of application security will increasingly focus on enabling secure software creation by non-specialists.
For much of the past three decades, software development has operated behind a relatively high barrier to entry. Building applications required specialist knowledge, technical training, and access to development resources that were often concentrated within dedicated engineering teams. While organisations frequently struggled to manage the security risks associated with software development, they at least had a clear understanding of who was building applications and where those applications originated.
Artificial intelligence is changing that assumption.
Make sure to check out the rest of our analysis here
Today, a marketing manager can build an internal dashboard. A project manager can create a workflow automation tool. A researcher can develop a data collection application. In many cases, none of these individuals needs to understand programming languages, cloud infrastructure, or software architecture to achieve their objectives. AI development tools have dramatically expanded the number of people capable of creating software.
For security teams, this presents an uncomfortable reality. The challenge is no longer limited to securing applications built by professional developers. Increasingly, organisations must secure applications built by everyone else.
During the “Hack Before You Launch” workshop, cybersecurity researcher Dr. Katie Paxton-Fear argued that this shift requires a fundamental change in how organisations think about software governance. The instinctive response may be to prohibit AI-assisted development entirely. However, as the workshop repeatedly emphasised, banning vibe coding is unlikely to solve the problem. The technology is already too accessible, too useful, and too widely adopted. The question is no longer whether organisations will encounter AI-generated software. The question is how they intend to secure it.
The Temptation to Ban AI Development
Whenever a disruptive technology emerges, organisations often respond by attempting to control adoption through policy. The same pattern has appeared repeatedly with cloud services, personal devices, file-sharing platforms, and generative AI.
The reasoning is understandable. AI-generated software introduces uncertainty. Security teams may not know how applications were built, which technologies they depend upon, or what vulnerabilities they contain. Preventing their use appears, at least initially, to be the safest option. The problem is that bans rarely eliminate demand.
Employees adopt technologies because they provide value. AI-assisted development significantly reduces the time required to solve business problems. When users can create working applications in hours rather than weeks, the incentive to use these tools becomes difficult to ignore. This creates a familiar challenge. If official channels prohibit AI-assisted development, users may simply move those activities outside approved environments. Applications become harder to discover, harder to govern, and ultimately harder to secure.
Dr. Paxton-Fear’s argument was therefore pragmatic rather than ideological. Organisations should not focus exclusively on preventing AI-generated software. Instead, they should focus on creating conditions in which AI-generated software can be developed more safely.
Security Must Move Closer to the Builder
Traditional application security programmes often assume the presence of professional developers. Security reviews, code analysis tools, architectural assessments, and secure development training are typically designed for technical audiences.
Vibe coders present a different challenge. Many will never read secure coding guidance (such as this helpful little piece…). Many have little interest in software engineering as a discipline. Their objective is not to become developers but to solve specific problems. If organisations want these users to produce more secure applications, security controls must become easier to access and easier to understand.
This means moving security closer to the point of creation. Rather than expecting users to discover security requirements independently, development environments should provide security controls by default. Secrets management, dependency scanning, vulnerability detection, and deployment safeguards should be integrated into the platforms used to create applications.
The workshop highlighted an important distinction between AI-enabled development platforms and standalone coding tools. Platforms designed for non-technical users increasingly include features such as secrets management and built-in deployment controls. While these capabilities do not eliminate risk, they reduce the likelihood of certain categories of vulnerability appearing in production environments. The principle is straightforward: secure behaviour should be easier than insecure behaviour.
Visibility Is the Foundation of Governance
One of the recurring themes throughout the workshop was visibility. As discussed in the previous article in this series, many vibe coders cannot easily conceptualise the underlying architecture of their applications. APIs, dependencies, authentication services, integrations, and cloud resources remain largely invisible.
This creates a governance challenge as well as a security challenge. Security teams cannot manage what they cannot see.
If organisations expect AI-generated software to become commonplace, they must develop mechanisms that expose the hidden components of these applications. Dashboards, dependency inventories, architecture visualisations, and automated asset discovery tools all become increasingly important. Visibility enables risk assessment. Risk assessment enables governance. Without visibility, neither is possible.
This is why the workshop emphasised the importance of making application “glue” visible. Understanding how components interact is often more valuable than understanding the individual components themselves.
Why AI Needs Security Context
A common misconception surrounding AI-assisted development is that better models will automatically produce secure applications. The reality is more nuanced.
Modern language models can already assist with vulnerability remediation, code review, and security testing. However, their effectiveness depends heavily upon the information available to them. Throughout the workshop, Dr. Paxton-Fear repeatedly stressed the importance of context. AI systems perform significantly better when they have access to outputs from vulnerability scanners, security testing tools, architecture information, and threat intelligence sources. Without that context, they are often forced to make assumptions.
This observation has important implications for organisations investing in AI development workflows. Rather than treating AI as a replacement for security tooling, organisations should view it as a consumer of security information. Vulnerability scanners, software composition analysis tools, static analysis platforms, and infrastructure security tools remain valuable because they provide the context AI systems require to make informed decisions. The future of secure AI development is unlikely to involve fewer security tools. It may require more.
The Rise of Security Agents
Perhaps the most forward-looking part of the workshop focused on the emergence of agentic security workflows. Most AI-assisted development today relies on a single agent responsible for generating code. Security testing, if it occurs at all, typically happens after development is complete. This mirrors many traditional software development processes and carries many of the same limitations.
Emerging agentic models suggest a different approach. Instead of a single coding agent, organisations may deploy multiple specialised agents operating simultaneously. A development agent could create features while a security agent performs continuous testing and a separate agent could review the exposure. Another might conduct threat modelling or dependency analysis. The possibilities go on and on.
Rather than reporting every issue directly to a user, security agents could provide feedback to development agents, creating a continuous cycle of remediation and validation. This concept remains immature, but it addresses one of the most significant weaknesses in current vibe coding workflows. Security becomes an active participant in development rather than an afterthought.
The goal is not to teach every user how to perform penetration testing. The goal is to ensure that security expertise is present throughout the development process, even when no security expert is involved directly.
Adopting Critical Applications
Not every AI-generated application will remain a temporary experiment. Some will become essential business systems.
This creates another challenge highlighted during the workshop. Applications originally developed by non-specialists may eventually support critical workflows, sensitive data, or customer-facing services. When this happens, organisations must have a process for formal adoption.
The software should no longer be treated as a personal productivity tool. It should become part of the organisation’s managed technology estate. This transition requires governance. Ownership must be established. Security responsibilities must be assigned. Maintenance processes must be defined. Monitoring must be implemented.
Perhaps most importantly, organisations must recognise when an experimental application has become business critical. Many security incidents occur because software outgrows the assumptions made during its creation.
Security Is a Lifecycle, Not a Feature
One of the strongest themes running through the workshop was the danger of treating software as a finished product. Vibe coders often build applications to solve immediate problems. Once those problems are solved, attention shifts elsewhere. The software remains operational, but maintenance effectively stops.
Security does not work that way. New vulnerabilities emerge continuously. Dependencies become outdated. Attack techniques evolve. Business requirements change. What was considered secure six months ago may no longer be secure today.
For organisations embracing AI-assisted development, this reality may be the most important lesson of all. Security cannot be delivered at launch and forgotten thereafter. It must be maintained throughout the life of the application.
The future of secure vibe coding therefore depends not only on better AI models or more sophisticated security tools, but on establishing processes that recognise software as an ongoing responsibility.
Lifestyling, AI, and You
The future of software development is unlikely to resemble its past. AI is expanding access to software creation at a pace few organisations anticipated. As a result, security teams face a choice. They can attempt to resist this transformation, or they can adapt their practices to accommodate it.
The message from Hack Before You Launch was clear. AI-generated software is not going away. The organisations that succeed will not be those that prohibit experimentation, but those that create secure pathways for experimentation to occur.
Security must become more visible, more automated, and more deeply integrated into the development process. Governance must evolve beyond traditional assumptions about who builds software and how software enters an organisation. Most importantly, security teams must recognise that the future of application security is no longer about protecting developers alone. It is about protecting everyone who can now build software.
"Security controls should be integrated directly into development platforms and workflows."
Which is a step in the right direction.
But as I've been saying for twenty years or more, the software development process ITSELF must be made more rigorous. How is that not obvious at this point?
We have a civilization based on sand right now. Sooner or later this will cost us - and AI-generated code is making it worse.