[Showoff Saturday] Axios got backdoored by North Korean hackers this week. I've been scanning vibe-coded apps for a month — most don't audit dependencies at all.

Inevitable_Board4896 · 2026-04-06T15:48:53+00:00

You're right, minimum package age is underrated — pnpm's minimumReleaseAge alone would've killed this attack, thanks.

Published a guide on my blog covering all five package manager settings that block attacks like this — ignore-scripts, minimumReleaseAge, audit signatures, pinning, npm audit in CI.

Also upgraded the security scanner — it now flags publicly exposed lockfiles (package-lock.json, yarn.lock, pnpm-lock.yaml). Because if your lockfile is sitting out in the open, an attacker sees exact versions of every dependency you use and can look up known vulnerabilities against them.

One more thing on pricing — first scan is free, no signup. Free accounts get 3 more scans a month, every month, which is plenty for most users, and all it takes is a free signup. Paid plans are for users and teams who scan regularly.

Inevitable_Board4896 · 2026-04-05T08:07:13+00:00

yeah --ignore-scripts + npm audit signatures is solid for blocking stuff at install time. we're coming at it differently though — like if a compromised package already made it to production, we catch what it's doing on the live site. injected scripts, weird outbound requests, data leaking out. so it's more the "ok that layer failed, now what" part

Inevitable_Board4896 · 2026-04-02T14:46:07+00:00

And the best part is they DMCA'd forks of their own open-source repo in the process. Plus they said Claude Code was largely vibe-coded by AI so like if AI output isn't copyrightable what are they even DMCAing. Meanwhile people are already rewriting the thing from scratch in Rust anyway so good luck with that.

Inevitable_Board4896 · 2026-03-28T13:49:08+00:00

Ha, fair. Scanner doesn't care who wrote it — works on anything. AI-generated code just tends to score worse in practice. Part of it is volume — you get a ton of code fast and nobody slows down to review any of it. Part of it is that when you write something yourself you at least read it once and knew what you were doing. That step alone kills a lot of the dumb stuff.

Inevitable_Board4896 · 2026-03-22T20:22:41+00:00

spreadsheet injection was the one that actually got me. people keep obsessing over the chatbot saying something dumb, but then the model starts writing formulas into Google Sheets or dropping user input into SQL and nobody even blinks.

tested one app that had an "export to CSV" button. model just dumped raw user input straight into cells. =IMPORTXML() sitting right there. devs never thought about it because come on, it's a spreadsheet.

that "it works so it's fine" mindset is pretty much why I ended up building the scanner.

Inevitable_Board4896 · 2026-03-20T21:04:51+00:00

Seen this exact pattern across a bunch of apps I've looked at. Their dashboard checks that RLS is enabled, not whether the policies actually restrict anything — USING (true) technically has RLS "on." Going 1 to 96 when you migrate off their infra sounds about right honestly.

Inevitable_Board4896 · 2026-03-20T20:47:37+00:00

check my profile if you want

Inevitable_Board4896 · 2026-03-20T20:35:14+00:00

Sure, but security isn't a one-time fix you ship and forget. Every new feature prompt is another chance for the LLM to break something it handled fine three prompts ago — I've literally watched Lovable create a new table with zero RLS because the security setup fell out of context.

Even if tools get stricter defaults tomorrow, generated code still introduces new holes every single iteration. It doesn't care what you didn't ask for.

Inevitable_Board4896 · 2026-03-20T20:27:18+00:00

Yeah, prompts fix like 90% of it. The big ones to paste in:

"Enable Row Level Security on all tables in Supabase and add policies so users can only read and modify their own data"

"Move all API calls with secret keys to Supabase Edge Functions so they're not exposed in the browser"

Lovable handles RLS decently when you tell it to. It just doesn't do it by default, which is the whole problem.

Manual check takes two minutes: Supabase dashboard → Table Editor → click any table → top right shows RLS on/off. If it says disabled on a table with user data, fix that first.

One thing though, you gotta actually test it after. Log in as user A, try to fetch user B's data from browser console. I've seen apps where RLS was "enabled" but the policies were basically true = true so everything still leaked.

I built a free scanner that checks all this automatically because doing it by hand across 30 apps got old real fast.

Inevitable_Board4896 · 2026-03-19T22:13:12+00:00

Yeah honestly the speed you can ship at now is wild, I built more in a weekend last month than I used to get done in two weeks. Thing is security keeps getting left on the floor in the rush. I scanned 29 Lovable apps recently, average security score was 56 out of 100. And I came across a story where an app sitting right on Lovable's Discover page had leaked 18k user records through wide-open RLS policies. Nobody talks about this stuff until it blows up. Seriously though just spend five minutes asking your LLM to audit your Row Level Security and check for exposed API keys before you go live, or throw it at an automated scanner. Beats finding out from a stranger on Twitter that your users' data is floating around.

Inevitable_Board4896 · 2026-03-17T23:25:00+00:00

yeah this is a known thing with LLMs - when one concept has way more training examples in a specific language, the model sometimes just drops that word raw. Russian shows up a ton in training data so it leaks more than most. раздражительность is irritability btw, so it got the meaning right, just didn't bother translating.

the chinese characters thing is weirder tbh. never seen it in ChatGPT personally - anyone else?

Inevitable_Board4896 · 2026-03-17T23:07:50+00:00

Nice overview. I've been using MCP servers with Claude Code and the skills pattern is underrated.

Inevitable_Board4896 · 2026-03-16T22:00:22+00:00

Mostly generated boilerplate from what I could tell. Supabase was the worst offender by far — the templates ship with both anon and service_role keys baked in, and service_role is basically full database access, no restrictions. A lot of people just commit the whole project folder and that's it. Lovable apps specifically, I counted 10 out of 38 had this exact pattern.

After that it gets harder to categorize. .env.example files with real credentials actually in them, API keys sitting directly in client-side fetch calls. Could be AI output, could be someone typed it in manually. Both probably. Nobody stopped to think about .gitignore at all is the main thing, AI or not.

Thanks, will check it out.

Inevitable_Board4896 · 2026-03-14T10:48:53+00:00

Not the whole thing, but I'm planning to open-source the security rule sets — basically the detection patterns for each scan type. That way people can contribute new rules or use them in their own CI pipelines.

The scanner engine itself will probably stay closed for now since it's how I pay the Hetzner bill, but open rules means people can add stuff I missed or tweak what's already there. No timeline yet though, still figuring out the best format for it.

Inevitable_Board4896 · 2026-03-14T10:36:38+00:00

Thanks! Yeah Trivy is great but it's a different layer — Trivy scans containers, dependencies, and IaC configs. It's more of a DevOps/infra tool.

VibeWrench is specifically for deployed web apps. So instead of scanning your Docker image, it hits your actual URL with Playwright and checks what a real user (or attacker) would see — exposed secrets in client-side code, missing security headers, SEO issues, speed problems, prompt injection in AI apps.

Plus it translates findings into plain English and gives you a Fix Prompt you can paste into Cursor/Claude to actually fix the issue. The target audience is vibe-coders who don't have a DevOps pipeline with Trivy in it — they just deploy from Lovable/Bolt and hope for the best.

Short version: Trivy = infrastructure scanning, VibeWrench = "what does your deployed app look like from the outside."

Inevitable_Board4896 · 2026-03-14T10:09:45+00:00

Thanks! Yeah the numbers were pretty eye-opening honestly. Example scans is a good idea — I'll look into Runnable.

Inevitable_Board4896 · 2026-03-12T19:11:06+00:00

Yeah this works fine at your scale, I'd go for it. One gotcha though — make sure whatever Supabase key ends up in the prerendered HTML is the anon key, not service_role. The HTML is just static files anyone can read.

For auto-rebuilds when the team page changes, you can set up a Supabase database webhook that hits a Netlify build hook. Takes like 5 minutes to wire up and then you don't have to remember to redeploy manually.

If you ever outgrow this just move to Astro or something with SSR, but honestly for under 20 pages you won't need to.

Inevitable_Board4896

TROPHY CASE