Vibe Coding Easy Path

Recently in a security governance meeting I was leading, I learned of a new vibe-coded app created to simplify database monitoring and other simple tasks.  What really stood out to me from a risk perspective was the included authentication service.  It was not connected to the enterprise identity system, so some additional risk was being incurred from creating and managing separate identities.  This was not the pieces that brought the request to the governance committee for review though, it was to open some of the network rules to make the app more easily available to the workforce.  

I have received some calls from concerned customers around a perceived need to create a new pipeline to secure vibe coded apps.  For a moment, I too felt a visceral “oh no, we have a huge gap here,” but then I remembered security should not try to govern every spark of creativity.  It should build obvious paths for work that incurs enough risk to cross a threshold.  As vibe coding opens the door for professionals with a non-technical background to make valuable, and risky applications, it’s not additional technical pipelines that we need, its connections for a new audience to the pipelines we already have in place.  

While “no” can be necessary for security to say from time to time, it tends to cost a lot of cultural capital.  If our security strategy depends too much on telling people what not to do, smart, motivated people eventually find a way around security strategy.  I typically don’t see this as malicious. They are trying to serve customers, meet deadlines, and reduce friction in their own work. When the approved path feels disconnected from reality, people build side paths, and the culture we want is stymied.  Vibe coding can quickly make the approved path feel disconnected, but again its less the path had a problem, more it was built for a particular audience and now that needs to be expanded.

The reality is that people are going to use AI-assisted coding and lightweight tools whether security blesses it or not.  The question for security, then is not, “How do we stop side paths?”  The better question is, “Where do side paths become risky enough for the organization to care?”  This can be different for every organization.  Some ideas to define when the organization needs to care are the application

• Processes, gathers or stores sensitive data such as customer PII or aggregate financial information
• Is accessible to the public or on the public internet
• Has admin capabilities 
• Integrates with other systems or has production dependencies (or is a production dependency)
• Needs an identity system

Thinking of systems in this way can help separate the fear that comes with a changing world and focus on real risk reduction.  As the barrier to entry in creating advanced software applications shrinks, security needs to be that much more precise about what matters

What is exciting with this is once a threshold where experimentation becomes engineering is defined, there is no need for a new pipeline to develop software in a new way, all that is needed is to be sure the pipeline is accessible enough to be valuable in the new paradigm and ensure it generates enough assurance to keep risk where it needs to be.

The best security programs are not the ones with the most rules. They are the ones where the safest, clearest, fastest path, and the path people can follow.  That is the kind of security I want to keep building.