Tokens should rotate themselves
The CI token created two years ago that everyone is afraid to touch is a breach waiting for a calendar invite. Rotation should be a property of the system, not a heroic act.
Somewhere in your infrastructure is a deploy token created by someone who has since left, scoped broader than anyone remembers, that nothing dares touch because the pipeline might break. Every company has one. Some have fifty.
Why long-lived secrets fail
A token that never expires only needs to leak once — a CI log, a laptop backup, a screenshot in a ticket — and it works forever, from anywhere, looking exactly like legitimate automation. The longer it lives, the more places it's been copied, and the less anyone remembers what it was for.
What good looks like
- Prefer short-lived credentials. OIDC federation from your CI to your cloud provider means no stored cloud keys at all — the pipeline gets a token that expires in minutes.
- Rotate on a schedule, automatically. A secret that rotates every six hours has a worst-case leak window of six hours. Manual rotation always slips; automation doesn't.
- Scope tightly. A deploy token that can only deploy to one service limits the blast radius when — not if — one leaks.
- Know what you have. You cannot rotate a secret nobody has inventoried. The audit comes first.
The reason rotation projects stall is fear: rotate the token, break the build, own the outage. The fix is to make rotation routine and reversible, so it stops being an event. BlackPing's secrets rotation does exactly that — tokens rotate themselves on a schedule, and if something breaks, the previous value works while you fix it.