Secrets
Hygiene.
The Briefing
Somewhere in your organization right now, a production API key is sitting in a Slack DM. An SSH private key is in a developer's Downloads folder. A database connection string with the root password is hard-coded in a configuration file committed to a public GitHub repository six months ago. The developer who committed it has left the company. The key has never been rotated.
Passwords are the security conversation everyone has. Secrets (API keys, access tokens, database credentials, signing certificates) are the security conversation almost no one has.
Secrets are orders of magnitude more dangerous than passwords. A compromised password gives an attacker a user session. A compromised API key gives them a system identity.
The Failure Modes
The Slack DM
A developer pastes a Stripe key into a chat. It is now stored in Slack's servers, indexed in Slack's search, and retained according to Slack's data retention policy. That key now has a lifecycle you do not control.
The Hard-Coded Commit
A developer embeds a secret directly in source code for convenience. Even if they delete it in the next commit, the original commit still exists in the Git history. The secret is permanently recoverable.
Environment Variables
Files like config.yaml or .env are the most common vectors for leakage. Developers often treat them as infrastructure rather than highly sensitive cryptographic material.
The Orphaned Key
An employee generates a service account key for a one-time integration. The key remains active with broad permissions. When the employee leaves, it becomes a persistent backdoor with no owner.
The Cultural Problem
Developers share secrets in Slack because it is fast. They skip the vault because "it's just a staging key." These are acts of friction, not malice.
"The solution is not to lecture developers about security. The solution is to make the secure path the easy path. Security that adds friction fails. Security that removes friction scales."
The Vault-First Protocol
The principle is simple. Secrets are never stored where humans work. They are stored where machines work. Every other location is a leak.
All secrets live in a dedicated secrets manager. The vault is the single source of truth. If a secret is not in the vault, it does not exist in any sanctioned form.
Application code never contains a secret. It contains a reference to a secret. The secret is injected at runtime by the deployment pipeline, not by the developer.
Service accounts follow the same Principle of Least Privilege as human accounts. A key that can do everything is a key that can compromise everything.
Tactical Countermeasures
- › Integrate a secrets detection tool (like GitLeaks or TruffleHog) into your CI/CD pipeline. Every commit must be scanned before the code reaches the repository.
- › Rotate on a schedule and revoke on an event. API keys must rotate quarterly at minimum. When an employee leaves, revoke all keys they touched immediately.
- › Deploy a CLI tool that injects secrets into the local environment with a single command. If retrieving a secret from the vault takes 30 seconds and pasting it in Slack takes 5 seconds, developers will paste.
Operational Calibration
- 01
Can you enumerate every API key, token, and service account credential in your organization right now? If not, you do not know your attack surface.
- 02
When was the last time you rotated your third-party API keys? If the answer is "when we first set them up," you are running a credential that is likely compromised and certainly stale.
- 03
If your most senior engineer left tomorrow, how many secrets would leave with them in their memory or local filesystem? If the answer is not zero, you have a personnel-dependent security posture.