We convince ourselves that because a file is named .secrets and hidden, no one will find it. But your local machine has a backup tool (Time Machine, CrashPlan), a sync tool (Dropbox, iCloud), or a remote debugging agent (Telepresence). That "local" secret becomes global instantly.
The only safe secret is the one that never touches your hard drive as plaintext. Everything else is just a bug waiting to be exploited. Have you found a .secrets file in a public repo? Report it to the owner via Responsible Disclosure. Have you created one by accident today? Run gitleaks now. Your future self will thank you.
COPY .secrets /app/.secrets RUN npm install --production They forget to add .secrets to .dockerignore . They push the image to a public Docker Hub repo. Within four hours, a bot downloads the image, extracts the layer, and drains the crypto wallet associated with the private key stored in that file. A developer uses git add . instead of git add src/ . The .secrets file sitting in the root directory gets committed. They realize the mistake immediately and push a fix. But the secret is already in the Git history. Attackers scan the reflog and old commits. Two weeks later, the production database is ransomed. Case Study 3: The NPM Package Poisoning An open-source maintainer publishes a library. They accidentally include a .secrets file used for local testing. The file contains a test Stripe key. Attackers use that key to verify the developer’s naming pattern, then socially engineer a malicious update to steal real production keys. .secrets
In the world of software development, we are taught to value transparency, clarity, and collaboration. But every engineer knows that to ship a functional product, you must also master the art of hiding things. We hide API keys, database passwords, SSH private keys, and OAuth tokens.
For years, the industry standard was a file named .env . But as microservices exploded and supply chain attacks became the new normal, a new, more controversial player emerged: We convince ourselves that because a file is named
git log --all --full-history -- "*/.secrets" If you find a .secrets file in Git history, changing the key is mandatory . If you cannot change the key (e.g., a hardcoded SSL private key), you must use git filter-branch or BFG Repo-Cleaner to purge it from existence.
You cannot delete the concept of secrets from development—you can only choose where to store them. If you store them in a plaintext file named .secrets in your repository, you are not storing them; you are publishing them to everyone who clones your repo, scrapes your Docker image, or reads your CI logs. The only safe secret is the one that
Rewriting history breaks forks and PRs. Do this only during a scheduled maintenance window. Part 5: The Psychology of .secrets – Why We Keep Doing This Why do developers keep creating .secrets files when we know better?