Pipeline security

Secrets in your repos: how credentials leak through CI/CD and how to stop it

Gociux · June 2026 · 6 min read

Hardcoded credentials are the most boring vulnerability class and one of the most reliably exploited. The mechanics are mundane: a developer tests with a real API key, commits, pushes. Maybe the key is removed in the next commit — but git is a history, not a state, and the secret lives on in every clone forever. Attackers know this; automated scanning of exposed repositories for credential patterns is continuous, and freshly leaked cloud keys see abuse within minutes, not days.

Why ".gitignore it" and "we deleted it" both fail

.gitignore prevents future accidents for that path; it does nothing for the config file already committed, the key pasted into a test, or the .env that was renamed. And deleting a leaked secret in a new commit removes it from the working tree while preserving it perfectly in history — visible to anyone with git log -p. Truly removing it requires history rewriting, which is disruptive enough that the practical rule is simpler: a committed secret is a burned secret. Rotate it.

Three layers of scanning, because each one misses

1. Pre-commit, on the developer machine. A hook running a secrets scanner catches the mistake before it enters history at all — the only layer where prevention is still possible. Treat it as a seatbelt, not a guarantee: hooks can be skipped and aren't installed everywhere.
2. In the pipeline, on every push. The enforcement layer: a scanning step that fails the build on a new detection. This is also where findings should flow into your SIEM and ticketing — a secret detection is a security event, not a linter warning.
3. Periodic full-history scans. New detection patterns and rotated rule sets find old sins. Run the scanner across complete history on a schedule; the first run on a mature codebase is always educational.

Modern scanners combine pattern matching (known key formats are highly recognizable) with entropy analysis for the generic high-randomness strings. Expect false positives early; tune with allowlists rather than turning detectors off.

The first hour after a real leak

• Rotate first. Before cleanup, before the retro — revoke and reissue the credential. Everything else is secondary.
• Audit usage of the leaked credential through provider logs for the entire exposure window — from commit time, not discovery time. Assume it was found.
• Then decide on history rewriting for private repos (often not worth the disruption once rotated) versus public exposure (rewrite, and assume cached copies exist anyway).
• Feed the lesson back: what pattern was it, why did no layer catch it, which detector or hook closes that path.