A team deploys from CI to a cloud account. The pipeline uses a long-lived access key stored as a CI secret, rotated annually, with 14 repositories sharing it. A fork's pull request workflow once printed environment variables in a debug step. Which change gives the largest reduction in risk for the least ongoing work?
Show the full answer Hide the answer
The deciding property
There should be no stored secret to leak. Every other option keeps a credential that works from anywhere until it is rotated, so it still has to be protected from every log line, fork, runner and third party that touches the pipeline.
Why federation wins
With OIDC federation (GitHub Actions has supported this since 2021, and the major CI systems offer an equivalent) the CI run asks its provider for a signed identity token whose claims state the repository, branch and environment. The cloud's trust policy accepts only tokens whose claims match, and exchanges them for credentials valid for about an hour. Nothing is stored; a leaked token expires, and it is useless outside the claimed repository and branch.
The 14-repository sharing disappears as well. Each repository gets its own role scoped to what it deploys, so a compromise in one cannot reach the others.
Why the others fail
- Rotating monthly shrinks the exposure window from a year to a month, which is an improvement of degree. A leaked key is still usable for weeks, and rotation is a recurring chore that fails silently when it is skipped. The CircleCI incident in January 2023 forced customers to rotate every secret stored in the platform; teams with short-lived federation had nothing to rotate.
- A self-hosted secrets manager moves the problem: CI needs a credential to read from it, the secret-zero problem. It is the right answer when the secret is not a cloud credential (a third-party API key, a database password) and federation does not apply.
- Encrypting with a key held by the same provider adds no separation: whoever compromises the CI environment can decrypt, and the provider's own breach exposes both.
What it costs
A one-time trust policy per repository, careful claim conditions (an unbounded repo:* pattern lets any repository in the organisation assume the role, a common misconfiguration), and a path for jobs that run on forks, which should receive no federated access at all.
What would flip the decision
| If this changes | Choose | Because |
|---|---|---|
| The target cannot trust an OIDC issuer (an on-premises system) | Secrets manager with short-lived dynamic credentials | Federation is unavailable |
| Secrets are third-party API keys | Secrets manager and scoped keys | Nothing to federate with |
| One repository and one engineer | Stored key with narrow scope and an alert on use | The ceremony may outweigh the risk |
Common weak answers
- "Add a secret scanner to the repository." It finds leaks after commit and does nothing about a key that is printed at runtime.