Here's a number every founder shipping AI-assisted code should have taped to their monitor: 44%. That's how often AI-generated code contains a real, exploitable security vulnerability, according to Veracode's 2026 report testing over 100 models. The same code compiles almost 100% of the time. So the AI writing half your product is excellent at producing code that runs and no better than a coin-flip at producing code that's safe — and a full year of model progress moved that safety number exactly one point, from 55% to 56%.
If you're building a SaaS in 2026, this isn't a curiosity. It's a direct threat to your business, because in SaaS a security hole isn't a bug — it's a breach, a disclosure obligation, and often the end. Here's what the finding actually means for you, and the one architectural decision that turns it from an existential risk into a manageable one.
The trap is specific and worth understanding. Developers trust code that compiles, runs, and passes its tests. That's the signal we've always used. And it's exactly the signal AI has learned to produce flawlessly — while the security flaw sits invisibly underneath, because the surface behaviour never reveals it.
AI got dramatically better at the part humans check and no better at the part humans usually don't. Your test suite confirms the feature works; it says nothing about whether that feature lets an attacker read another tenant's data. The green checkmark is now actively misleading, because it certifies the one property AI reliably delivers and stays silent on the one it doesn't.
The Veracode breakdown is genuinely useful because it tells you where to look. Models are good at the famous vulnerabilities — SQL injection passed 83% of the time, weak cryptography 87% — because those are heavily documented in training data. They're catastrophic where security depends on understanding a specific application's data flow: cross-site scripting passed just 15%, log injection 12%. Java-generated code passed only 30% against Python's 63%.
The pattern: AI handles security when it's a recognisable textbook pattern, and fails when it requires reasoning about how your data moves through your system. Injection flaws are about untrusted data crossing a boundary somewhere else in the app — context the model generating one function simply doesn't have. Which means the vulnerabilities AI introduces are disproportionately the subtle, application-specific ones that are hardest to catch in review and most dangerous in a multi-tenant SaaS.
The wrong response is "stop using AI to write code." The productivity is real, the trend is irreversible, and you'd be handing competitors an advantage. The right response is the oldest principle in security, applied deliberately: assume the code is wrong, and build so that wrong code can't reach far.
If nearly half your generated code has a flaw, the objective isn't to catch every flaw — you won't — it's to make each flaw survivable by shrinking its blast radius. A vulnerability in a feature that can only touch its own small surface is a bug. The same vulnerability in a feature that runs with broad database access is a company-ending breach. Same flaw, wildly different outcome, and the difference is entirely architecture you decide before the AI writes anything.
Concretely, containment means: authentication and access control a vulnerable feature can't bypass; permissions scoped tightly enough that an exploited endpoint can't read everything; a hard data boundary that refuses to expose sensitive records no matter what the calling code asks for; and components isolated so a hole in one can't compromise the whole. This is defence in depth — always good practice, now the difference between an incident and a catastrophe.
Here's the strategic implication for how you build. The most security-critical code in any SaaS — authentication, session handling, access control, the tenant data boundary, payment handling — is exactly the code you least want written fresh by an AI that's insecure 44% of the time. It's also the most undifferentiated code you'll write, identical in shape to every other SaaS.
So the move is to get that layer from a foundation that's already been reviewed and hardened, and let your AI-assisted work happen inside its guardrails rather than reimplementing them. When your auth, RBAC, entitlement and data boundaries are battle-tested platform code, the fast-moving feature code you generate sits contained within them. The AI writes the thing that might be wrong; the platform ensures the thing that's wrong can't reach the crown jewels.
This is a real part of the case for self-hosted, source-available platforms. VBWD is built exactly this way: a plugin architecture over an agnostic core, so the feature you or your AI writes lives in a contained plugin that extends the platform through defined seams rather than touching the security-critical core. Its authentication, role-based access control and access-level system are shared, reviewed infrastructure rather than something regenerated per project. And its search seam refuses, at the architecture level, to expose user records and invoices — so a careless or AI-generated query in a plugin cannot leak what the platform itself won't surface. You still review your code; but a mistake in a plugin is contained by design instead of sitting one bug away from your whole database. Because it's source-available, you can also read and audit the security-critical layer rather than trusting a black box — which matters more, not less, in an age of generated code.
AI writing half your code while shipping a vulnerability 44% of the time is the defining security reality of building software right now, and the numbers say it's structural, not temporary — a year of progress moved the needle one point, and the flaws cluster precisely in the application-specific logic hardest to catch. The volume of generated code is exploding and human review is thinning. The risk is compounding quietly.
You don't manage that by writing less AI code. You manage it by assuming generated code is insecure by default and architecting so a flaw stays contained — hardened auth you didn't reinvent, permissions scoped tight, a data boundary that can't be talked out of its job, components that fail alone. Build your differentiator with AI, at full speed. Just make sure it's standing inside a foundation that was built to assume it might be wrong. Because 44% of the time, it is.
VBWD is a self-hosted, source-available platform for building subscription products, marketplaces, and AI-powered apps. Explore it further: