A secret is anything that proves identity to a machine: API keys, database passwords, tokens, private keys, signing certificates. They are small strings with large power, and they leak in unglamorous ways. A key pasted into a config file. A token committed to a repository “just for now.” A password shared in a chat to unblock a colleague.

The goal is not perfection. It is to make the safe path the easy path, and to be ready when a secret escapes anyway.

Where Secrets Usually Leak

In practice, leaks come from a short list of places:

• Source code and commit history, including deleted files that remain in earlier commits
• Configuration files copied between environments
• Container images with credentials baked in at build time
• Build logs that print environment variables
• Chat messages, tickets and shared documents
• Laptops, where local files hold long-lived keys
• Client-side code, where anything shipped to the browser is visible to users

That last one deserves emphasis. A key placed in front-end code is not secret, regardless of how it is obfuscated. If a service must be called with a privileged key, the call belongs on a server you control.

The Core Rules

1. Never commit secrets. Use ignore files, pre-commit checks and repository scanning to catch mistakes.
2. Separate secrets from code. Code describes behavior; a secrets store or runtime injection supplies the values.
3. Scope tightly. Each key should do only what its job needs, for one application and one environment.
4. Prefer short-lived credentials. Identities that receive temporary tokens at runtime beat static keys sitting on disk.
5. Rotate on a schedule and on suspicion. Rotation should be routine enough that it is not frightening.
6. Make every secret traceable. Know who owns it and where it is used.

Choosing Where Secrets Live

Different approaches suit different maturity levels.

Approach	Good for	Watch out for
Environment variables injected at deploy time	Simple apps, a first step up from hardcoding	Leaking via logs, crash dumps or debug endpoints
Cloud provider secrets manager	Workloads already on that provider	Over-broad access policies on the store itself
Dedicated secrets platform	Multi-cloud or larger teams	Operational overhead, availability dependency
Workload identity (no stored key)	Services that can use provider-issued temporary credentials	Needs correct role setup and per-provider detail
Encrypted files in a repository	Small teams wanting versioned config	Key management for the encryption key itself

Details differ by platform, so check your provider’s current documentation before designing. Whichever you use, protect the store with the same care: strong authentication for humans, narrow policies for applications, and audit logging for every read.

A Hypothetical Example

A small team has a payment-related API key in a configuration file in the repository. It works, and everyone on the team has seen it. When a contractor leaves, nobody is sure what they still hold.

A sensible migration looks like this. First, create a new key with narrower permissions and store it in the team’s secrets manager. Second, change the application to read the key at startup rather than from the file. Third, deploy and confirm the new key works. Fourth, revoke the old key at the issuer, not merely delete it from the repository. Finally, add scanning so the same mistake gets flagged on the next commit.

Order matters. Deleting the old value from the code does nothing while the key remains valid and sits in history.

If a Secret Leaks

Assume that anything pushed to a public place was copied within minutes. Respond in this order:

1. Revoke or rotate immediately. Don’t wait to investigate first. Invalidating the credential closes the door.
2. Check usage logs. Look at the issuing service’s activity for the key between exposure and revocation.
3. Assess scope. What could the key reach, and was any of it touched?
4. Clean up history if appropriate. Rewriting repository history can reduce future exposure but does not undo copies already made. Never treat it as a substitute for rotation.
5. Fix the cause. Why was it possible to commit it? Add the missing guardrail.

If personal data may have been accessed, notification duties can apply. These vary by jurisdiction, so involve legal or compliance advisors promptly.

Habits That Keep This Manageable

• Keep a simple register of secrets: name, owner, purpose, location, last rotation.
• Use different credentials per environment so a development leak can’t touch production.
• Give humans individual accounts instead of sharing one key.
• Turn on secret scanning in your code hosting platform if it is offered.
• Review the secrets store’s access policy during every quarterly access review.

Frequently Asked Questions

Is a private repository safe enough for secrets? Not really. Private repositories get cloned, forked, shared with contractors and occasionally made public by accident. Treat repository contents as widely readable.

How often should we rotate keys? Often enough that rotation is a practiced routine, and always after suspected exposure or when someone with access leaves. The right interval depends on sensitivity and your tooling.

Are environment variables secure? They are better than hardcoding, but they can appear in logs, process listings and diagnostic output. Use them carefully or prefer a secrets manager.

What is the difference between a secret and a configuration value? If exposure would let someone act as your system or read protected data, it is a secret. Everything else, such as a feature flag or a region name, is ordinary configuration.

Can we just encrypt the secrets in our code? Only if the decryption key is managed securely elsewhere. Otherwise you have moved the problem, not solved it.

Next Step

Run a secret scanner against your main repository’s full history this week and list every hit. For each live credential you find, rotate it first and clean up afterwards.