I've noticed a pattern with founders who treat a security review like a certificate you earn once and frame on the wall. Someone checks the code, a few issues get fixed, and from then on the app is considered secure, full stop. That mindset made sense back when a codebase might sit mostly untouched for months between releases. It doesn't hold up now, especially if you're building with an AI coding tool, because the entire appeal of those tools is that your codebase keeps changing. New tables, new routes, new integrations, sometimes several times a week.
A car doesn't get one oil change
Think about a car. Nobody takes it in once, changes the oil, and considers the engine handled for the next 150,000 miles. Oil breaks down. Parts wear. A hot summer, a long highway trip, a winter of short cold starts, all of it changes what the engine needs. The maintenance schedule exists because the car keeps moving and the wear keeps happening. A codebase works the same way. Every feature you ship is another mile on the engine.
What changes under the hood
The gap almost never comes from the code that already got reviewed. It comes from what got added after. A new database table that didn't inherit the access rule the rest of the schema uses. A new API route wired up in a hurry that skips the check every other route has. A secret key pasted into a client-side file because that's where the example snippet put it. None of that shows up in a review of the old code, because it didn't exist yet when that review happened.
The clearest public example of this from 2025 is the row-level security flaw found in Supabase backends generated by Lovable, later cataloged as CVE-2025-48757. A researcher found that a large number of apps built on the platform were missing row-level security on their database tables, the exact kind of gap that lets anyone query data they were never supposed to see. Independent scanning turned up more than 170 affected production apps and over 300 vulnerable endpoints across roughly 1,600 projects checked. That's not a story about one careless build. It's a story about a mistake that's easy to reintroduce every single time a new table gets added, on any project, at any point in its life.
Even the tool vendors stopped pretending one check was enough
Look at what the AI coding platforms themselves did after incidents like that. Lovable folded a security scan into its publish flow instead of leaving it as a one-time audit step. Replit built a scanner into the coding flow itself. Bolt.new eventually shipped an automatic vulnerability check that runs every time you publish, not only the first time. Anthropic added a dedicated security-review command directly into Claude Code. Not one of these was built as a run-it-once-at-launch feature. They're all built around the same assumption: the code that got checked yesterday isn't the code running today.
That kind of jump doesn't happen because old code gets worse while sitting still. It happens because more code gets written, faster, and every new piece is a fresh chance to repeat an old mistake.
What ongoing actually looks like day to day
- Re-check after you add a new table or column, not only after you ship a whole new feature.
- Re-check when you wire up a new API route or webhook, especially if you copied the pattern from a tutorial or template.
- Re-check anytime you touch auth, roles, or permissions, even when the change feels small.
- Treat it as part of shipping, not a separate task you schedule for someday.
A car doesn't get safer because you changed the oil once, back in 2019. It gets safer because the habit is tied to the miles, not the calendar. Do the same with the app you're building. The vulnerability that actually gets you is rarely the one from your first week of building. It's the one you shipped last Tuesday, quietly, while everyone including you assumed that question had already been answered.