The Secret Keeper

The incident

The AWS key was committed in 2022, removed in a cleanup in 2023, and still sitting in the git history the whole time — because git never forgets. Someone's cloned laptop, someone's leaked repo, someone's scanner found it. The proof arrived as a 3 a.m. billing alert: cryptocurrency miners, spun up politely within the account's service limits, patient enough to go unnoticed for eleven days.

Why the obvious approach fails

Secrets in code feel contained because the repo feels private — but a repo's audience only ever grows: new hires, contractors, CI systems, laptop backups, and eventually, statistically, someone it shouldn't. Deleting the secret doesn't help; version control preserves it forever, and scanners read history specifically. Environment files improve nothing fundamental — they're unencrypted, copied freely, and shared over Slack the first time onboarding is in a hurry. The real properties needed are central storage with access control, short lifetimes, automatic rotation, and an audit trail of every read — which is a secrets manager, not a convention.

The standard

• +Secrets live only in a dedicated manager (Vault / cloud-native); code and config reference them, never contain them.
• +Credentials are short-lived wherever the platform allows — dynamic database credentials and assumed roles over static keys.
• +Rotation is automated and regular; a rotation that requires human choreography is a rotation that won't happen.
• +Secret-scanning gates every merge and runs against history; a detected secret triggers revocation first, cleanup second.
• +Every secret access is logged — who or what read which secret when is always answerable.

Composes with