CI secret scanning vs deployed-app scanning — different files, different answers
Push protection and CI scanners do real work on source. Build-time substitution happens after they finish. Compare honestly.
What CI & repository scanning does well
Source-side scanning intercepts credentials at the earliest controllable moment and integrates where developers already work.
- Interception before merge — cheapest possible fix point.
- Zero production infrastructure; runs where code already flows.
- Mature ecosystem: push protection, historical scans, org policy.
What Deployed-bundle scanning adds
Deployment scanning inspects the artifact strangers actually receive, including transformations no source scanner can predict.
- Catches build-time substitution (NEXT_PUBLIC_/VITE_) invisible to source.
- Sees agent-written client calls and streamed hydration payloads.
- Drift across deploys: reintroductions alert as regressions.
Where each one is blind
Each layer’s blindness is structural, not fixable by effort:
- Anything produced after checkout — bundles, maps, hydration blobs.
- Preview deployments built from branches CI never scanned as artifacts.
- Code behind logins without paste-mode input.
- Runtime-assembled keys (no JS parser exists in this class).
Using them together
Keep CI as the interception layer it excels at; add deploy-side verification so the artifact gets the same scrutiny as the source. Monitoring closes the reintroduction gap neither static layer sees.
Decision rule
- If your goal is stopping commits containing secrets → CI/push protection.
- If your goal is proving visitors cannot retrieve keys → deployed scanning.
- If you need both guarantees → both layers, scheduled.
Neither answer replaces the other; they watch different files at different moments. The mistake is believing one report covers both.
The bigger picture
Zoom out and the pattern is bigger than one repo. AI-assisted output has outgrown review capacity everywhere at once, which means thousands of teams are making the same reasonable-looking tradeoffs in the same week. Nobody using modern tooling is uniquely exposed. The failure mode documented above is the modal outcome of velocity without verification, not evidence of carelessness.
How KeyDrift reports this exact finding
Report anatomy matters during incidents, so it is worth reading once calmly: masked string (never the live value — it ceases to exist outside the detection engine), salted fingerprint (trackable within your workspace, useless to strangers), chunk path (your starting point for a "git log -S" hunt), disposition (secret versus public-by-design), confidence (matches below 0.5 never reach the page at all).
Manual check, step by step
The full manual drill, for readers who want zero dependence on any tool: open the deployed site in a private window; launch DevTools → Sources; use Search-all-files (Ctrl/Cmd+Shift+F) for eyJ; then repeat for the other marker families — eyJ, sk_live_, sk-proj-, AKIA, postgres, BEGIN PRIVATE KEY. Decode anything JWT-shaped before reacting, and classify public-by-design formats as expected guests rather than intruders.
Close the loop with monitoring
If you take one operational step from this page, make it this: put the URL under continuous monitoring (free tier covers one project daily). The first scan tells you whether you have a problem today; the schedule tells you whether the problem comes back next month after someone re-adds the convenient line.
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
Doesn’t good CI make deploy scanning redundant?
No — they inspect disjoint file sets. Green pipelines have shipped leaking bundles repeatedly; that is the entire category’s reason to exist.
Where do pentests fit?
Depth-on-schedule vs breadth-per-deploy; see the pentest comparison page.
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.