Skip to content
All posts

Secrets in public repos are still the fastest breach

1 min readsecrets · git · leaked-credentials · appsec

Of all the ways into a company, a leaked credential in a public repository is the least glamorous and the most reliable. No exploit chain, no timing attack. Someone committed a key, pushed it, and a bot found it before the coffee was cold.

Why it persists

Git remembers everything. Rotating the key in the latest commit does nothing if the old key still sits in history. Developers paste a token to "just test something", forget it, and the deletion commit only hides it from the file view, not from git log. Add a public fork or a mirror and the secret outlives the repo it came from.

What gets leaked

The usual suspects: cloud access keys, database connection strings, third-party API tokens, signing secrets, and the occasional private key. Each one is a different blast radius, but they share a property: they are valid until rotated, and an attacker only needs seconds.

Catching it

NANOTESTING's repository scanning looks for high-signal secret patterns across the default branch and reports them as a finding you can act on, with the file and a redacted sample so you can confirm without re-leaking it. The fix is always the same two steps in this order: rotate the credential immediately, then purge it from history. Rotating without purging leaves the old key live; purging without rotating leaves a window. Do both, and add a pre-commit secret check so the next paste never ships.

Related posts