Secrets
A key, a token, a password, a cookie that still works: anything that lets a holder in. Where you put it is the control. Git and chat are how it leaks.
First principles
A secret is any value that grants access. The SSH private key. The TLS private key. The API token in a CI variable. The mailbox password. The cloud access key. The session cookie that has not expired. If holding the string is enough to act as someone, it is a secret. Classify by blast radius, not by how the vendor labelled the field.
Where it may live
On the disk of the machine that needs it, with permissions that exclude everyone else. In a password manager or a vault, with an identity in front of it and a log behind it. Those are the two honest places.
Git is a copy that outlives the repo you think you control — clones, forks, backups, CI caches. Chat is a screenshot waiting to happen, plus search, plus retention you do not set. Tickets, wikis, and runbooks are chat with a longer memory. None of those are a vault.
Cyberstack house rule
If a value opens a system we run, it does not go in git, it does not go in chat, and it does not go in a screenshot. It lives in a password manager or on the host that must use it. Onboarding a person means an identity and a vault, not a forwarded message. If it leaked — including 'only internally' — rotate it. Then look for use of the old value. Rotation without hunting is optimism.
What an admin actually does
- Inventory the secrets that open production: cloud, mail, DNS, CI, backups, identity. An owner per row.
- Move standing secrets out of repos. Use the platform's secret store or a vault. Rotate anything that was ever committed.
- CI gets its own identities, scoped, short-lived where the cloud allows it. No human's cloud key in a pipeline.
- When someone leaves, rotate what they could have copied. See Offboarding.
Informed by ASD's ACSC — ISM. Wording is ours.