Secret scanning
Sixteen named credential patterns across bundles, diffs, commit messages and a bounded walk of git history.
Committed credentials are the most common way a small product gets drained, so they are looked for in four places: your public JavaScript, every push, commit messages, and a bounded slice of git history taken once after inventory.
What can be named
OpenAI, Anthropic, Stripe (secret, test and publishable), AWS access key ids, GitHub tokens, Slack tokens, SendGrid, Resend, Twilio, Google API keys, Supabase service role and anon JWTs, private key blocks and database URLs. A named key comes with what someone could do with it.
What cannot
Anything shaped like a credential but unrecognized is still raised, at a lower severity and confidence, with the reason stated: the name says secret, but we cannot tell from source whether the value is live.
Deleting the line or rewriting history does not help on its own - the old value is already out. Rotate the key, then clean up. The finding resolves when the literal is gone, and says explicitly that rotation is something only you can confirm.
Questions
Is the secret itself stored anywhere?
No. It is masked at detection. Enough is kept to identify which key it is and where it lives; the value never reaches our database and never reaches a model.
How far back does the history scan go?
A bounded slice, taken once after the first inventory, and recorded as scanned-through so it is never re-read from scratch. It is deliberately not the whole history of a ten-year repository.
A test fixture keeps being reported. What now?
Give it an obviously inert value and it stops being reported. If it must look real, dismiss the finding as a false positive with a reason - that is recorded and it will not come back.
Something here wrong, missing or out of date? Tell us and we will fix the page.