Isolate any system that installed the package, inspect caches and workflows, rotate secrets that could have been reachable, and review repository activity for tampering. Then verify whether build or deployment identities were exposed. The immediate goal is containment of secret leakage and downstream propagation, not just package removal.
Why This Matters for Security Teams
A malicious package advisory is not just a software supply chain event. It is an identity event, because the package may have touched build tokens, CI/CD secrets, cloud keys, signing material, or repository permissions before the team even knew it was malicious. The first 24 to 72 hours are about stopping secret leakage and propagation, not proving every file is clean. That distinction matters because attackers often use package compromise to move laterally through automation, not to trigger obvious endpoint alerts.
Current NHI guidance from The State of Non-Human Identity Security shows how fragile remediation remains: 91.6% of secrets are still valid five days after notification, which means delayed rotation is a common failure mode, not an edge case. Team members should also expect to review vendor and public advisory context through sources such as CISA cyber threat advisories, especially when scope and indicators shift quickly.
In practice, many security teams encounter downstream compromise only after automation has already reused the exposed secret.
How It Works in Practice
Start by identifying every system that pulled the package, then assume any workflow, runner, or developer machine that installed it may have exposed reachable secrets. That includes dependency caches, package mirrors, artifact stores, CI jobs, deployment bots, and any repository automation that ran during the advisory window. If the package had access to tokens, rotate them immediately and verify whether the new credentials are actually replacing the old ones everywhere they were used.
Next, check the identity layer behind the automation. Build and deployment identities often have broader rights than they need, so validate whether the compromise reached service accounts, cloud roles, or signing identities. This is where NHI-focused response beats generic malware cleanup. The attack paths described in LiteLLM PyPI package breach and Shai Hulud npm malware campaign both illustrate how a package incident can quickly become a secrets incident and then a repository integrity incident.
- Isolate affected hosts and runners before additional jobs execute.
- Inspect package caches, lockfiles, dependency mirrors, and CI artifacts for tampering.
- Rotate reachable secrets, then revoke and reissue long-lived tokens where possible.
- Review commit history, workflow runs, and repository settings for unauthorized changes.
- Confirm whether signing keys, release credentials, or deploy identities were exposed.
For implementation detail on response timing and containment, pair this workflow with current CISA threat advisory updates and your internal secret inventory. These controls tend to break down when secrets are embedded directly in code or when CI systems reuse the same long-lived token across many jobs because the blast radius becomes difficult to bound.
Common Variations and Edge Cases
Tighter containment often increases operational disruption, requiring organisations to balance service continuity against the risk of hidden propagation. That tradeoff is most visible in monorepos, shared runners, and heavily cached build pipelines, where a single advisory can affect dozens of applications at once. Best practice is evolving, but there is no universal standard for how aggressively to rebuild everything versus surgically isolate only the touched paths.
Some environments can reissue credentials quickly, while others depend on external vendors, hardware security modules, or manual approval gates. In those cases, teams should prioritise the highest-value identities first: deployment credentials, repository tokens, package publishing keys, and any secret with write access. If a package was executed in an agentic workflow or automated code assistant, the response should also examine whether the software agent had autonomous access to secrets beyond its immediate task.
Use alert triage to separate confirmed exposure from likely exposure, but do not wait for perfect certainty before revocation when a secret may have been reachable. The key exception is systems with true ephemeral credentials and strong isolation, where the immediate risk is lower if tokens were already short-lived and scope-limited. Even then, review logs, because compromise often shows up first as unusual repository or workflow behaviour rather than direct secret use.
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 address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Addresses secret rotation after package compromise. |
| NIST CSF 2.0 | PR.DS-5 | Covers data and secret protection during incident response. |
| NIST AI RMF | Supports governance for autonomous or automated software actors. |
Assign accountability for automation, then review agent and workflow access after compromise.
Related resources from NHI Mgmt Group
- What should teams do in the first 24 to 72 hours after discovering a compromised AI agent runtime?
- What should teams do in the first 24 to 72 hours after a connected app compromise?
- What should teams do in the first 24 to 72 hours after suspected package compromise?
- What should organisations do in the first 24 to 72 hours after an agent behaves anomalously?
