They should do both, but token containment usually reduces immediate blast radius faster. Pinning versions helps stop repeat exposure from known-bad packages, while token rotation and scope reduction cut off the attacker’s ability to reuse credentials already harvested from the environment. If tokens stay valid, package fixes alone will not close the breach path.
Why token containment usually comes before version pinning
After a credential or package compromise, the first decision is usually about stopping reuse of what the attacker already has. Pinning dependency versions helps freeze the supply chain at a known-good state, but it does not invalidate stolen tokens, so it cannot by itself close the live access path. token rotation and scope reduction usually reduce immediate blast radius faster.
That distinction matters because attacks that start with a malicious or compromised package often end with harvested credentials, not just a bad dependency version. If those tokens still authenticate successfully, the attacker can keep using them even after the vulnerable package is removed or pinned. The practical priority is containment first, then eradication of repeat exposure.
For supply-chain context and token theft patterns, see LiteLLM PyPI package breach and Slack GitHub breach 2022.
How the two controls work together in practice
Pinning and rotation solve different failure modes. Pinning versions blocks reintroduction of the same bad dependency, which is useful when the compromise path involved a package, a transitive dependency, or a malicious update. Rotation closes off abuse of any credentials, API keys, or tokens that may already have been exposed through logs, environment variables, CI/CD, or the compromised package itself.
That means the order is not either-or. If you only rotate and leave a poisoned dependency range open, you can be re-exposed on the next install or build. If you only pin and leave live tokens in circulation, you may stop the package from being fetched again while the attacker continues to act with stolen access. The correct response usually pairs both controls, but with token containment first when active misuse is plausible.
Guidance on short-lived credentials and lifecycle control is reinforced by Guide to NHI Rotation Challenges and Ultimate Guide to NHIs, Static vs Dynamic Secrets.
The same logic shows up in token-focused incidents, where a fixed package problem was not enough because reused tokens or unrotated credentials remained valid. In those cases, pinning helps prevent recurrence, but containment depends on revocation, rotation, and narrowing scopes or audience boundaries so the old credential cannot be replayed broadly.
What to do when the attack path involved tokens and packages
Start by identifying which credentials were exposed, where they were stored, and what they can still reach. Then rotate the tokens with the widest blast radius first, especially anything with production, repository, cloud, or signing permissions. Only after the active credential path is cut should teams treat dependency pinning as the main prevention step for recurrence.
If the environment relies heavily on automated builds, package managers, or machine credentials, the order becomes even more important because the compromise may be quietly persistent. A pinned version is a preventive control, but revoked or short-lived tokens are the control that stops immediate abuse. In other words, pinning removes one source of re-entry, while rotation removes the attacker’s present access.
Guide to the Secret Sprawl Challenge is useful where the incident exposed tokens in code, pipelines, or shared environments, because remediation has to address both exposure and reuse paths.
Risk and Threat Considerations
When organisations prioritise the wrong control first, they can leave a still-valid token in the hands of an attacker and assume the breach is contained because the package has been pinned. That creates a false sense of closure, especially when the original access path was through CI/CD, source control, or a third-party package that already harvested secrets.
Failure mechanism: The malicious or compromised dependency exposes credentials, and those credentials remain valid after the package version is pinned or removed. The attacker then reuses the live token to maintain access, move laterally, or return through another trusted integration.
Impact: Systems remain reachable, sensitive repositories or cloud resources stay exposed, and containment is delayed until the credential is actually revoked or replaced. In the worst case, pinning slows recurrence while the attacker continues to operate under legitimate-looking access.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5, SLSA and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Token theft and exposed credentials are central to the response order. |
| NHI-07 — Long-Lived Secrets | The answer hinges on whether still-valid tokens remain usable after the package fix. | |
| NHI-05 — Overprivileged NHI | Scope reduction is part of cutting blast radius after credential exposure. | |
| Recommendation — Rotate exposed tokens first, then close the leakage path and reissue secrets. Shorten secret lifetimes so stolen tokens expire quickly and reduce replay risk. Reduce token scope to the minimum access needed before restoring normal operations. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | The question is about rotating and invalidating credentials after compromise. |
| SI-2 — Flaw Remediation | Dependency pinning is a remedial control to block recurrence of a known-bad package. | |
| Recommendation — Revoke and replace authenticators promptly when compromise or exposure is suspected. Apply flaw remediation to block the compromised dependency version from re-entering builds. | ||
| SLSA | Supply Chain Levels for Software Artifacts | Dependency pinning addresses software supply-chain integrity after a bad package event. |
| Recommendation — Strengthen build provenance and dependency integrity so compromised packages are easier to exclude. | ||
| CIS Controls v8 | CIS-5 — Account Management | Token rotation and scope reduction are account and access hygiene measures. |
| CIS-4 — Secure Configuration of Enterprise Assets and Software | Pinning known-good dependency versions is a secure-configuration response. | |
| Recommendation — Remove stale access and reissue credentials after compromise to shrink blast radius. Lock software to approved versions and configurations to prevent reintroduction of the bad package. | ||
Practitioner Guidance
Decision rule: If the incident includes evidence of exposed or harvested tokens, rotate and scope-reduce first, then pin dependency versions to stop the same package path from reappearing. If there is no sign of credential exposure and the issue is strictly a bad package version, pinning can be the first containment move, but rotation should still follow for any secrets that were handled by the affected workflow.
What to verify: Confirm whether the compromised package could read environment variables, CI secrets, cached tokens, or developer credentials, because that determines whether the live access path is still open after the dependency fix. Also verify that replacement credentials are not sharing the same audience, scope, or long-lived secret format.
Practitioner takeaway: Package pinning prevents repeat exposure, but token rotation stops immediate reuse; when both are in play, cut off the credential first if there is any realistic chance it has already been harvested.
Related resources from NHI Mgmt Group
- Should organisations prioritise registry scoping or secrets rotation first after this kind of issue?
- Should organisations prioritise token rotation or app inventory first?
- Should organisations prioritise token rotation or behavioural detection first?
- Should organisations prioritise token lifetime or secret rotation first?