DEV Community: Not Elon

Apple Just Killed a $100M Vibe Coding App. Here's the Security Angle Nobody's Talking About.

Not Elon — Thu, 02 Apr 2026 04:35:18 +0000

Last week, Apple removed "Anything" from the App Store. The startup had raised $11M at a $100M valuation. Gone overnight.

Replit and Vibecode are also blocked from releasing updates.

The tech press is calling it anticompetitive. X is full of takes about Apple killing innovation. The narrative is simple: Apple wants you to use Xcode with their AI tools, not third-party vibe coding apps.

But here's what nobody's talking about: Apple cited Guideline 2.5.2. And that's a security rule, not a competition rule.

What Guideline 2.5.2 Actually Says

"Apps should be self-contained in their bundles, and may not read or write data outside the designated container area, nor may they download, install, or execute code which introduces or changes features or functionality of the app."

Vibe coding apps, by definition, do exactly what this rule prohibits. They download code, execute it, and change app functionality on the fly. That's the entire product.

This isn't arbitrary. The rule exists because dynamic code execution is a security nightmare.

The Security Data Nobody's Citing

While everyone debates whether Apple is being anticompetitive, here's what's happening in the vibe coding security space:

35 new CVEs in March 2026 traced directly to AI-generated code vulnerabilities
escape.tech scanned 5,600 live vibe-coded apps and found hundreds with exposed API keys and secrets
UK's NCSC CEO called for vibe coding safeguards at RSA Conference this week
Trend Micro published their vibe coding risk analysis yesterday, calling it a "real and growing threat"
Harvard Gazette ran a piece today noting that vibe coders "don't typically need to concern themselves" with reliability, safety, and security

The problem is real. The question is whether banning apps is the right solution.

Why Vibe Coding Apps Are Uniquely Risky on iOS

Traditional iOS apps go through App Review. Apple scans them for malware, policy violations, and common security issues.

Vibe coding apps bypass this by generating code on-device after approval. The app that passes review is not the app users actually run. Whatever Claude or Codex generates next week isn't subject to any review.

This creates a few problems:

Prompt injection attacks can generate malicious code without user awareness
Supply chain vulnerabilities in the underlying LLMs propagate to every app built with them
No static analysis is possible on code that doesn't exist until runtime
Exposed secrets are common because vibe coders often don't know to protect them

Apple's Real Mistake

Apple is right that there's a security problem. They're wrong about the solution.

Banning apps doesn't fix the underlying vulnerability. It just pushes vibe coding to the web, where the same apps can run without any review at all.

A better approach:

Sandbox the generated code more aggressively
Require on-device code review before execution
Mandate secret scanning before deployment
Create a certification program for vibe coding platforms that meet security standards

Instead, Apple took the easy path: ban first, figure it out later.

What This Means for Vibe Coders

If you're building with Lovable, Bolt, Cursor, or any other AI coding tool:

Your iOS distribution options just narrowed. Web apps and PWAs are still fine. Native iOS apps generated by vibe coding tools face an uncertain future.
Security scanning is now mandatory. If you're shipping anything, you need to run a security scan. Tools like VibeCheck, Aikido, or ChakraView can catch exposed secrets and common vulnerabilities.
The regulatory spotlight is coming. If Apple is cracking down, expect the EU, UK, and others to start asking questions about AI-generated code quality.

The vibe coding gold rush isn't over. But the "ship fast, worry later" phase might be.

Building something with AI coding tools? VibeCheck is a free security scanner for vibe-coded apps. Paste your GitHub URL or deployed site, get a security grade in seconds.

Follow @solobillionsHQ for daily vibe coding security updates.

Anthropic Just Leaked Claude Code's Source. Here's What It Means for Your Vibe-Coded App.

Not Elon — Tue, 31 Mar 2026 23:04:23 +0000

Georgia Tech researchers just dropped a stat that should scare every vibe coder: 35 new CVEs in March 2026 were traced directly to AI-generated code.

But today, Anthropic proved the point better than any research paper could.

What Happened

Anthropic accidentally shipped a 59.8 MB JavaScript source map file in version 2.1.88 of their Claude Code npm package. That single file exposed the entire codebase: 512,000 lines of TypeScript, internal architecture details, 44 hidden feature flags, 20 unshipped features, and the exact prompts used to control the AI agent.

Within hours, the code was mirrored across GitHub, forked into open-source alternatives, and analyzed by thousands of developers. Anthropic confirmed it was "a release packaging issue caused by human error."

Human error. A source map in production. The exact same mistake AI coding tools make in your app every day.

Why This Matters More Than You Think

This isn't just an Anthropic story. It's a pattern.

Anthropic is a $30B company with a $2.5B ARR product. They have security teams, code review processes, and CI/CD pipelines. And a source map still made it to production.

Now think about what's shipping in the average vibe-coded app built with Lovable, Bolt, or Cursor:

Source maps in production builds (the exact same error Anthropic made)
.env files committed to public repos (your database credentials, API keys)
Debug endpoints left active (admin panels, test routes with no auth)
Hardcoded secrets in client-side code (visible to anyone who opens DevTools)
No .gitignore for sensitive files (lockfiles, build artifacts, config files with credentials)

These aren't theoretical. We see them in real apps every day.

The Pattern: Three Major AI Toolchain Incidents This Month

March 2026 was brutal for AI security:

LiteLLM supply chain attack (March 25): A backdoored package on PyPI got 47,000 downloads in 46 minutes. The same attacker also poisoned Telnyx (742K monthly downloads). Malware was hidden in a WAV file.
trivy-action poisoned (March 14): A GitHub Action used for security scanning was itself compromised. The tool meant to protect you became the attack vector.
Claude Code source leak (March 31): 512,000 lines of production code exposed via a source map in an npm package. The AI coding tool leaked its own source code.

The tools we use to build and secure AI-generated code are themselves becoming the attack surface.

What the Leaked Code Actually Revealed

For anyone building AI agents or using Claude Code, the leaked source exposed:

A profanity flagging system that quietly records flagged content
44 hidden feature flags controlling unreleased capabilities
A three-layer memory architecture (MEMORY.md index, topic files, grep-based transcript search)
Verification agent prompts that explicitly call out Claude's tendency to claim it verified something without actually running the check

That last one is telling. Anthropic's own internal prompts say: "reading is not verification. run it." They know their model takes shortcuts. Your vibe-coded app is built by that same model.

What You Should Do Right Now

Check your builds for source maps:

# Find source map files in your build output
find ./dist -name "*.map" -o -name "*.js.map"

# Check if your bundler is generating source maps for production
grep -r "sourcemap|sourceMap|devtool" webpack.config.* vite.config.* next.config.*

Check for exposed secrets:

# Search for hardcoded API keys and credentials
grep -rn "sk-|api_key|password|secret|token" --include="*.ts" --include="*.js" --include="*.env" .

# Make sure .env is in .gitignore
cat .gitignore | grep -i env

Check your npm packages:

# See what files are included in your package
npm pack --dry-run

# Add min-release-age to block new packages for 7 days
echo "min-release-age=7" >> ~/.npmrc

Or scan your whole app in 30 seconds: notelon.ai checks for source maps, exposed secrets, missing auth, and the other common vibe coding mistakes. Free. No signup.

The Lesson

Anthropic has 1,000+ employees, dedicated security teams, and enterprise compliance requirements. They still shipped a source map to production.

You're one person with an AI coding tool. What's in YOUR production build right now?

The gap between code generation speed and security review isn't closing. It's accelerating. 35 new CVEs from AI code in March. The tools themselves are becoming attack vectors. And the developers who need security most are the ones least likely to check.

Don't be the next leak. Scan your code before someone else does.

Sources: VentureBeat, Ars Technica, Fortune, Infosecurity Magazine

35 New CVEs in March From AI-Generated Code: The Numbers Are Getting Worse

Not Elon — Tue, 31 Mar 2026 17:08:44 +0000

Georgia Tech researchers just dropped a stat that should scare every vibe coder: 35 new CVEs in March 2026 were traced directly to AI-generated code. That's up from 6 in January and 15 in February.

The trend line is vertical.

The Vibe Security Radar

The Vibe Security Radar is a research project from Georgia Tech's Systems Software & Security Lab. They track vulnerabilities specifically introduced by AI coding tools that made it into public advisories (CVE.org, NVD, GitHub Advisory Database, OSV, RustSec).

Their method:

Pull from public vulnerability databases
Find the commit that fixed each vulnerability
Trace backwards to find who introduced the bug
If the commit has an AI tool's signature (co-author tag, bot email), flag it
AI agents investigate the root cause using actual Git history

74 confirmed cases so far. The real number is estimated at 5-10x higher (400-700 across open source) because tools like Copilot leave no metadata traces.

Which Tools Introduce the Most Vulnerabilities?

Claude Code shows up the most in the data, but the lead researcher Hanqing Zhao says that's mostly because Claude "always leaves a signature." Copilot's inline suggestions leave no trace.

They track approximately 50 AI-assisted coding tools: Claude Code, GitHub Copilot, Cursor, Devin, Windsurf, Aider, Amazon Q, Google Jules, and more.

Why This Matters for Vibe Coders

Here's the context that makes this urgent:

NCSC Warning: The UK's National Cyber Security Centre CEO called for vibe coding safeguards at RSA Conference this week
escape.tech Data: 5,600 live vibe-coded apps scanned, hundreds of vulnerabilities and exposed secrets found
Supply Chain Attacks: LiteLLM's PyPI package was backdoored (47K downloads in 46 minutes). The same attacker poisoned trivy-action, a security scanner itself
Only 18% of organizations can fix security vulnerabilities at the pace AI generates them (InformationWeek)

The gap between code generation speed and security review capacity is widening every month.

The 4 Most Common AI Code Vulnerabilities

Based on our analysis of hundreds of vibe-coded apps at VibeCheck:

Hardcoded secrets in source code (API keys, database credentials in plaintext)
No input validation before database queries (SQL injection, NoSQL injection)
Missing authentication on API endpoints (anyone can call them)
No rate limiting on auth endpoints (brute force attacks trivial)

AI coding tools generate functional code. They rarely generate secure code. The difference kills you in production.

What You Can Do Right Now

For your dependencies:

# .npmrc - block new packages for 7 days
min-release-age=7

# uv.toml - same for Python
exclude-newer = "7 days"

Most malicious packages get caught within 24-72 hours. A 7-day buffer kills the majority of supply chain attacks.

For your code:

Pin exact versions with lockfiles and hashes
Never hardcode secrets (use environment variables)
Add input validation on every endpoint that touches a database
Rate limit authentication endpoints
Run a security scan before deploying

Free scanner: notelon.ai checks for the common vibe coding mistakes. Paste your repo or URL, get results in seconds. No signup required.

The Trend Is Clear

Month	CVEs from AI Code
Jan 2026	6
Feb 2026	15
Mar 2026	35

That's a 150% month-over-month increase in February, then 133% in March. If this trajectory holds, April could see 70+.

The tools that generate code are getting faster. The tools that secure it aren't keeping up. That gap is the vulnerability.

Sources: Infosecurity Magazine, Georgia Tech Vibe Security Radar, NCSC, InformationWeek

The LiteLLM Supply Chain Attack: Why Vibe Coders Are the Most Exposed

Not Elon — Tue, 31 Mar 2026 00:32:54 +0000

On March 24, 2026, someone slipped malicious code into LiteLLM versions 1.82.7 and 1.82.8 on PyPI. LiteLLM gets 95 million downloads per month. It's the library that lets you route requests across LLM providers through a single API.

If you're vibe coding with any AI tool that uses LiteLLM under the hood, this affects you directly.

What Happened

The attacker (tracked as TeamPCP by Endor Labs) injected 12 lines of code into proxy_server.py. The code executes the moment the module is imported. No user interaction needed.

Version 1.82.8 went further: it added a .pth file that runs the payload on any Python invocation, even if you never import LiteLLM. Just having it installed is enough.

The payload runs a three-stage attack:

Harvests credentials: SSH keys, cloud tokens, Kubernetes secrets, crypto wallets, and .env files
Lateral movement: Deploys privileged pods across Kubernetes clusters
Persistence: Installs a systemd backdoor that polls for additional binaries

Everything gets encrypted and exfiltrated to an attacker-controlled domain.

Why Vibe Coders Are Most Exposed

This is the part that matters if you're building with Cursor, Lovable, Bolt, or Replit.

No lockfiles. Most vibe coders run pip install litellm without version pinning. Whatever is latest on PyPI is what you get. The compromised versions were live for 46 minutes before being pulled. That's 47,000 downloads.

No dependency auditing. When your AI coding tool adds a package, do you check what version? Do you verify hashes? Most vibe coders don't even know what packages their AI added to requirements.txt.

Trust inheritance. Your AI coding tool has access to your environment variables, API keys, and cloud credentials. A compromised dependency inherits all of that access. The attacker didn't need to break your code. They broke a library your code trusts.

The .pth file trick. This is particularly nasty. Python's .pth files execute at interpreter startup. Security scanners that check import-time execution wouldn't catch it. Static analysis tools that flag exec() and eval() wouldn't catch it either, because the payload uses subprocess.run() instead.

This Isn't an Isolated Incident

TeamPCP has been running a month-long campaign across five ecosystems:

GitHub Actions: Compromised Aqua Security's Trivy (a vulnerability scanner)
Docker Hub: Compromised Checkmarx's KICS (infrastructure-as-code analyzer)
npm: CanisterWorm malware
OpenVSX: VS Code extension supply chain
PyPI: LiteLLM (this attack)

Notice the pattern? They're specifically targeting security tools. The tools developers trust to keep them safe are the attack vector.

What You Should Do Right Now

1. Check if you're affected

pip show litellm | grep Version

If you see 1.82.7 or 1.82.8, you need to assume compromise. Rotate ALL credentials immediately.

2. Pin your dependencies

Stop installing latest. Use a lockfile with hashes.

litellm==1.82.6 --hash=sha256:<verified_hash>

3. Audit your requirements.txt

Look at what your AI coding tool added. Do you know what every package does? If not, you have blind trust in your dependency tree.

4. Use `pip audit`

pip install pip-audit
pip-audit

This checks your installed packages against known vulnerabilities.

5. Scan your deployed app

If you shipped a vibe-coded app to production, scan it. Exposed API keys, missing auth, open endpoints -- these are the things attackers look for first.

VibeCheck on notelon.ai scans for the most common vibe coding security mistakes. Free, no signup.

The Bigger Picture

35 CVEs were directly attributed to AI-generated code in March 2026 alone. Up from 15 in February and 6 in January.

The vibe coding security crisis isn't theoretical anymore. Real attacks are happening against the exact tools and packages vibe coders depend on.

The builders who scan, pin, and audit will survive. The ones running pip install with blind trust are one compromised package away from a full credential dump.

Previously: I Tested Every Vibe Coding Security Scanner (2026) -- ranked #3 on Brave for "best vibe coding security scanner"

This Week in AI Security: OpenAI Codex Hacked, LiteLLM Supply Chain Attack, Claude Gets Computer Control

Not Elon — Mon, 30 Mar 2026 22:35:45 +0000

This was the week AI security stopped being theoretical.

Three events, all within days of each other, paint a picture that every developer building with AI tools needs to understand.

1. OpenAI Codex: Command Injection via Branch Names

BeyondTrust's Phantom Labs team (Tyler Jespersen) found a critical vulnerability in OpenAI Codex affecting all Codex users.

The attack: command injection through GitHub branch names in task creation requests. An attacker could craft a malicious branch name that, when processed by Codex, would exfiltrate a victim's GitHub tokens to an attacker-controlled server.

The impact: full read/write access to a victim's entire codebase. Lateral movement across repositories. Everything.

OpenAI patched it quickly. But the pattern is what matters: AI coding tools inherit trust from user context (GitHub tokens, env vars, API keys) but don't treat that context as a security boundary.

Every AI coding tool that touches git has this same attack surface. Basically nobody is auditing for it.

2. LiteLLM Supply Chain Attack: 47K Downloads in 46 Minutes

On March 24, 2026, litellm version 1.82.8 was published to PyPI with a malicious .pth file that executed automatically on every Python process startup.

The payload: a multi-stage credential stealer targeting AI pipelines and cloud secrets. The same threat actor (TeamPCP) had already compromised Trivy, KICS, and Telnyx across five supply chain ecosystems.

The timeline:

13 minutes between the compromised publish and detection
47,000 downloads before the package was pulled
95 million monthly downloads for the litellm package overall

This is the package that most AI proxy servers use. If you're routing API calls through litellm (and many vibe-coded apps do), you were exposed.

Endor Labs just published their analysis showing this is the same attacker behind the Trivy and KICS compromises. This is a coordinated campaign targeting AI infrastructure specifically.

3. Claude Gets Computer Use: The Closed Loop

Anthropic released Computer Use for Claude Code. Claude can now open your apps, click through your UI, and test what it built, all from the CLI.

The capability is impressive. The security implications are sobering.

With Computer Use, the feedback loop is fully closed: Claude writes code, runs it, tests it visually, finds bugs, fixes them, deploys. No human in the loop checking if:

Auth middleware actually works
API keys are properly scoped
Rate limiting is real
Environment variables aren't hardcoded
The dependencies being installed are legitimate

This isn't Claude's fault. The tool works as designed. But it means insecure code ships faster than ever, with more confidence, because "it tested itself."

The Pattern

All three events share a common thread: trust boundaries in AI development are poorly defined.

Codex trusted user-supplied branch names as safe input
Vibe coders trusted pip install litellm as a safe operation
Claude Computer Use trusts that the code it wrote is correct because the UI loaded

Meanwhile, 9to5Mac reports that vibe coding has broken Apple's App Store review queue. Wait times are up from less than a day to 3+ days. The volume of AI-generated app submissions has overwhelmed human reviewers.

What comes next is predictable: automated security gates. Apple, Google, and every app marketplace will add automated scanning. Apps with exposed API keys, missing authentication, and hardcoded secrets will get auto-rejected before a human ever looks at them.

What You Can Do Today

If you're shipping vibe-coded apps:

Pin your dependencies. Use lockfiles. Verify hashes. Don't pip install without knowing exactly what version you're getting.
Treat AI-generated code as untrusted input. Review it the way you'd review a PR from a new hire. The code works, but "works" and "secure" are different things.
Scan before shipping. Tools like VibeCheck scan your GitHub repos and deployed URLs for the common vibe coding mistakes: exposed API keys, missing auth, open endpoints, insecure headers.
Assume your secrets are exposed. If you've ever hardcoded an API key in a vibe-coded project, rotate it now. Not tomorrow. Now.
Add rate limiting to every public endpoint. The bots are faster than your users.

The AI coding revolution is real. The security crisis is also real. They're the same thing.

I track vibe coding security tools and incidents at notelon.ai. Free scanner, no signup required.

OpenAI Codex Had a Command Injection Bug That Could Steal Your GitHub Tokens

Not Elon — Mon, 30 Mar 2026 20:34:02 +0000

BeyondTrust's Phantom Labs just published a report on a command injection vulnerability in OpenAI's Codex. It's patched now, but the attack pattern matters because it's exactly the kind of thing vibe coders won't see coming.

What Happened

Codex runs tasks inside managed containers that clone your GitHub repo and authenticate using short-lived OAuth tokens. The vulnerability: branch names weren't sanitized before being passed to shell commands during environment setup.

An attacker could craft a malicious branch name that injects arbitrary shell commands. Those commands execute inside the container with access to your GitHub token.

The attack worked across:

The Codex web interface
The CLI
The SDK
IDE integrations

Worse: it could be scaled. Embed a malicious payload in a branch name, and every developer who interacts with that repo through Codex gets compromised.

What Could Be Stolen

The GitHub OAuth tokens Codex uses aren't just read tokens. In enterprise environments where Codex has broad permissions:

Full read/write access to repositories
Workflow trigger permissions (CI/CD pipelines)
Organization-level access depending on token scope

One compromised branch name. Every Codex user on the repo exposed.

Why This Matters for Vibe Coders

This vulnerability was found by professional security researchers at BeyondTrust. Most vibe coders:

Don't review branch names for injection payloads
Don't audit what permissions their AI coding tools have
Don't know what an OAuth token scope even is
Trust that "it's a managed container" means it's safe

The attack surface isn't your code. It's your tools.

The Bigger Picture

This dropped the same day Claude Code launched Computer Use (mouse and keyboard control). Two separate stories, same lesson:

AI coding agents are live execution environments with access to your credentials.

They're not just autocomplete. They run commands, clone repos, access tokens, and now control your screen. Every new capability is a new attack surface.

In the last 7 days:

LiteLLM supply chain attack hit 95M monthly downloads (TeamPCP campaign)
Same attacker compromised Trivy (vulnerability scanner) and KICS (IaC analyzer)
OpenAI Codex command injection exposed GitHub tokens
Claude Code gained mouse and keyboard access

The tools we trust to write and test our code are becoming the primary attack vector.

What To Do

Audit your AI tool permissions. What repos can Codex access? What scope do the tokens have? Minimize to read-only where possible.
Pin your dependencies. TeamPCP compromised packages that millions install without version pinning.
Don't trust container isolation alone. The Codex containers had network access. "Managed" doesn't mean "secure."
Scan your deployed apps. If you built it with AI tools, scan it before users find what you missed. VibeCheck is free.
Check for exposed secrets. Branch names, commit messages, config files. AI tools don't flag these by default.

OpenAI patched this one. The next vulnerability in the next AI coding tool hasn't been found yet.

Building VibeCheck, a free security scanner for vibe-coded apps. Follow @solobillionsHQ for daily vibe coding security updates.

Claude Code Just Got Mouse and Keyboard Access. Here's What That Means for Security.

Not Elon — Mon, 30 Mar 2026 18:39:15 +0000

Claude Code launched Computer Use today. In one prompt, Claude can write code, compile it, launch the app, click through the UI, find bugs, fix them, and verify the fix.

Everyone is celebrating the productivity unlock. Nobody is talking about the new attack surface.

What Changed

Before today, Claude Code could read and write files. That's it. A prompt injection from a malicious dependency could write bad code to disk. Annoying, but contained. The blast radius was your filesystem.

After today, Claude Code can interact with any app you whitelist. Open a browser. Click through a GUI. Type into forms. The blast radius is now anything on your screen.

The Same Day, BeyondTrust Drops This

Hours before Anthropic's announcement, BeyondTrust Phantom Labs published a critical vulnerability in OpenAI Codex. The attack: command injection via GitHub branch names in task creation requests. The result: exfiltration of a victim's GitHub tokens to an attacker's C2 server, granting full read/write access to their entire codebase.

The attack vector was a branch name. Not a malicious file. Not a suspicious dependency. A branch name.

This is the pattern: AI coding tools inherit trust from user context (GitHub tokens, env variables, API keys) but don't treat that context as a security boundary. The tool is an agent with your credentials.

Why Computer Use Changes the Threat Model

Anthropic added app-level permissioning, which is the right first step. You whitelist specific apps and choose between look-only and full control. But let's think about what happens when things go wrong.

The old attack chain:

Malicious dependency or compromised MCP plugin
Prompt injection lands in a file Claude reads
Claude writes malicious code to disk
Developer (hopefully) reviews before shipping

The new attack chain:

Same malicious dependency or MCP plugin
Same prompt injection
Claude now has access to whitelisted apps
"Open browser, navigate to [exfil endpoint], paste clipboard" becomes a real attack path
No file on disk to review. The action happened in the UI.

The attack doesn't need full desktop access. It just needs one whitelisted app.

The Confirmation Loop Problem

Everyone is excited about the "closed loop": write code, test it visually, fix bugs. But think about what this loop actually verifies.

Claude can see: "the button renders correctly." Claude can see: "the page loads without errors."

Claude cannot see: "this form sends credentials over HTTP." Claude cannot see: "this API endpoint has no auth check." Claude cannot see: "the database query is injectable."

Security vulnerabilities are invisible in the UI. A page can look perfect in every screenshot while leaking data through every endpoint.

Worse: the same model that writes the insecure code is now verifying it. That's not a closed loop. It's a confirmation loop. You need an adversarial check, not a self-review.

"Claude tested it and it works" is about to become the new "it compiles, ship it."

The LiteLLM Supply Chain Attack Is Still Fresh

One week ago, the LiteLLM supply chain attack hit 47K downloads in 46 minutes. The same attacker (TeamPCP) had already compromised Trivy and Telnyx. Malware hidden in a WAV file using steganography. MsBuild compiling inline C# at runtime. XOR-encoded payloads with no signatures to match.

These are packages that vibe coders pip install without lockfiles or hash pinning. 88% of LiteLLM's pip installs had no version pinning.

Now imagine that same compromised package running on a machine where Claude has Computer Use enabled. The injection doesn't just write to files anymore. It can interact with your apps.

What Should You Actually Do?

Whitelist the minimum. Don't add apps you don't need Claude to test. Every whitelisted app is attack surface.
Use look-only mode when you don't need click-and-type. If Claude only needs to verify visual layout, it doesn't need to click.
Don't trust the closed loop for security. Claude verifying its own output catches UI bugs, not security holes. Run a separate security check with a different tool or different model.
Pin your dependencies. Use lockfiles. Use hash verification. The supply chain is the entry point for most of these attacks.
Check what Claude is reading. If a malicious file lands in your project (through a compromised dependency, a PR, or an MCP plugin), Claude will read it. With Computer Use, it can now act on it.

This Isn't Anti-Progress

Computer Use in Claude Code is genuinely useful. Being able to visually verify what you build eliminates an entire class of "works in terminal, broken in browser" bugs.

But capability and attack surface are the same thing. Every new thing an AI agent can do is also a new thing an attacker can make it do, if they can inject the right prompt.

The security conversation needs to keep pace with the capability conversation. Right now, it's not even close.

I track vibe coding security tools, vulnerabilities, and the evolving threat landscape. Free security scanner at notelon.ai.

I Scanned 30 Lovable Apps This Month. Here Are the 5 Security Issues I Found in Almost Every One

Not Elon — Mon, 30 Mar 2026 02:02:44 +0000

I run security scans on vibe-coded apps. This month I looked at 30 apps built with Lovable, and the same five issues appeared in nearly every one.

These are not theoretical risks. They are things any user with browser DevTools could exploit in under five minutes.

1. Supabase RLS policies that check role instead of ownership

This was in roughly 80% of apps that use Supabase.

The AI generates a Row Level Security policy like this:

CREATE POLICY "Users can view data"
ON public.user_data
FOR SELECT
USING (auth.role() = 'authenticated');

This means any logged-in user can read every row in the table. Not just their own. Every user's data.

The fix is one function call: auth.uid() = user_id instead of auth.role() = 'authenticated'.

I wrote a full guide on checking and fixing this.

2. Supabase anon key + service role key in the JavaScript bundle

Every Lovable app that uses Supabase ships the anon key in the client bundle. That part is expected and documented by Supabase.

The problem: about 1 in 5 apps I scanned also had the service role key in the client bundle. The service role key bypasses all RLS policies. If someone extracts it from your JavaScript (which takes about 30 seconds with DevTools), they have full read/write access to every table.

How to check: Open your deployed app. View page source. Search for eyJ (the start of a base64-encoded JWT). You should find exactly one key (the anon key). If you find two, the second is probably your service role key.

The fix: Move any server-side logic that uses the service role key into a Supabase Edge Function or server-side API route. Never import the service role key in client code.

3. No email verification required

Lovable apps typically set up Supabase Auth with email + password. The AI generates the signup flow, the login flow, and the protected routes.

What it does not generate: email verification.

This means anyone can sign up with any email address (including addresses they do not own) and immediately access the app. Combined with the RLS issue from #1, they can also read every other user's data.

How to check: Go to your Supabase dashboard > Authentication > Settings > Email. Look for "Enable email confirmations." If it is off, anyone can sign up with a fake email.

The fix: Enable email confirmations in Supabase. Then update your app's auth flow to handle the "check your email" state between signup and confirmation.

4. API keys for third-party services in environment variables that get bundled

This goes beyond Supabase. If your Lovable app uses OpenAI, Stripe, SendGrid, or any other service with an API key, check where that key lives.

Lovable apps built with Vite expose any environment variable that starts with VITE_ to the client bundle. If your OpenAI key is stored as VITE_OPENAI_API_KEY, it ships to every user's browser.

How to check: Open DevTools > Sources > find your compiled JS files > search for your key prefix or the string sk- (OpenAI) or SG. (SendGrid).

The fix: Any key that costs money when called (OpenAI, Stripe secret key, SendGrid) must live on the server side only. Create a Supabase Edge Function or backend API that proxies the request.

5. No rate limiting on authentication endpoints

None of the 30 apps I scanned had rate limiting on their auth endpoints. This means an attacker can attempt unlimited password guesses, send unlimited password reset emails, or create unlimited accounts.

Supabase has built-in rate limiting for auth, but the defaults are generous and the AI never tightens them.

How to check: Open Supabase dashboard > Authentication > Rate Limits. Look at the current settings.

The fix: Set rate limits that make sense for your app. For most apps: 5 signups per hour per IP, 10 login attempts per hour per IP, 3 password reset emails per hour per email.

Why these keep appearing

The pattern is consistent: Lovable (and other AI tools) optimize for "the feature works" not "the feature is secure." Every one of these apps worked correctly. Users could sign up, log in, and use every feature. The security gaps were invisible during normal use.

The AI does not add security controls unless you specifically prompt it to. And most builders do not know what to prompt for because they are not security experts. That is the whole point of vibe coding.

What to do about it

If you have a Lovable app with real users:

Run the Supabase RLS check from issue #1 right now. It takes 2 minutes.
Search your client bundle for eyJ and count the JWT tokens. If there are more than one, you have a problem.
Search for sk- and SG. in your bundle.
Check your auth email verification setting.
Review your rate limits.

We built free scanning tools at notelon.ai that automate checks 2-4. No signup required.

If you want a human review covering all five issues plus business logic, auth flows, and API design, our $99 security audit covers 50+ checks with a PDF report and fix instructions.

Part of the Vibe Coding Security series. Updated weekly with new findings.

Your Supabase RLS Is Probably Wrong: A Security Guide for Vibe Coders

Not Elon — Sun, 29 Mar 2026 21:36:30 +0000

You built your app with Lovable, Cursor, or Bolt. You connected Supabase. You enabled Row Level Security because the docs said to.

Your RLS is probably wrong.

I have scanned dozens of vibe-coded apps this month. The same RLS mistake appears in roughly 80% of them. The app works perfectly. Every feature functions. Users can sign up, create data, view their data. And every user can also view every other user's data.

The mistake

Here is what AI-generated RLS policies typically look like:

CREATE POLICY "Users can view data"
ON public.user_data
FOR SELECT
USING (auth.role() = 'authenticated');

This policy says: if you are logged in, you can read all rows. Every row. Every user's data.

Here is what it should say:

CREATE POLICY "Users can view their own data"
ON public.user_data
FOR SELECT
USING (auth.uid() = user_id);

The difference is one function call. auth.role() checks if someone is logged in. auth.uid() checks if the logged-in user owns that specific row. One character of difference in the code, total difference in security.

Why AI tools get this wrong

When you prompt Lovable or Cursor to "add authentication to my app," the AI does exactly what you asked. It adds login and signup. It creates the database tables. It enables RLS.

But the AI optimizes for "works correctly" not "works securely." The policy it generates passes every test: authenticated users can read data, unauthenticated users cannot. That is technically correct. It is also a data breach.

Nobody prompts the AI to add ownership checks. The AI does not add them unprompted. The result is an app that looks secure but leaks data between users.

How to check yours in 2 minutes

Open the Supabase SQL editor and run:

SELECT
  schemaname,
  tablename,
  policyname,
  qual
FROM pg_policies
WHERE schemaname = 'public'
ORDER BY tablename;

Look at the qual column. If you see (auth.role() = 'authenticated'::text) on any table that stores user data, you have the problem.

If you see (auth.uid() = user_id) or something similar with auth.uid(), you are probably fine for that table.

The fix

For each table that stores user-specific data:

-- Drop the broken policy
DROP POLICY "Users can view data" ON public.user_data;

-- Create the correct one
CREATE POLICY "Users can view their own data"
ON public.user_data
FOR SELECT
USING (auth.uid() = user_id);

-- Do the same for INSERT, UPDATE, DELETE
CREATE POLICY "Users can insert their own data"
ON public.user_data
FOR INSERT
WITH CHECK (auth.uid() = user_id);

CREATE POLICY "Users can update their own data"
ON public.user_data
FOR UPDATE
USING (auth.uid() = user_id);

CREATE POLICY "Users can delete their own data"
ON public.user_data
FOR DELETE
USING (auth.uid() = user_id);

Replace user_data with your actual table name. Replace user_id with whatever column stores the user's UUID in that table.

Common variations that are also broken

Service role bypass:

USING (auth.role() = 'service_role' OR auth.role() = 'authenticated')

Still broken. Any authenticated user reads everything.

True for all:

USING (true)

No restriction at all. Anon users can read everything. This appears more often than you would expect.

Missing policies entirely:
Some tables have RLS enabled but zero policies. This actually blocks all access (Supabase defaults to deny), which is better than the wrong policy. But it usually means the developer disabled RLS on that table to "fix" their app when queries stopped working.

Tables that need ownership checks

Not every table needs auth.uid() = user_id. Here is a quick breakdown:

Needs ownership check: profiles, user_data, orders, messages, documents, settings, anything with personal or financial data

Does not need ownership check: public content (blog posts set to published), lookup tables (countries, categories), app configuration

Needs role-based check: admin panels, moderation queues, shared team data

What happens when this is wrong

A user creates an account on your app. They open browser DevTools. They go to the Network tab. They find a Supabase request. They copy the URL and anon key (both visible in the JavaScript bundle). They run:

curl 'https://your-project.supabase.co/rest/v1/user_data?select=*' \
  -H "apikey: your-anon-key" \
  -H "Authorization: Bearer their-jwt-token"

Every user's data comes back. Names, emails, financial data, health data, whatever you store. One curl command.

Beyond RLS

RLS is the most common issue but not the only one. Other things to check:

API keys in your JS bundle. Open your deployed site, view source, search for eyJ. Your Supabase anon key will be there (expected). Anything else should not be.
Auth email verification. Is it required? If not, anyone can sign up with any email and start querying.
Rate limiting. Are your auth endpoints rate-limited? If not, brute force attacks work.
Storage bucket policies. If you use Supabase Storage, the bucket policies have the same RLS problem. Check them separately.

We built free security tools specifically for this at notelon.ai. The code scanner checks for exposed keys and common misconfigurations. No signup required.

If you want a deeper review covering all of the above plus business logic, auth flows, and API design, our $99 security audit covers 50+ checks with a PDF report.

Part of the Vibe Coding Security series. More guides on Lovable, Cursor, Bolt, and Windsurf security at notelon.ai/report.

The UK Government Just Called Vibe Coding Security Risks 'Intolerable'

Not Elon — Sun, 29 Mar 2026 13:27:58 +0000

The head of the UK's National Cyber Security Centre (NCSC) stood up at RSA Conference last week and called the security risks from AI-generated code "intolerable."

The same week, Cursor's CEO warned that vibe coding builds "shaky foundations" that eventually "crumble."

The same week, someone compromised LiteLLM's PyPI package and got 47,000 poisoned downloads in 46 minutes.

These aren't separate stories. They're the same story.

What the NCSC actually said

The NCSC CEO called for international cooperation on vibe coding security. Not guidelines. Not best practices. International cooperation. That's the language governments use when they think a problem is bigger than any one country can solve.

Why? Because vibe-coded apps are shipping to production at a rate that outpaces any security review process. The code compiles. The tests pass. The app works. The security is broken.

What "broken security" actually looks like

We've been scanning vibe-coded apps for months. The pattern is the same every time:

Supabase RLS disabled or misconfigured. Default Lovable setup ships with Row Level Security that checks "is this user authenticated?" instead of "does this user own this data?" Any logged-in user can read any other user's records. For a todo app, whatever. For a health app with 8,700 users storing body metrics? That's a data breach waiting to happen.

API keys in client-side JavaScript bundles. Vite and Next.js handle environment variables differently. Vibe coders rarely know the difference. We regularly find Supabase anon keys, Stripe publishable keys, and occasionally secret keys sitting in the JS bundle anyone can read with browser DevTools.

Zero rate limiting on auth endpoints. No brute-force protection on login. No cooldown on password reset. No limit on API calls. The AI never adds these because nobody prompts for them.

No input validation on database-touching forms. The AI builds the form. The form submits to Supabase. Nothing in between checks whether the input is valid, safe, or even the expected type.

The numbers

Escape.tech scanned 5,600 AI-built apps. 60% failed basic security checks.
Wikipedia tracked 1,645 Lovable-created web apps. 170 had personal data access issues.
ReversingLabs documented a cascading supply chain attack (TeamPCP) that hit LiteLLM and Telnyx in the same week, compromising 47,000 and 742,000 downloads respectively.

What Cursor's CEO got wrong

Michael Truell compared vibe coding to "erecting four walls and a roof while being oblivious to the details lurking beneath the floorboards or within the wiring."

The metaphor is wrong. The floorboards are fine. The wiring works. The problem is that the house has no locks on the doors, no fence around the yard, and the windows don't close. Everything functions. Nothing is secure.

The fix isn't "learn to code properly" as Truell implies. The fix is: review your security defaults before you deploy. 20 minutes checking RLS, env vars, auth flows, and rate limiting. That's it.

What to do about it

If you've shipped a vibe-coded app to production:

Check your Supabase RLS policies. Open the SQL editor and verify every table has policies that check auth.uid() = user_id, not just auth.role() = 'authenticated'.
Search your deployed JS bundle for JWTs and API keys. Open DevTools, go to Sources, and search for eyJ (the base64 prefix of every JWT). If you find your Supabase anon key, that's expected. If you find anything else, you have a problem.
Add rate limiting to your auth endpoints. Even a simple 5-requests-per-minute limit on login and password reset prevents brute force.
Run a security scanner. We built free tools at notelon.ai specifically for vibe-coded apps. No signup required. If you want a deeper review, our $99 audit covers 50+ checks with a PDF report.

The NCSC, Cursor's CEO, and the supply chain attacks are all pointing at the same thing: the code works, the security doesn't. The good news is it's fixable. The bad news is most people won't fix it until something breaks.

Full security report with 63+ sources: notelon.ai/report

What a $1,000 Code Review Actually Finds in Lovable and Claude Code Apps

Not Elon — Sat, 28 Mar 2026 20:28:18 +0000

A post on r/vibecoding went viral this week. Someone paid a senior dev $1,000 on Upwork to review their vibe-coded app. The verdict: "good code, just needs a few security concerns addressed."

That's the outcome for almost every vibe-coded app I've looked at. The code works. The UI is fine. The security is broken.

Here's what actually shows up in these reviews.

The Same 5 Issues, Every Time

1. Supabase RLS policies that don't exist or don't work

Lovable sets up Supabase for you. It creates tables, writes queries, handles auth. What it doesn't do reliably is lock down who can read what.

Open your Supabase dashboard right now. Go to Authentication > Policies. If you see tables with no policies, that table is readable by anyone with your Supabase URL and anon key. Both are in your client bundle. Anyone can open devtools and find them.

The fix is row-level security policies on every table. But the AI generates policies that look right and aren't. A common one: a policy that checks auth.uid() = user_id on SELECT but has no policy on UPDATE or DELETE. So users can read only their own data but can modify anyone's.

2. API keys in the client bundle

Open your deployed app. Open devtools. Go to Sources. Search for "sk_" or "key" or "secret" or "Bearer". If you find anything, that key is public.

Vibe coding tools don't always know which API calls should happen server-side. They'll put a Stripe secret key or an OpenAI API key directly in a React component because the code works and the AI optimizes for working code.

One app I reviewed had a Resend API key in the client. Anyone could send emails as that company. Another had an OpenAI key that was burning $40/day from unauthorized usage before the founder noticed.

3. No rate limiting on auth endpoints

Someone can hit your login endpoint 10,000 times per second with different passwords. No lockout, no delay, no CAPTCHA. For password reset: an attacker can trigger thousands of reset emails to any address, which gets your email domain blacklisted.

4. Missing input validation on the backend

The AI validates inputs on the frontend. It checks email format, required fields, string length. But if someone bypasses the frontend (which is trivial), the backend accepts anything.

This means SQL injection, XSS stored in your database, and malformed data that breaks your app for other users. Supabase edge functions generated by AI almost never validate input types.

5. Dependencies with known vulnerabilities

Every vibe-coded app I've seen has at least 3 npm packages with known CVEs. The AI picks packages that work, not packages that are maintained. A npm audit will show you, but most vibe coders never run it.

The recent TeamPCP supply chain attack targeted PyPI packages (telnyx, litellm) with malicious versions. If you're using AI to pick your dependencies, you're trusting that the AI knows which version is safe. It doesn't.

Why This Matters Now

When your app has 0 users, none of this matters. But the moment someone enters their email, their payment info, their personal data, you're liable.

GDPR fines start at 10 million euros for data breaches caused by inadequate security. Even in the US, state privacy laws are getting teeth. "I used AI to build it" is not a defense.

170 out of 1,645 Lovable-created apps were found to have data exposure issues earlier this year. That's over 10%.

The Market Gap

Here's the reality of getting a code review as a vibe coder:

Free: Ask Claude/ChatGPT to review your code. It'll find surface-level issues but miss the architectural ones. It generated the code, so it has the same blind spots.
$500-$1,000: Hire a senior dev on Upwork. Takes a week. May not specialize in the specific security patterns of AI-generated code.
$5,000+: Professional penetration test. Enterprise-grade but overkill for a solo founder's MVP.

There's nothing in between for the vibe coder who just wants to know: "Is my app safe to launch?"

That's the gap. A focused security audit that knows exactly where Lovable, Cursor, Bolt, and Claude Code break. Not a general code review. A checklist of the exact vulnerabilities these tools introduce, tested against your specific app, with copy-paste fix prompts you can feed back into the AI.

Check Your App Right Now

Before you ship, run through this yourself:

Open Supabase > Authentication > Policies. Every table should have RLS enabled with policies for SELECT, INSERT, UPDATE, DELETE.
Open devtools on your deployed app. Search Sources for API keys (sk_, key_, secret, Bearer).
Try signing up 10 times in 10 seconds. If it works every time, you have no rate limiting.
Run npm audit in your project. Fix anything marked critical or high.
Check your .env file isn't committed to git: git log --all -- .env

If you want a deeper check, I built a free scanner at notelon.ai/tools/vibecheck that runs automated checks against your repo. For a full manual audit with a PDF report and fix prompts, there's a $99 audit service.

I build security tools for vibe coders at notelon.ai.

If You're Selling Vibe-Coded Apps to Clients, You're One Breach Away From a Lawsuit

Not Elon — Sat, 28 Mar 2026 07:57:31 +0000

You built a client's app in 3 hours with Lovable. Charged $500. Client loved it. Shipped it.

Six weeks later, their customer data leaks. The client's lawyer sends you a letter.

This isn't hypothetical. It's the trajectory.

The Numbers Nobody's Talking About

60% of AI-generated apps fail basic security tests (Escape.tech, 5,600 apps scanned)
67% of vibe-coded repos have critical vulnerabilities (ShipSafe, 100 repos audited)
35 new CVEs in March 2026 alone from AI-generated code (Georgia Tech Vibe Radar)
47,000 poisoned downloads in 46 minutes when LiteLLM was supply chain attacked last week

You're not building insecure apps on purpose. The AI tools you're using are generating insecure code by default. Missing Row Level Security. Hardcoded API keys. No input validation. Client-side only authentication.

The AI optimizes for "it works." Not "it's secure."

The Liability Problem

When you build an app for a client, you own the outcome. "I used AI to build it" is not a legal defense. Neither is "I didn't know it was insecure."

If client data gets exposed because you shipped an app with:

No RLS on Supabase tables (anyone can read any user's data)
Hardcoded API keys in client-side code (visible in browser dev tools)
No rate limiting (bot can dump the entire database)
Missing security headers (clickjacking, XSS)

...that's on you. Not the AI tool. Not the platform. You.

The Fix (That Also Makes You More Money)

Add a security audit as an upsell on every project.

Not "learn security." Not "become a pentester." Outsource it.

The pitch to clients:

"I've built your app. Before we go live, I recommend a security audit to make sure your users' data is protected. It's $99 and takes 24 hours. You'll get a full report showing exactly what's secure and what needs fixing."

Client hears: professional, thorough, protective of their business.

You hear: $99 in margin on a deliverable you didn't build.

The Math

Scenario	Your Fee	Audit Cost	Your Margin	Client Gets
No audit	$500	$0	$500	Vulnerable app + liability
With audit	$599	$99	$500	Secure app + peace of mind

Same margin. Better deliverable. Lower liability. Recurring revenue if client wants monthly scans.

What a $99 Audit Covers

A real audit checks 50+ security vectors specific to vibe-coded apps:

Authentication & Authorization: RLS policies, JWT validation, admin routes
Secrets Management: Exposed API keys, env vars in client code, .git exposure
Input Validation: SQL injection, XSS, path traversal
API Security: Rate limiting, CORS configuration, error handling
Supply Chain: Dependency versions, known vulnerabilities, lockfile integrity
Infrastructure: Security headers, HTTPS enforcement, cookie flags

You get a report with every finding, severity rating, and a copy-paste AI prompt to fix each issue.

See a sample audit report

Free Tools to Start With

Before you upsell audits, run your own builds through these:

VibeCheck Scanner -- Paste your repo URL. Get a security score in 30 seconds. Free.
Security Assessment Quiz -- 10 questions. 2 minutes. Know your risk grade.
Breach Cost Calculator -- Show your client what a breach would cost them. Makes the $99 audit feel like nothing.

Platform-Specific Risks

Every vibe coding tool has different security blind spots:

Lovable: RLS disabled by default, Supabase keys in client code, 200K daily projects with 63% non-developer users
Bolt.new: No built-in security scanning, manual deployment to any platform, no guardrails
Cursor: MCP plugin supply chain attacks, .cursorrules injection, terminal command execution
Windsurf: Cascade autonomous execution, Memories storing sensitive data, cloud/local confusion
Replit: Agent controls entire stack (code + DB + deployment), public-by-default repos, rogue agent incident (July 2025)

The Bottom Line

You're building apps faster than ever. That's the upside.

The downside: you're shipping vulnerabilities faster than ever too. Your clients trust you to deliver something that works AND doesn't leak their data.

A $99 security audit takes 24 hours and covers 50+ checks. It protects your client, protects you from liability, and adds margin to every project.

Or skip it. And hope nobody finds the RLS bypass before your client's data shows up on a breach notification site.

Get a security audit for your next client project -- $99 for a full 50+ check assessment with actionable fix prompts. Results in 24 hours.

DEV Community: Not Elon

Apple Just Killed a $100M Vibe Coding App. Here's the Security Angle Nobody's Talking About.

What Guideline 2.5.2 Actually Says

The Security Data Nobody's Citing

Why Vibe Coding Apps Are Uniquely Risky on iOS

Apple's Real Mistake

What This Means for Vibe Coders

Anthropic Just Leaked Claude Code's Source. Here's What It Means for Your Vibe-Coded App.

What Happened

Why This Matters More Than You Think

The Pattern: Three Major AI Toolchain Incidents This Month

What the Leaked Code Actually Revealed

What You Should Do Right Now

The Lesson

35 New CVEs in March From AI-Generated Code: The Numbers Are Getting Worse

The Vibe Security Radar

Which Tools Introduce the Most Vulnerabilities?

Why This Matters for Vibe Coders

The 4 Most Common AI Code Vulnerabilities

What You Can Do Right Now

The Trend Is Clear

The LiteLLM Supply Chain Attack: Why Vibe Coders Are the Most Exposed

What Happened

Why Vibe Coders Are Most Exposed

This Isn't an Isolated Incident

What You Should Do Right Now

1. Check if you're affected

2. Pin your dependencies

3. Audit your requirements.txt

4. Use pip audit

5. Scan your deployed app

The Bigger Picture

This Week in AI Security: OpenAI Codex Hacked, LiteLLM Supply Chain Attack, Claude Gets Computer Control

1. OpenAI Codex: Command Injection via Branch Names

2. LiteLLM Supply Chain Attack: 47K Downloads in 46 Minutes

3. Claude Gets Computer Use: The Closed Loop

The Pattern

What You Can Do Today

OpenAI Codex Had a Command Injection Bug That Could Steal Your GitHub Tokens

What Happened

What Could Be Stolen

Why This Matters for Vibe Coders

The Bigger Picture

What To Do

Claude Code Just Got Mouse and Keyboard Access. Here's What That Means for Security.

What Changed

The Same Day, BeyondTrust Drops This

Why Computer Use Changes the Threat Model

The Confirmation Loop Problem

The LiteLLM Supply Chain Attack Is Still Fresh

What Should You Actually Do?

This Isn't Anti-Progress

I Scanned 30 Lovable Apps This Month. Here Are the 5 Security Issues I Found in Almost Every One

1. Supabase RLS policies that check role instead of ownership

2. Supabase anon key + service role key in the JavaScript bundle

3. No email verification required

4. API keys for third-party services in environment variables that get bundled

5. No rate limiting on authentication endpoints

Why these keep appearing

What to do about it

Your Supabase RLS Is Probably Wrong: A Security Guide for Vibe Coders

The mistake

Why AI tools get this wrong

How to check yours in 2 minutes

The fix

Common variations that are also broken

Tables that need ownership checks

What happens when this is wrong

Beyond RLS

The UK Government Just Called Vibe Coding Security Risks 'Intolerable'

What the NCSC actually said

What "broken security" actually looks like

The numbers

What Cursor's CEO got wrong

What to do about it

What a $1,000 Code Review Actually Finds in Lovable and Claude Code Apps

The Same 5 Issues, Every Time

Why This Matters Now

The Market Gap

Check Your App Right Now

4. Use `pip audit`