Scenario 2 of 2 · Proactive audit · The Vibe Coding Security Top 10 Gotchas
SpeedBump — find it before it ships
Same app, same company — but this time you're reviewing Loopline's code and config before it goes live, to find the gotchas that made FastLane possible.
Open a terminal. cd ~/fastlane. claude. Paste only the prompt
text below.
~20 min. CORE phases (1, 3, 5) tell the full story. DEEP phases (2, 4) are for a quiet queue or to run later. No agent? Terminal fallback commands are at the bottom.
Full pre-ship audit
Paste this, then Enter:
You will see: findings across four areas — database, application, supply chain, and secrets — each with its own correlation label.
Database: RLS gaps on two tables. Application: IDOR, CORS wildcard, an exposed debug route, and general OWASP-flavored defects. Supply chain: a slopsquatted package and an auto-trusted MCP config. Secrets: the same service-role key, twice.
Reveal the answer
Database: customers table has no RLS at all;
tickets table's RLS policy is USING (true) — functionally the
same gap. Application: IDOR on /api/tickets/[id], wildcard
CORS, an unauthenticated /api/debug/seed route, plus reflected XSS and
missing login rate-limiting. Supply chain: a slopsquatted npm package
referenced in an open PR, and a starter template's MCP config that auto-connects to an
unvetted remote server. Secrets: the same Supabase service-role key
recoverable both from the client bundle and from git history.
Rank by blast radius
Same chat:
You will see: reasoning about which matters most — the database gap that needs no exploit at all, versus everything else.
A defended ordering. Reasonable top pick: the database/RLS gap, because it requires no clever exploit — just knowing (or leaking) any working key. The point is the reasoning, not one "right" order.
Reveal the answer
Defensible top pick = database/RLS: with RLS off, any valid key (anon or service-role) reads everything — no clever exploit needed, which is what makes it the highest-severity, lowest-effort path. Secrets exposure = the actual delivery mechanism here (a leaked key needs somewhere permissive to point at). Application-layer (IDOR/CORS) = a second, independent path to similar data. Supply chain = highest potential damage (a compromised dependency runs code) but, in this case, never actually reached production.
Correlate with the breach
Same chat:
You will see: findings split three ways — exploited, probed, and one that never shipped at all. Not all the same.
RLS + secrets exposure = exploited (the actual data pull). IDOR + the debug route = probed only. The slopsquatted package = never exploited — it never shipped.
Reveal the answer
Exploited: the RLS gaps and the leaked service-role key — together,
the direct cause of the 1,842-row customers pull. Probed, not
confirmed exploited: the IDOR sweep (5 IDs across 3 orgs, no separate large-scale
exfil confirmed via this path) and the /api/debug/seed hit (one request, no
evidence of damaging use). Never exploited — never shipped: the
slopsquatted react-csv-parser-pro package, which stayed on an unmerged PR
branch the entire time.
Check the agent's call
Same chat:
You will see: the package is real and malicious-adjacent, but a merge-status check settles whether it ever mattered.
Checking PR #47's merge status (OPEN, never merged) and confirming
package.json on main has no such dependency — not just reading
the AI chat log or the branch diff in isolation.
Reveal the answer
Never running in production. pr-branch-diff.txt shows PR #47 is still
open; package.json (main branch) has no such dependency. The package itself
is a genuine slopsquatting attempt — registered one day after an AI session referenced
the hallucinated name — but this specific instance never reached Loopline's shipped
code. Confirming "exposed" vs. "exploited" here requires checking merge status, not just
the existence of the suggestion — the same nuance FastLane's Phase 3 tests, from the
audit side this time.
Prioritized remediation
Same chat:
You will see: RLS first (systemic, breaks the chain), then secret rotation, then the application-layer gaps, with the never-shipped package and dev-tooling risk flagged as real-but-latent.
Ordered by real risk: RLS first (closes the systemic gap), then rotate the leaked key and purge git history, then fix the IDOR/CORS/debug-route trio, then the two latent findings — never treating "never shipped" the same as "not worth fixing."
Reveal the answer
1) Enable correctly-scoped RLS on every table (gotchas #1, #5) —
the systemic fix. 2) Rotate the service-role key and rewrite git history
to purge the old .env commit (gotchas #2, #8). 3) Add the
missing org_id check, scope CORS to known origins, and remove the debug
route (gotchas #4, #7, #9). 4) Verify AI-suggested packages against the
registry before merging, going forward (gotcha #3 — even though this instance was
caught). 5) Review any cloned starter template's agent/MCP config before
opening it (gotcha #6) — latent, but still worth doing.
Explore without spoiling it
jq '.findings[].correlation_label' speedbump/application-security-audit.json
jq '.findings[].correlation_label' speedbump/supply-chain-audit.json
Terminal fallbacks (no agent)
jq -r '.findings[] | select(.correlation_label=="exploited") | .id' speedbump/*.json
grep -B1 "never reached" ../app/pr-branch-diff.txt
Authorized & lawful use only. All data is synthetic and self-contained; no live systems are touched. "Loopline" is a fictional company. Promotes the open-source Anthropic Cybersecurity Skills library (Apache-2.0); not affiliated with Anthropic PBC.