Rotate in order of blast radius: credentials that can publish or deploy code first, then cloud and infrastructure keys, then third party service tokens, then everything else the job could read. Rotating in a random order, or rotating the oldest first, leaves your most powerful secret live while you work through the list.
Why order matters
A malicious install script or build step runs with whatever the job could read. If the attacker holds a copy of your secrets, every minute a powerful one stays valid is a minute they can use it. GitHub's hardening guidance says the goal of rotation is to shrink how long a stolen secret stays usable, and that a secret printed in a log should be treated as exposed and rotated. During an incident, apply the same logic to every secret the job could reach.
The order to follow
| Priority | Secret type | Why first |
|---|---|---|
| 1 | Package registry publish tokens and signing keys | Lets an attacker ship malware under your name |
| 2 | Deploy credentials and cloud keys | Direct path to production |
| 3 | Source control tokens with write access | Lets an attacker alter code and workflows |
| 4 | Database, queue and storage credentials | Data access |
| 5 | Third party SaaS tokens | Narrower, but often hold customer data |
| 6 | Read only tokens and test keys | Lowest impact |
Steps
- Freeze the pipeline so no new job starts and reads fresh secrets.
- List every secret the affected jobs could read: repository, environment and organization secrets, plus anything fetched from a vault at run time.
- Create the replacement first, deploy it, then revoke the old one. This avoids an outage that tempts people to skip revocation.
- For each old credential, check its audit log for use you do not recognise before or after the incident window.
- Prefer short lived credentials going forward. npm now supports only granular tokens, and you set an expiry when you create one, so choose a short one.
- Record the time each secret was revoked. You will need it for the incident timeline.
What rotation does not fix
New secrets do not remove a foothold. If the attacker changed a workflow file, added a deploy key or a webhook, or planted a script in a cache, the new secret will be read by the same malicious code. Review recent changes to workflow files and to repository settings before you release the pipeline. See how to check whether a leaked key was used and what to do about a secret in git history.
A note on shared secrets
One credential used by many pipelines is the hardest to rotate, because every consumer breaks at once. Plan for it: list the consumers, schedule the change, and update them in a batch right after creating the replacement. If you find a shared deploy key during the incident, put splitting it into per pipeline credentials on the hardening backlog. Smaller credentials mean smaller incidents and simpler rotations.
Try it yourself
Click through it at your own pace, or open it full screen.
Click through the monitoring flow and notice how a new advisory on a package you already use surfaces without a fresh scan.
Quick check
Should I revoke first or create the new secret first?
Create and deploy the replacement first when you can do it in minutes, then revoke. If the old secret is known to be abused right now, revoke immediately and accept the outage.
Do I need to rotate secrets the job could not read?
Not for this incident. Scope the list to what the affected jobs could access, and rotate on your normal schedule for the rest.
Safeguard can scan your dependencies and generate an SBOM so you can see which projects pulled the affected package. You can try a free scan at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
