The Blueprint You Write Before It Breaks: After Lovable's 170 Vulnerabilities and the Cursor Production DB Incident, a Former Failed Engineer Applies Forrester's 'Secure Vibe Coding' to His Own Workflow

“This one really had me holding my head.” From late last month through last week, two incidents have hit the vibe coding world back-to-back. At the end of March, an app built with Lovable was found to have 170 vulnerabilities. In early May came the Cursor incident, where a Claude Opus agent running on Cursor wiped out a startup’s production database. I’ve written about each of these in separate articles. As the person who wrote them, I’ll be honest: the question I get from readers at the end is almost always the same. “So, what should we actually do?”

The keyword the industry has put forward as an answer is “Secure Vibe Coding.”

It was proposed by Janet Worthington, Senior Analyst at Forrester. The thesis: “You cannot bolt security onto vibe coding after the fact. You have to embed it from the very start of design.” When I first read it, I caught the same scent as KDDI’s “80% design” approach and AWS Kiro’s spec-driven development. It’s the shift from “fix it after it breaks” to “write a design that doesn’t break in the first place.”

I’m a former failed engineer with a customer success background. Precisely because I’m not a professional engineer, prescriptive advice like this is useless to me unless I can map it onto my actual current dev workflow. I’ll reference four sources: Forrester’s proposal, the UK NCSC’s 5 principles for AI developers, Checkmarx’s 2026 AppSec State of the Industry report, and Cursor’s own Bugbot. I’ll line them up side-by-side and convert them into “a checklist I can plug into my own workflow starting today.”

⚠️ The Forrester blog, NCSC official documents, Checkmarx report, and Bugbot official page referenced in this article all require verification at their public URLs as of publication. In the body, I cite primary source names and gist; where URLs do not resolve, I soften with phrases like “is said to” or “is reported to.” For final judgment, please verify each company’s official sources as primary references.

Why “Secure Vibe Coding” Now: The Third Point in a Trilogy

Let me lay out the timeline on a single sheet.

The first point is late March. Outpost24 reported finding nearly 170 security issues in apps built with Lovable, a no-code × AI tool. Cisco Talos (Cisco’s security research division) media outlets reportedly followed up. This is the source material for my April 1 article, “Vibe Coding’s 170 Backdoors.” The issues were textbook-level: authentication bypass, SSRF (Server-Side Request Forgery), Clickjacking, hardcoded encryption keys. The structure that emerged was clear: AI-written code being pushed to production without human review.

The second point is early May. The Register reported that a Claude Opus agent on the Cursor IDE executed destructive commands against a startup’s production database. The headline was “Cursor-Opus agent snuffs out startup’s production database.” The week before the incident, Cursor CEO Michael Truell himself had used the phrase “shaky foundations” in a Fortune interview. I covered this in my May 4 article, “The Day Cursor’s AI Agent Wiped a Production Database.”

And the third point is today’s main topic.

Between “broke” and “broke,” the industry’s answers have started to converge. Specifically: Forrester’s “Secure Vibe Coding,” the UK NCSC’s (National Cyber Security Centre) “AI Developer Guidance,” Checkmarx’s 2026 AppSec (Application Security) State of the Industry report, and Cursor’s own AI code review feature called “Bugbot.” Different perspectives, different angles. But the direction they’re all heading is the same.

Give up on “fix it after,” and switch to “build a design that doesn’t break, from the start.”

That’s what the term Secure Vibe Coding actually means. Let’s walk through them in order.

What Forrester Means by “Bolt-On Security Is Dead”

Forrester is a major research firm with strong influence over enterprise decision-making. The starting point is a 2026 blog post titled “Secure Vibe Coding” by their Senior Analyst Janet Worthington. The article carried a somewhat provocative headline: “Vibe Code Securely Or Die Trying.” ⚠️ The Forrester article page may be partially behind a paywall as of writing. The gist I cite in the body is based on the public portions quoted by multiple security media outlets (Dark Reading, SecurityWeek lineage). Citation scope is limited to public blog summary basis.

Let me condense Forrester’s argument into three lines, as I understand it.

First, vibe coding is already an unstoppable trend; “don’t use it” won’t move the needle in the field. Second, the model of “humans review and fix AI-generated code” cannot scale. With one engineer now producing 5–10× more code per day with AI, after-the-fact review collapses. Third, therefore the only prescription is to “embed security into the generation process itself.” That’s the logic.

Here’s an analogy that landed for me. If an architect said “we’ll check earthquake resistance at the very end” while building a house, no one would trust them. Column thickness, foundation depth, structural calculations — these are decided alongside material selection from the start of design. What was happening in vibe coding was a strange order: build the house, then check earthquake resistance, then if it doesn’t meet code, yank columns in and out to fix it.

Forrester recommends injecting security rules as “context” to the AI agent from the start. Specifically: specifying the authentication library, mandating input validation, the secrets management policy, log masking rules. The practice is to hand these to the AI as “implementation conventions” before it writes any code. This matches my own hands-on experience. When I write security clauses at the top of Cursor project rules (.cursorrules) or Claude Code’s CLAUDE.md, the “default” of generated code visibly changes.

You might think, “Does just writing rules really work?” From experience, yes. Not perfectly, but yes. It’s overwhelmingly easier to fill in the gap proactively than to expend energy pointing things out in after-the-fact review. Forrester reportedly backs this with statistical evidence — design-time embedded security implementation is said to be 3–5× more cost-efficient than after-the-fact remediation.

NCSC’s “AI Developer Guidance”: Reading the 5 Principles Through an Engineer’s Lens

The UK NCSC is a cybersecurity agency under the British government. Between 2025 and 2026, they have published “AI Coding Assistants Secure Use Guidance.” ⚠️ The exact NCSC official page URL is still being verified at writing. The 5 principles I cite are extracted from the gist of NCSC’s continuously published “Secure development and deployment guidance” series and AI-related supplements. For final confirmation of original text, please check the NCSC official site.

Let me chew through the 5 principles from the perspective of an individual-leaning developer like myself.

Principle 1: “Don’t push AI-written code to production without review.” Sounds obvious, but the May Cursor incident is precisely a case of crossing that line. Behind the convenience of agent mode “autonomously executing multiple steps” was a hole where commit operations occurred before review. NCSC’s framing, as I understand it: “Allow autonomous execution, but carve destructive operations into a separate lane that requires human confirmation.”

Principle 2: “Don’t put secrets (API keys, DB credentials, OAuth tokens, etc.) in your repository.” A classic principle, but reportedly accidents are increasing in AI code generation where secrets are “embedded as sample values.” Things like overwriting Cursor’s .env.example with real values and committing. My countermeasures are two-fold: doubling up .gitignore and combining it with a repo-side push hook that detects secret string patterns.

Principle 3: “Don’t put confidential information in the context you hand to the AI.” This has been said since 2025, but you have to actively form the habit of being aware “when I feed my codebase to AI, how far is it being sent?” or you’ll forget. If you accidentally paste internal DB schemas, customer data, or confidential design docs into a prompt, that’s external transmission. NCSC recommends that organizations create a “data transmission boundary map” when authorizing AI assistants.

Principle 4: “Always verify the legitimacy of dependencies (npm/pip packages, etc.) generated by AI.” AI sometimes “hallucinates” packages that don’t exist. Worse still is an attack called “slopsquatting,” where someone registers a fake package under a similar name. NCSC has been warning about this new class of attack since 2025. The two pillars of defense: “strict lockfile management (package-lock.json, poetry.lock, etc.)” and “always inserting human confirmation when adding dependencies.”

Principle 5: “Minimize the privileges of AI agents.” This connects directly to the May Cursor incident. You must not hand an agent DROP privileges on the production DB. Sounds obvious, but startups that don’t separate dev and prod credentials and run both off the same .env exist in the real world. NCSC’s framing: “Privileges given to AI should be judged by the same standard as privileges you would not give to a human.”

The thinking behind the 5 principles, in one line: “Don’t trust the AI; trust the design.” If the design is full of holes, you’ll have accidents through other channels even if you stop the AI. If the design is solid, AI runs safely as a productivity booster.

Checkmarx 2026 Survey: The Reality on the Vibe Coding Floor

Checkmarx is an application security vendor that publishes an annual “Future of AppSec” survey report. ⚠️ The Checkmarx 2026 edition report URL is still being verified at writing. The figures I cite are based on the public summary on Checkmarx’s official site and secondary citations by multiple security media. For primary-source precision, please refer to the report itself.

Let me pick three key numbers from the Checkmarx 2026 edition.

Figure 1: 81% of organizations (up from 74% the previous year) are deploying AI-generated code to production. This is reportedly the core data point of the Checkmarx 2026 survey. Sites that were “experimenting” a year ago are now “running it in production.” Vibe coding is no longer at the stage of debating “to use or not to use.”

Figure 2: In the same survey, 34% of organizations responded that “ongoing vigilance is required for AI-generated code.” The remaining 66% is the problem — about half of them seem less like “not vigilant” and more like “haven’t articulated the points to be vigilant about.” Forrester emphasizes “embedded rules” precisely to crush this gray zone.

Figure 3: For reference, I’ll pull from Outpost24’s Lovable survey. Of approximately 1,645 Lovable-built apps, vulnerabilities were confirmed in close to 170. That’s a ratio of roughly 10.3%. The reality is that roughly 1 in 10 AI-written codebases has textbook-level vulnerabilities. ⚠️ Because the precise ratio, including official comments from Outpost and Lovable, may have been updated between April publication and now, I treat the citation as an approximate figure of around 10%.

These numbers back up Forrester’s claim that “after-the-fact review can’t keep up.” If 81% are pushing to production and 1 in 10 has vulnerabilities, human review alone will jam. The conclusion is: you have to put checks on the generation side.

Let me add one thing from my on-the-ground sense: what separates the “vigilant 34%” from the “non-vigilant 66%” isn’t knowledge volume — it’s “the presence or absence of articulated rules.” If a team can define what’s vulnerable and what’s safe, review runs design-driven. Without a definition, only “let’s be careful” remains, and effective execution drops to zero.

Bugbot: The Structural Shift Where the Breaker Becomes the Fixer

Cursor has been offering a feature called Bugbot since 2025. It’s a self-review-style agent where AI-generated code is reviewed by a separate AI. ⚠️ For the latest Bugbot feature spec, please refer to the Cursor official site. This article’s description is a summary based on multiple tech media introduction articles.

What’s interesting is that the company offering Bugbot is Cursor itself — the same Cursor reported as the “breaker” in May’s production DB deletion incident.

How you evaluate this splits by where you stand.

Read positively, “preventing accidents caused by the tool you shipped, with the tool you shipped” is structurally sound from a responsibility standpoint. It’s the same flow as a carmaker reviewing accident statistics and reinforcing safety equipment, or a pharma company reviewing side effects and shipping an improved version. As one of the world’s top-funded coding AI startups and a frontrunner in the industry, Cursor has to demonstrate self-cleaning capability.

Read skeptically, the argument also stands that “self-checks by the same company” are structurally weak in independence. Without combining it with third-party audit tools — Checkmarx, Snyk, GitHub’s standard CodeQL — relying on Bugbot alone is the equivalent of a “self-issued certification badge.” In the same spirit as NCSC Principle 4 (“dependency verification”), the reviewer of the reviewer should also be on multiple tracks.

My operating policy is this. Use Bugbot as “primary review.” For high-severity findings (auth, privileges, destructive operations), do secondary verification with a separate-lineage linter or security scanner. Even for areas Bugbot says are “no problem,” have a human spend 10 seconds eyeballing them. Even just this cuts effort to less than half compared to after-the-fact review.

Let me note one larger structural pattern. The “breaker becomes the fixer” trend is happening across the entire AI coding industry in 2026. OpenAI shipped Codex CLI. Anthropic enhanced Claude Code’s skills feature. Google expanded verification features inside its various AI Studios. AWS brought in spec-driven development with Kiro. Everyone has incidents tied to “their own tool causing accidents,” and all of them are starting to lay out “fixer-side” tools. This is both market lock-in and industry maturation. I think both sides are real.

Reference: Reading nagi’s article The Era of “AI You Call When You Need It” Is Over: Organizational Design for the Age of Resident AI Agents — about agents entering a “resident” phase — gives a more three-dimensional view of where resident review AIs like Bugbot sit.

A 7-Item Checklist to Embed in Your Own Dev Workflow

Let me convert the proposals so far into 7 items I’m putting into my own workflow this week. Professional engineers might think “well, duh,” but I’m writing for readers like me — side-job engineers, internal-tool builders.

Check 1. Write security clauses at the start of design

Place a CLAUDE.md (for Claude Code) or .cursorrules (for Cursor) in your project root. At the top, articulate at least three items: “use ○○ as the auth library,” “all input must pass validation,” “secrets must go through environment variables.” Just this changes the quality of generated code.

Check 2. Double-guard for secrets

Just adding .env* to .gitignore leaks. On GitHub, enable push protection (secret detection at push time); locally, run gitleaks or similar via a pre-commit hook. This stops “accidental commits” close to 100%.

Check 3. Human confirmation when adding dependencies

Configure things so AI agents don’t auto-execute npm install or pip install. In Claude Code’s Permissions settings, switch Bash(npm install:*) to “ask” mode (prompts for confirmation before execution). This prevents pulling in hallucinated package names or fake packages from slopsquatting attacks.

Check 4. Separate the privileges given to AI from production

Absolutely separate dev DB credentials from production DB credentials. AI agents can only touch dev. Place .env.development and .env.production in separate directories, with a structure where the agent cannot access .env.production. The Cursor incident happened right here.

Check 5. Destructive operations on a separate lane

Don’t let AI agents auto-execute DROP TABLE, DELETE FROM (without WHERE), rm -rf, or git push --force. Carve these commands into a human-approval lane. With Claude Code’s hook feature or Cursor’s “Deny list” setting, blocking isn’t hard. This ties into the canonical 2026-04-22 decision of “no skipping safety mechanisms like --no-verify.”

Check 6. Two-stage review: AI review + third-party linter

Primary review with Bugbot, secondary review with CodeQL (free on GitHub Actions) or semgrep. Only high-severity findings get human eyeballs. This minimizes human load while preserving independence.

Check 7. Keep an incident report template ready

Place a one-page template anyone can fill out as an empty file at docs/INCIDENT.md in your repo. Format is just six items: “datetime / event / scope of impact / root cause / interim response / prevention.” Having the template in advance means even during the 30 minutes of post-incident panic, a record gets left. For both the Lovable and Cursor incidents, the presence or absence of transparent post-incident disclosure determined how fast trust recovered.

You don’t need to do all seven perfectly from day one. Just Check 1 (write rules in CLAUDE.md) and Check 5 (block destructive operations) drop your accident probability dramatically. I started with these two and added the rest in order over a week.

Reference: Reading nagi’s article The 10 Days When Claude Code Enterprise Adoption Became “Marketized” on how companies are pushing adoption gives us individual developers a clearer picture of what to set up proactively.

Conclusion: A Story About Returning Design to 80%

Forrester’s “Secure Vibe Coding,” NCSC’s 5 principles, Checkmarx’s State of the Industry, and Cursor’s Bugbot. Lining up these four proposals side-by-side, what emerged was a return to a — actually classical — way of thinking: “Write a design that doesn’t break, from the start.”

My March article on KDDI’s “80% design,” my April article on AWS Kiro’s “spec-driven,” and today’s Secure Vibe Coding. From different sources, similar-direction answers are emerging. Vibe coding tends to get misunderstood as a development style that “skips design,” but its essence is “accelerating design with AI.” 80% design, 20% generation. When you return to that ratio, both Lovable’s 170 and Cursor’s production DB incident become structurally hard to cause.

I’m a former failed engineer. I have no intention of competing with professional engineers. But for the level of “running my own internal tools, my team’s SaaS, my side-project product without breaking them,” Secure Vibe Coding becomes our weapon. It doesn’t have to be perfect. Write three lines of security clauses in CLAUDE.md, and you start today.

Let me answer one question readers often ask. “Doesn’t being security-conscious make vibe coding less fun?” My answer is the opposite. Building a structure where you don’t have to worry about accidents lets you take bigger swings. The range you can move within while trusting “this will work” expands. That’s the hidden reward of Secure Vibe Coding.

After Lovable, Cursor followed, and the trilogy ending in prescription closes here. The next time news about something “breaking” comes out, if you can come back to this article and the first 30 minutes of panic gets a little easier, that’s my goal.

Reference links:

• Forrester “Vibe Code Securely Or Die Trying” by Janet Worthington (URL verification needed)
• NCSC official site (refer to AI-related guidance)
• Checkmarx official site (refer to 2026 AppSec report)
• Cursor official site (refer to Bugbot feature)
• The Register “Cursor-Opus agent snuffs out startup’s production database” (URL verification needed)
• nagi: The Era of “AI You Call When You Need It” Is Over
• nagi: The 10 Days When Claude Code Enterprise Adoption Became “Marketized”