Part 5 of 7 · 2 min read
Catching leaks, and working like a professional
A scanner that stops a key before it is committed, what teams add, and how this comes up in interviews.
The best time to catch a leaked key is before it is committed. secret_scan.py in the example project reads files, looks for text shaped like a key, and exits with an error if it finds one. Here it is run on one file that contains a key-like value and one clean file:
$ python secret_scan.py leaky.py clean.py
leaky.py: possible api key (sk-...)
leaky.py: possible assigned secret
$ echo $?
1
$ python secret_scan.py clean.py
$ echo $?
0
An exit code of 1 means "found something" and 0 means "clean". That is what lets another tool, such as Git, use it as a gate: for example python secret_scan.py $(git diff --cached --name-only) scans only the files you are about to commit. You can run it as a Git pre-commit hook (a script that Git runs before each commit, .git/hooks/pre-commit) or, better, through the pre-commit tool, and again in CI (module 7).
What you will use daily at work
| Practice | What it looks like |
|---|---|
| A dedicated scanner | Teams run tools such as gitleaks or detect-secrets in pre-commit and CI instead of a hand-written scanner. |
| Push protection | GitHub and similar hosts can refuse a push that contains a known key format. Turn it on. |
| A secret manager | In production, keys come from a secret manager (a cloud service or your platform's secret store), not from files. |
| Separate keys per environment | Different keys for development, test and production, each with its own spending cap. |
| Rotation on a schedule | Keys are replaced regularly, and the process is practised so that it is quick under pressure. |
| Log aggregation | Logs from every server go to one searchable place, where the request ID ties a run together. |
| Alerts on spend and errors | A sudden jump in token use or error rate sends a message to a person. |
Draft: to be checked against the current documentation of gitleaks, detect-secrets and your chosen hosting platform before this page goes live.
Interview angle
Answer in your head first, then open it.
How do you manage API keys in a project?
Environment variables loaded into a typed settings object at start-up; .env ignored by Git with a committed .env.example; encrypted secrets in CI; a secret manager in production; separate, least-privilege keys per environment; rotation and spending caps.
Why structured logs?
They can be searched, filtered and aggregated by field, so you can find all slow requests or all failures of one tool.
A key was pushed to a public repository. What do you do?
Revoke it first, replace it, review the provider's usage logs, then clean history and add a scanner.
What does "fail fast" mean for configuration?
Check all required settings at start-up, so a missing value stops the program immediately with a clear message.
What is a good request ID for?
Every log line from one run carries it, so you can reconstruct that run.