It depends on what the secret unlocks. A stolen CI secret can let an attacker publish a package, push to a repository, read other secrets or reach cloud resources, all while appearing to be your pipeline. Shrinking scope and lifetime is the most reliable way to reduce the damage.
Why CI secrets are valuable
A pipeline exists to deliver code, so it holds the keys to delivery. GitHub's documentation says that a compromised action in a workflow can reach all secrets configured on the repository, and may be able to use the pipeline token to write to the repository. The same logic applies to any CI system: whatever the job can do, an attacker running inside the job can do.
The blast radius ladder
Think of impact in steps. Each step is worse than the one above it.
| Level | What the secret allows | Typical consequence |
|---|---|---|
| 1 | Read repository contents | Source code exposure |
| 2 | Write to the repository | Malicious commits or workflow changes |
| 3 | Publish to a registry | A poisoned release under your name |
| 4 | Reach cloud accounts | Data access, new infrastructure |
| 5 | Reach other secrets from there | Lateral movement to more systems |
Most real incidents climb more than one step. A read token that reveals a second token moves the attacker up the ladder without any new break-in.
Lifetime matters as much as scope
A token valid for years is a standing invitation. PyPI's documentation makes the contrast concrete. Its normal API tokens are long-lived, so an attacker who steals one can use it until the owner notices and revokes it. Trusted publishing instead mints a token that is valid for 15 minutes.
GitHub's documentation on OpenID Connect describes the same idea for cloud access: the provider issues a short-lived token valid for a single job, which expires automatically.
Ways to shrink the ladder
- Use short-lived credentials from an identity exchange wherever your cloud or registry supports it.
- Scope each secret to one job and one resource.
- Set the default pipeline token to read only, and grant write access per job.
- Keep secrets out of jobs that run untrusted code, such as pull requests from forks.
- Mask and avoid printing secrets, but do not rely on masking. GitHub notes that automatic redaction is not guaranteed because values can be transformed.
- Log which job used which secret, so a review can rebuild the story.
If one is stolen
Revoke it first, then work out what it could reach. Rotate anything the same job could read. Check recent releases and commits made with the credential. Our guide on preventing CI/CD credential theft goes deeper on prevention.
Where Safeguard fits
Safeguard's compliance and evidence automation and its policies can help you record who can release and what gates apply. It does not replace secret scanning or secret management, so keep a dedicated process for those.
Quick check
Is a read only secret harmless?
Not always. Source code may contain other credentials or reveal how to reach internal systems.
Does masking in logs protect a secret?
Only partly. GitHub states that automatic redaction is not guaranteed, so limit exposure instead of relying on it.
Sources
Last reviewed: 19 October 2026.
