Start with an inventory, not a platform
Small teams rarely lack tools for secrets; they lack a clear picture of where their secrets currently live. Before adopting anything, list every credential the team relies on and where copies exist: cloud consoles, repositories, laptops, CI settings, chat threads, and the shared document nobody admits to. For each one, note who can access it and how you'd rotate it.
The inventory usually surfaces the urgent fixes on its own, such as a production token in an old commit or a credential pasted into an onboarding document.
Three habits that cover most of the risk
1. Keep secrets out of source control. Use git-ignored environment files locally, and detect secrets before code is pushed. The OWASP Secrets Management Cheat Sheet recommends enabling detection at the developer level, such as a pre-commit hook, and GitHub's push protection blocks pushes that contain recognised secrets.
2. Centralise runtime secrets. Use the secret store your cloud or deployment platform already provides rather than a homegrown scheme, and give each service access only to the secrets it needs. OWASP recommends scoping access so that no single identity can read every secret, and using dynamic, short-lived secrets where you can.
3. Fix the human path. A lot of avoidable exposure happens when credentials move between people: onboarding, incidents, contractors. Give the team one standard way to do it, such as an encrypted link that expires, and make chat and email the exception that needs a reason.
Simple team rules for sharing
Small teams move faster than formal policy. A short set of defaults, written down where everyone can find them, does more than a long policy nobody reads:
| Situation | Default |
|---|---|
| Sending a password or key to one person | A one-time EnvShare link: one read, expiring within a day |
| A few people need the same value briefly | A read limit equal to the number of people, and the shortest workable expiry |
| Anyone needs it for longer than a week | It goes in the password manager or secret store, not a link |
| Someone outside the team needs to send you a secret | A secret request |
| A secret was pasted into chat, email or a ticket | Rotate it, then delete the message |
| Someone leaves | Rotate every shared secret they could see |
Make exceptions explicit. If someone has to break a rule during an incident, they say so, and the secret is rotated afterwards.
Rotation without drama
Rotation is the safety net for every other mistake, so make it routine:
- Know how to rotate each secret in your inventory before you need to.
- Prefer setups that allow overlap, where a new key works before the old one is revoked, so rotation doesn't cause downtime.
- Rotate on triggers: departures, suspected exposure, the end of a contractor engagement. OWASP's guidance is that exposed secrets should be revoked immediately.
When to invest in more
A dedicated secrets platform starts to pay off when you have several environments, several services sharing credentials, or compliance requirements that call for audit logs. Until then, the three habits and the team rules above get you most of the way, and they make the move to a bigger system easier when it comes.
For the handoff itself, see how to send API keys safely and how to share .env files securely.