Secrets Scanning

Secrets scanning sweeps code, commits, pull requests and configuration files looking for credentials: API keys, access tokens, passwords, private keys and connection strings.

It is the cheapest check in the pipeline and protects against one of the most common leaks: a credential committed by mistake.

The first layer is pattern matching: token formats are recognizable. AWS keys start with AKIA, Stripe API tokens with sk_live_, private keys with -----BEGIN. A well-made regex catches most of them.

The second layer is entropy analysis, for formats nobody documented: strings that look highly random (many distinct characters, no word pattern) near suspicious names like api_key, secret or password. It is what catches homegrown internal service keys.

The third layer, when available, is active verification: the tool tests whether the credential found is valid, turning a 'potential finding' into a 'confirmed incident'.

The classic scenario in three acts. Act one: someone pastes a production key straight into the code. It works, the test passes, life goes on.

Seconds after the push, automated third-party scrapers (and GitHub's own secret scanning) are already testing the key. Deleting the commit does not fix it: the secret remains in git history, in forks and in caches. A typical local scanner report:

The only correct response is to revoke and rotate the credential immediately, before cleaning the repository and before discussing process. No history cleanup is fast enough to compete with a bot that tests the key every second.

The structural prevention is to take secrets out of the code for good: managers like HashiCorp Vault, AWS Secrets Manager or Doppler inject the credential at runtime and allow rotation without a deploy.