▣ FastLane / SpeedBump

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.

Setup (if you closed the terminal)

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.

Phase 1 Core

Full pre-ship audit

Paste this, then Enter:

Using your application-security, database-security, and supply-chain skills, audit every report in speedbump/: the database security audit, application security audit, supply chain audit, and secrets audit. List the skills you used and summarize each area's findings.

You will see: findings across four areas — database, application, supply chain, and secrets — each with its own correlation label.

Checkpoint — on track when you see

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.

Phase 2 Deep

Rank by blast radius

Same chat:

Of those findings, which single one is most dangerous, and why? Rank all four areas by how much damage each enables on its own.

You will see: reasoning about which matters most — the database gap that needs no exploit at all, versus everything else.

Checkpoint — on track when you see

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.

Phase 3 Core

Correlate with the breach

Same chat:

Now look at ../app/access-log.txt and ../app/pr-branch-diff.txt: for each speedbump finding, did the attacker EXPLOIT it, only PROBE it, or was it never actually used at all? Show me the evidence for each.

You will see: findings split three ways — exploited, probed, and one that never shipped at all. Not all the same.

Checkpoint — on track when you see

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.

Phase 4 Deep

Check the agent's call

Same chat:

Double-check the supply-chain finding: was the slopsquatted package actually running in Loopline's production code, or does the evidence only show it was suggested? Show the specific check you'd run to confirm either way.

You will see: the package is real and malicious-adjacent, but a merge-status check settles whether it ever mattered.

Checkpoint — on track when you see

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.

Phase 5 Core

Prioritized remediation

Same chat:

Give me a prioritized fix list: what to change FIRST to close the actual breach path, versus what to fix because it's a real risk even though it wasn't confirmed as used. For each fix, name which Top 10 gotcha it addresses.

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.

Checkpoint — on track when you see

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.

← Back to Scenario 1: FastLane