Secretus logoSecretus

The five places secrets go to leak: .env files, CI logs, chat, tickets, and code

·7 min read

Follow enough incident reports and a boring truth emerges: secrets rarely leak from vaults. They leak from the five ordinary places where copies accumulate while nobody's looking. This month alone, public reporting has described stolen SSH keys and access tokens sitting in source repositories, credentials bought off forums that still worked, and MFA seed files lifted from network appliances. Different headlines, same root cause: a secret at rest in a place nobody was guarding.

Here's the field guide, ranked roughly by how often each shows up.

1. Code and config: the key ring nobody meant to build

Nobody decides to store credentials in Git. It accrues: a connection string committed "just for the demo", a deploy key in a README, an .env that slipped past .gitignore. Deleting the file later doesn't help — Git history remembers, and secret scanners (both the defenders' and the attackers') read history, not just the latest commit. The fix is structural, not heroic: scanners in CI that fail the build (gitleaks, trufflehog, GitHub secret scanning), short-lived credentials that make an old leak worthless, and cloud identity federation so most keys don't need to exist at all.

2. CI/CD logs and artifacts: the echo chamber

Build pipelines are handed the most powerful credentials in the company, then asked to print debugging output. One echo, one verbose flag, one crash dump, and a token lands in a log that dozens of people and several integrations can read. Masking helps but breaks on transformations (base64, JSON-escaped, split across lines). Treat build logs as semi-public: scope CI credentials tightly, expire them in minutes via OIDC federation instead of storing long-lived secrets, and audit what your pipeline prints.

3. Chat: the archive that feels like a hallway

Chat feels ephemeral — that's the trap. Every "here's the admin password 🙏" becomes a permanently searchable record, replicated to every device and export. An attacker who lands one account doesn't read messages; they search password, apikey, -----BEGIN. The countermeasure is a habit, not a product: credentials never travel in message bodies. Send a link that expires and burns after one read, so the archive holds a dead link instead of a working key.

4. Tickets and wikis: the institutional memory problem

Support tickets, runbooks and onboarding wikis collect credentials because they're where people ask for access and write down "how to get in". Unlike chat, they're designed to be durable and broadly readable — which makes them the best-indexed credential store an intruder could ask for. Same rule as chat, plus one: when a credential must be referenced in documentation, reference where to obtain it (the vault path, the request process), never the value.

5. Inboxes: the oldest archive of all

Email is where third parties send you credentials — and where they stay, through years of forwarding rules, delegated access, and the occasional mailbox compromise. You can't always control what others send you; you can control the half-life: move received credentials into a manager immediately, delete the email, and rotate anything that arrived in plaintext, because you have no idea how many hops it took.

The common mechanics

All five share the same physics. Copies accumulate because pasting a value is easier than referencing it. Retention is unbounded because nothing in these systems expires by default. And discovery is trivial because all of them are searchable — for you and for whoever gets in. Flip each property and you get the defensive posture: fewer copies (reference, don't paste), bounded lifetimes (short-lived credentials, expiring shares), and nothing worth searching for (dead links instead of live values).

None of this requires a security team. It requires deciding that a secret at rest in a log, a thread, a ticket, or a repo is a bug — and giving people a way to share one that doesn't create a permanent copy: a channel where the secret expires, can be read exactly once, and confirms it was delivered. Make the safe path the lazy path, and the five places above stay empty.

Share a secret the safe way

End-to-end encrypted, one-time links — free, no account needed.

Try Secretus