Your App Builder Has SOC 2. The App You Built With It Does Not.

In early May 2026 the Israeli security firm RedAccess published the results of a scan across roughly 380,000 applications built on vibe coding platforms including Lovable, Base44, Replit and Netlify. Of those, researchers identified about 5,000 that had been built for corporate purposes, and roughly 40 percent of that corporate subset contained sensitive data deployed without basic security controls. A separate scan by Escape.tech covered 5,600 publicly reachable vibe coded applications and reported more than 2,000 high impact vulnerabilities, more than 400 exposed secrets including API keys and access tokens, and 175 distinct instances of personal data exposure. The figure worth sitting with is not the vulnerability count. It is the 5,000, because that is a count of applications doing company work that almost certainly do not appear on any asset register.

The compliance consequence is simpler than the security discussion and it gets missed constantly. An auditor does not ask how a piece of software was produced. If an application processes data covered by the trust services criteria, it is in scope for a SOC 2 examination whether a senior engineer wrote it over six weeks or an operations manager described it to a chat box on a Tuesday afternoon. The same logic applies to the ISO 27001 statement of applicability, to ISO 42001 where the application embeds a model, and to PCI DSS the moment anything resembling a payment page is involved. Building an application on Lovable or Bolt or v0 does not reduce the control obligation attached to it. In practice it increases the evidence burden, because the change management artefacts that an assessor expects to see, the ticket, the review, the approval, the test record, were never generated in the first place.

There is a specific confusion that platform marketing does nothing to clear up. As of mid 2026, v0 holds SOC 2 Type 2. Lovable sells single sign on and role based access on business plans. Bolt puts single sign on and advanced governance behind an enterprise tier. Every one of those statements is true, and not one of them tells you anything about the application your team shipped. A platform attestation covers how the vendor operates the service, how the vendor manages access to its own infrastructure, and how the vendor handles its own change control. It is a statement about the factory, not the product. The database your marketing lead connected last month sits outside that boundary entirely, and the assessor looking at your environment will treat it as your system, because it is.

The mechanism by which these applications leak is well documented and worth understanding precisely, because it explains why the problem is systemic rather than a matter of careless individuals. CVE-2025-48757 was reported to Lovable on 21 March 2025 by the researcher Matt Palmer, and published publicly on 29 May 2025. The root cause was missing or insufficient Row Level Security policies in generated projects. The public key needed for the browser to talk to the database was embedded in the client, as it is designed to be, which meant that anyone who opened developer tools could query tables directly without authenticating. Across more than 170 affected applications and 303 vulnerable endpoints, the exposed material included email addresses, phone numbers, payment and subscription status, third party API keys for services such as Gemini and Google Maps, developer credentials, home addresses, and in some cases individual debt amounts.

Lovable responded on 24 April 2025 by shipping a security scanner that runs before publish, and that response is genuinely better than what the alternatives offer. Bolt makes security audits available on demand and only on paid plans. According to platform documentation, v0 provides no built in vulnerability scanning at all. But the limitation of even the best option in that set is the part teams need to hear, because it determines how much assurance the feature actually buys. The scan checks whether an access policy is present. It does not check whether the policy blocks an unauthorised read. Those are different questions, and the gap between them is exactly where CVE-2025-48757 lived. A green tick that means a policy exists, presented to a non engineer who reasonably reads it as a statement that the application is secure, is worse than no tick at all.

What makes this materially harder than the shadow IT problems most organisations have already learned to manage is that these applications leave almost no trace in the places you normally look. They are not in the corporate cloud account. They are not behind the identity provider. They are published on a vendor subdomain, paid for on a personal card or a small departmental subscription, and connected to a database provisioned in ninety seconds by someone with no reason to think a database needs governing. Reported figures on shadow AI incidents put the average cost meaningfully above the baseline breach, in the region of 670,000 dollars higher, and show customer personal information exposed in around 65 percent of cases against 53 percent for breaches generally. That skew is not a coincidence. Applications built quickly by people close to the customer tend to be the ones holding customer data.

It is worth being clear about what your compliance automation can and cannot see here, because this is a common and expensive assumption. Vanta, Drata, Secureframe and Sprinto continuously monitor the accounts and repositories you have connected to them. That monitoring is genuinely valuable and it is also strictly bounded. An application running on a builder subdomain, backed by its own database project, created outside the connected estate, is invisible to every one of those platforms. The dashboard will show a healthy control posture, and the dashboard will be accurate about the environment it was told to watch. Continuous compliance is continuous over your declared scope, and the failure mode of the last two years has been scope drifting faster than anyone updated the declaration.

The obvious objection is that the answer to all of this is to block the tools, and that objection deserves a direct response, which is that blocking them is both futile and wrong. The productivity is real. An operations lead who builds a working internal dashboard in an afternoon has created value that would have waited three months in a delivery queue, and organisations that respond by banning the category simply push the activity onto personal accounts where they lose even the expense record. The workable answer is a publishing path rather than a prohibition. Decide which data classes may touch a builder application at all, provide a sanctioned account so the spend and the artefacts are visible, require a real access control review before anything holding personal or financial data becomes publicly reachable, and name an owner. That is four decisions, and none of them require slowing anybody down.

Our recommendation this month is an inventory exercise that takes most teams a single afternoon. Search your egress logs, your expense records and your single sign on directory for the major builder domains, and list every application you find. For each one, answer four questions in writing. What data does it hold, and does any of it belong to a customer. What can an unauthenticated visitor read if they open developer tools and query the backend directly. Where do the API keys live, and are any of them production keys for a paid service. Who owns it, by name, and what happens when that person changes role. Then make a decision on each application: bring it into scope with the controls that implies, rebuild it properly, or turn it off. Every one of those conversations is cheaper to have in August than during a SOC 2 examination, a PCI DSS assessment, or the notification call that follows someone else discovering the answer to question two.