Everything old is new again. History repeats itself. I keep thinking of these aphorisms while considering the Tea App breach, which involved an unauthenticated, public database of sensitive data. This simple security error has been attributed, although not confirmed, to be a result of vibe coding.
I should note that there is no solid evidence that this breach was rooted in vibe coding; however, while it is the most prominent story, it is also not the only example of vibe-coded apps & services having significant security issues.
Exposing data like this, unauthenticated, has been such a common problem before vibe coding that there is an ecosystem of tools that scan code to find & alert developers on exactly this sort of issue. When I was at Orca, this was a major focus of the AppSec team and there are many excellent products and open-source, free tools (such as KICS and Trivy) that organizations are operationalizing.
I don’t want to discount the value of vibe coding as an approach to democratizing software development – it is an excellent way to prototype ideas and enable those of us who aren’t strong developers. This is, however, a clarion call that the industry must apply the same security rigor to the output that we’re applying more generally in software development.
First, regardless of how an application or service is developed, threat modeling it should be a requirement. Threat modeling is a well-established approach to understanding what must be protected within the application and ensuring that those protections are implemented. Using the Tea App breach as an example, a thread modeling exercise would’ve shown that the sensitive data that was being stored required appropriate controls to ensure it wasn’t publicly accessible.
Beyond that, as I already mentioned, scanning of the source code and deployment artifacts should be standard practice. Organizations should look at vulnerabilities introduced from third-party libraries and ensure that policies are in place to update or mitigate serious vulns. Additionally, this scanning should look for misconfigurations (such as a lack of authentication on sensitive resources) and secrets that are inadvertently embedded. These early checks do a great deal to help catch mistakes and address them.
This should also include a focus on reducing the attack surface and complexity of the app to reduce risk and limit the impact of a compromise. Many modern apps are deployed in containers, an area that I’m very familiar with, and the use of slim or distroless bases are a key tool. Depending on budgets, using free options such as Alpine or paid offerings such as Minimus go a long way to reduce what’s deployed.
Organizations must also invest in monitoring of applications for anomalous or malicious activity once they are deployed. We often describe the modern security landscape as “assume breach” – in other words, no matter how much we invest in preventing breaches, it’s always possible that a threat actor has found a way in that wasn’t anticipated. Identifying and responding to these events early limits the impact.
I hope that the vibe coding platforms will introduce additional features and checks to streamline much of this work but we shouldn’t rely on any single tool to secure our code. The impact of a breach can be severe – to our users and to our reputation – and we must incorporate layers of security into what we deliver.
link