Table of Contents
The advisory arrives midweek. It ends the way they all do: rotate all your secrets.
This week it came from several directions at once. A poisoned LiteLLM release ran a credential stealer every time Python started, in every environment it was installed in, whether or not anything used it. Separately, Railway told all its users to revoke and rotate every key. And OpenCode reported customer API keys stolen.
The pattern isn’t new. In March, an earlier LiteLLM compromise pulled CI secrets from roughly 2,500 organizations.
Different doors. The same instruction.
“Rotate everything” is the only instruction anyone can give
The advice is reasonable. Exposure is easy to assume: everything the process could read. So everything gets rotated. The hard part is doing it safely, when nobody knows who uses each secret.
The hunt begins: every copy of every key, in every vault, config file and pipeline. Every service that reads it. Then the change, everywhere at once. Miss one consumer, and revoking the old key takes it down.
Meanwhile, the clock is not yours. In this week’s LiteLLM incident, attackers were testing stolen cloud keys the same day. A careful rotation takes days.
Mapping who uses each secret is a hard problem of its own, and runtime visibility changes it. That was the subject of our last post. This post asks why there is a long-lived secret to steal at all.
Workload identity works only where the other side trusts it
The industry knows the better answer: workload identity. A service proves what it is, instead of presenting something it holds. The platform vouches for it, and it gets a token that expires in minutes. The major clouds have worked this way for years. Workload identity federation extends it beyond them: OpenAI, Anthropic, Snowflake and Databricks now accept those identities too. Where it is available, use it.
But most systems don’t accept it. A SaaS vendor, a database, a legacy internal API, a partner’s endpoint: few accept a federated token. There are hundreds of SaaS apps, and waiting for all of them is not a plan.
Your side can prove who it is. The other side still wants a secret.
So make every secret disposable
If those systems will keep asking for secrets, and some will be stolen, the goal changes: make a stolen one worth little, and recovering from it routine.
A better vault won’t get you there. It keeps a long-lived secret safer, but still long-lived. Applications fetch it and hold it, and copies spread until there are many sources of truth. Access rules per vault path are hard to keep tight, so a workload can usually reach secrets it never uses, and one compromised workload exposes all of them.
A disposable secret needs five properties:
- Short-lived. It expires soon after it is issued, so an attacker’s window is short.
- Scoped to need. It grants only what the workload actually uses, so a stolen copy reaches little.
- One per workload. When one leaks, you know whose it was, and replacing it touches nothing else.
- Owned by the system, not a person. Rotation happens because policy says so, not because someone remembered.
- No code changes. Applications receive it the way they already read secrets.
Hush Access Manager
This is what we built Hush Access Manager to do.
It bridges the two sides. On yours, access follows identity: a policy grants a workload access to a resource because of what it is, the way an IAM role does in the cloud. On the other side, the target still gets what it expects, a credential. But it is a disposable one, minted by Hush for that workload alone, scoped to its policy and short-lived. The workload never holds a long-lived secret, and nobody has to own one.
It works for the systems that never adopted workload identity: databases, SaaS, APIs and cross-cloud resources. Where a target does support federation, Hush provisions that instead.
Under the hood, it identifies workloads with SPIFFE, so you get workload identity without running SPIFFE yourself.
An example policy, simplified from the Hush console. It says who the workload is, what it may do, and how it receives its credentials. There is no secret in it. Rotate issues fresh credentials on demand.
How it works
- Define. You set policies by API or infrastructure as code: which workloads reach which resources, with what rights.
- Mint. The Access Manager runs in your environment. It creates scoped credentials at each target, per policy, keeps rotating them, and revokes them when no workload matches anymore.
- Attest. When a workload starts, the Access Manager verifies its identity and matches it to policy.
- Deliver. Each workload receives only its own credentials, as environment variables or files. It needs no access to a vault, and no code changes.
- Connect. The workload talks to the resource directly, in its native protocol. There is no proxy in the path.
The Access Manager runs in your environment. It manages credentials at each target and hands each workload only its own (dashed). The workload then talks to the target directly (solid): Hush is never in the path of your traffic. Numbers follow the steps above.
The same week, replayed
Run this week again with every credential managed this way.
The stealer still runs. It still finds credentials, in environment variables or files, wherever the workload keeps them.
Each credential it takes is short-lived, and belongs to one workload.
Once the bad package is gone, you redeploy the affected workloads. Hush hands them fresh credentials and retires the stolen copies. Every other workload keeps running untouched. Its credentials were never exposed, so there is nothing to rotate.
No hunt for copies. No spreadsheet of owners. No lost weekend.
Where to start
Start with the secret you would least like to see in a stolen archive. Pick one workload and one resource. Hush can suggest the first policy from what that workload already uses. Then let the Access Manager take it from there, and move on to the next one.
And ask the question this week raised: if you had to rotate everything tonight, how long would it take, and how sure would you be that you got it all?
How long would “tonight” take?
Connect one environment and see every secret, and every one you’d miss.
See your secret inventory for FREE