Should teams prioritise secret rotation or package restriction first after a trojanised dependency?

Why package restriction has to happen before secret rotation

A trojanised dependency changes the order of operations because the unsafe code path is still active. If you rotate secrets first but leave the package available, the same dependency can immediately capture the new values again. Containment comes first: block execution, then treat every exposed credential as potentially burned and rotate it with proof that the malicious path is no longer reachable.

That is especially true when the dependency can be pulled from build systems, notebooks, or other developer paths that automatically re-resolve packages. In that situation, a rotation-only response creates a moving target for defenders and a persistent collection opportunity for the attacker.

Where the race condition comes from

The practical issue is not just that a package was malicious, but that it may still be trusted by automation. A CI job, notebook, or bootstrap script can continue reinstalling the same dependency after you have changed the secret, which means the compromise mechanism is still present even though the secret value is new.

That is why package restriction should be paired with blast-radius thinking. You are not only stopping one install event, you are removing a repeatable path for credential capture, token theft, or further tampering. LiteLLM PyPI package breach is a useful reminder that dependency compromise can turn package execution into credential exposure very quickly.

What “done” looks like after containment

Once the malicious package is blocked, the response shifts from containment to recovery. Rotate the exposed secrets, invalidate any sessions or tokens that may already have been copied, and check whether any downstream systems inherited the same dependency through mirrored images, cached wheels, or notebook environments.

It also helps to separate short-term remediation from longer-term hardening. If teams only rotate secrets, they may miss the more durable problem, repeated re-entry through the same package source. A stronger fix includes dependency pinning, allowlisting, internal package controls, and a review of where build and notebook environments can resolve code. Guide to the Secret Sprawl Challenge is relevant here because exposed secrets often spread across more places than the initial incident suggests.

Risk and Threat Considerations

A trojanised dependency is dangerous because it can keep harvesting credentials until the execution path is removed. The main risk is not just disclosure of one secret, but repeated disclosure of newly rotated material if the package remains available in any trusted workflow.

Failure mechanism: An attacker-controlled dependency continues to run in a build, notebook, or automation path, captures fresh secrets after rotation, and preserves access even after defenders believe the incident has been handled.

Impact: The organisation can end up in an endless rotation loop, with renewed token theft, pipeline compromise, and possible lateral movement through systems that reused the same dependency.

Practitioner Guidance

Decision rule: If the dependency is still installable or callable anywhere, prioritise restriction and removal before rotating exposed secrets. If you cannot prove containment, assume rotation will be wasted effort.

What to verify: Confirm that the malicious package is blocked in every resolution path, including CI, notebooks, caches, and mirrors, then verify that no remaining workflow can reintroduce it.

What good looks like: The dependency is no longer reachable, exposed credentials are rotated and revoked, and the same package cannot silently re-enter through another build or developer environment.

Practitioner takeaway: In dependency compromise, rotation is recovery, but restriction is containment, and containment must win first or the attacker may simply collect the replacement secrets too.

Related resources from NHI Mgmt Group

• Should teams prioritise package provenance or secret rotation first after a registry compromise?
• Should organisations prioritise secret rotation or dependency review after a package compromise?
• Should teams prioritise secret discovery or rotation first after exposure?
• Should teams prioritise extension allowlisting or secret rotation first after this kind of incident?