Protect source and CI

Keep secrets out of source

Prevent, detect, and respond to committed credentials without treating history rewriting as a substitute for revocation.

Git remembers. Once a secret enters a repository, assume every clone and automation path may have copied it.

Prevention starts with boring hygiene. Keep real values in files Git never sees, and commit an example file with the shape but not the values:

# .gitignore
.env
.env.local
# .env.example — committed, no real values
DATABASE_URL=
RESEND_API_KEY=

Real secrets live in a secret manager or in your platform’s environment configuration, injected at runtime. The example file documents what the app needs without exposing anything.

Detect before and after the commit

Add a scanner to catch mistakes before they land. gitleaks scans working trees and full history:

gitleaks detect --source . --verbose
# Finding: AWS access key
# Secret: AKIA...
# File: config/deploy.js  Commit: 4f2a91c

A non-zero exit code means it found something; the output tells you the file, the rule that matched, and the commit. Run it as a pre-commit hook and in CI. On GitHub, also enable secret scanning and push protection so the platform blocks known credential formats at push time.

Detection has a cost: it can flag harmless test strings. Pair it with a reviewed way to mark false positives — gitleaks reads fingerprints from a .gitleaksignore file — so developers never respond by disabling scanning globally.

Revoke first, clean up second

Here is the mistake that keeps repeating. A cloud key is committed, removed in the next commit, and assumed safe. A fork, CI log, or local clone may already contain it, so rewriting Git history cannot invalidate the credential.

Treat a committed secret as leaked from the moment it was pushed. Revoke or rotate it first. Then decide whether rewriting history is worth the coordination cost — for a public repository it usually is, to stop future scrapers, but it is cleanup, not containment.

Commit a scanner-approved fake credential to a disposable repository and save the alert evidence. Follow the response runbook through revocation simulation, history search, and affected-system inventory. Then test a harmless look-alike value and document how a developer can resolve the false positive without disabling scanning globally.

Lesson completed

Take this course offline

Get every free book, course edition, and software download.

Get the download library →