Why clean repo scans don’t clear deployed apps
Repo scanners answer “is the source clean?” Deployed scanners answer “what ships?” Both matter; neither substitutes.
What Repository-class tools (pre-commit hooks, push protection, historical scanners) does well
they intercept credentials as code moves — cheap, early, integrated.
- Sees history and diffs across every branch.
- Blocks at the cheapest moment (pre-push).
What Runtime/bundle inspection of served artifacts adds
it sees substitution output: prefixed literals, hydration payloads, agent edits post-review.
- Observes the exact bytes visitors download.
- Catches transformations unique to bundling.
Where each one is blind
Each layer’s blindness is structural: source tools never see built output; artifact tools never see unmerged branches.
- Anything produced after checkout — bundles, maps, hydration blobs.
- Code behind logins without paste-mode input.
- Runtime-assembled keys (no JS parser exists in this class).
Using them together
Keep repo-side interception; add deploy-side verification so the artifact gets equal scrutiny. Monitoring catches reintroductions neither static layer sees.
Decision rule
- Need prevention before merge? Repo-side.
- Need proof about production? Deployed-side.
Neither answer replaces the other; they watch different files at different moments. The mistake is believing one report covers both.
Why this failure class persists
It helps to name the economics honestly. Fixing this class of leak costs minutes when caught at deploy time and days when caught at invoice time, because by then the credential has been harvested, validated, resold or drained — often all four. Detection latency is the entire game, which is why the monitoring half of KeyDrift exists alongside the scanning half.
How KeyDrift reports this exact finding
When KeyDrift finds this on your deployment, the report shows a masked value (first 8 and last 4 characters only), a salted fingerprint for tracking, the exact chunk filename carrying it, and a severity with written rationale. Public-by-design neighbours — anon keys, publishable keys, Firebase web constants — appear as informational context rather than noise, because knowing what should be there is what makes the real findings credible.
Manual check, step by step
A five-minute version you can run anywhere: view-source on the landing page, copy every src= script URL, fetch each and search the results for eyJ. It misses manifest-only chunks and streamed payloads — which is precisely the gap between "I checked" and "it is clean" — but it catches the loud majority and builds the pattern-recognition that makes scanner output legible.
Close the loop with monitoring
Monitoring closes the loop that one-time verification leaves open. A scheduled scan refetches everything, diffs against history, and fires only on transitions: created, regressed, resolved. Regression alerts matter most here — they fire when a previously fixed finding returns, which in agent-era codebases is less a possibility than a schedule.
What the plans change
- Free $0 — 1 project · daily scans · email alerts · findings always visible.
- Indie $29/mo — 3 projects · hourly · Slack added · 80 chunks per scan.
- Team $89/mo — 15 projects · every 15 minutes · Discord + webhooks · 150 chunks.
- Growth — from $249/mo, quoted display-only until checkout ships.
The constant across every tier: plans limit how much is watched, never what a scan found. Visibility is structural, not promotional — asserted by tests over the entitlements model itself.
Common questions
Is Repository-class tools (pre-commit hooks, push protection, historical scanners) bad practice then?
No — the page credits exactly where it wins. Blind spots are structural, not sloppy.
Bottom line?
Need proof about production? Deployed-side.
Run a free scan at keydrift.dev/scan — paste a URL or the bundle source itself, no account. Findings arrive masked, with the exact chunk they live in.