Rotate every secret that was readable from any environment where the bad code could have run. For a malicious package that means the build machine or laptop that installed it. For a vendor build compromise it can mean the vendor product's stored credentials and, in severe cases, identity systems.
The scoping rule
Malicious code runs with the permissions of whoever ran it. So list the environments first, then the secrets reachable from each. Ask: what environment variables, files, tokens and cloud roles could this process read?
By attack class
| Class | Where code ran | Rotate first |
|---|---|---|
| Dependency confusion | Wherever the package was installed, often CI | CI secrets, registry tokens, cloud keys in that job |
| Compromised maintainer | Install or import time in build and production | Same, plus anything the app held at runtime |
| Build system compromise | Inside the vendor product on your network | Credentials the product stored, service accounts it used |
| Malicious update | Machines that applied the update | Secrets on those machines |
CISA's SolarWinds guidance lists reset of all credentials stored in the affected platform, and says that if administrative credentials or SAML token abuse is involved, the identity trust store may need to be treated as compromised. That is the upper end, and it depends on evidence.
A rotation sequence
- Contain first. Rotating while the bad code still runs just leaks the new secret.
- Rotate the highest value secrets first. Cloud admin, signing keys, registry publish tokens, production database credentials.
- Revoke, do not just replace. Make sure old tokens stop working.
- Rotate in dependency order. A key that protects other keys goes early.
- Check logs for use. Look for the old credentials being used from unexpected places.
- Record it. What was rotated, when, by whom.
Lower the cost next time
Short lived credentials expire on their own. PyPI documents tokens that last about 15 minutes in its trusted publishing flow, against long lived API tokens that stay valid until revoked. Scope secrets per job, and keep them out of developer shells where you can.
Common mistakes
Teams often rotate only the secret named in a report and miss the neighbors. A package that ran in CI could read every variable in that job, plus files on the runner. A package that ran on a developer laptop could read shell history, cloud credential files and SSH keys. Write the list from the environment outward, not from the headline inward, and have a second person review it. Also remember third party tokens, such as registry, chat and ticketing tokens, which are easy to forget because they sit outside the cloud account.
Quick check
Do I rotate if the package was only in a dev dependency?
Yes if it was installed where secrets were reachable. Dev tooling often runs on machines that hold them.
What if I cannot tell whether code executed?
Assume it did for environments that installed the version, and rotate on that basis.
Where Safeguard fits
Safeguard offers SBOM and dependency scanning, policies and gates, and compliance and evidence automation for recording what you did. Try the free scan.
Sources
Last reviewed: 19 October 2026.
