Treat the install as a security event, isolate the affected runner, and rotate any cloud credentials the runner could reach. Then review the package’s lifecycle scripts and network egress to determine whether the package attempted reconnaissance or credential access. The first goal is to stop further exposure, not to keep the build moving.
Why install-time scripts are the danger point
Install-time scripts turn package installation into active code execution, which means the build runner is no longer just fetching dependencies, it is running attacker-controlled logic. When that logic can reach cloud metadata, the package may be trying to harvest instance or workload credentials, probe the environment, or pivot into broader cloud access. Treat the package as part of the attack path, not as a routine dependency event.
That matters because metadata endpoints often sit on a privileged trust boundary. If the runner can reach them, the package may be able to obtain short-lived credentials or tokens that are much more valuable than the package itself. In npm supply-chain incidents, that pattern is often the difference between harmless tampering and a compromise that reaches cloud, source control, or CI secrets.
Teams should think in terms of blast radius: which runner, which network path, and which credentials were reachable at install time. A package that only downloads files is a different problem from a package that can make outbound calls, enumerate environment variables, and query internal metadata services.
What to stop and inspect first
The first operational move is containment, not cleanup. Stop the affected runner from continuing, prevent reuse of any transient credentials it may have accessed, and preserve enough state to determine whether the package only attempted reconnaissance or actually retrieved secrets. If the install happened in shared CI, assume the exposure window is larger than the single job.
Then review the lifecycle scripts in the package, along with the runner’s outbound network rules and metadata access path. The most useful question is whether the package had a route to cloud credentials, not whether it eventually exfiltrated them. If the runner could reach instance metadata, adjacent service credentials, or mounted secret material, rotate those credentials even before you have a full forensic picture.
For reference on the broader supply-chain pattern, Shai-Hulud npm worm first wave 2025 and Rspack npm compromise 2024 both show how install-time behavior can be used to steal secrets from build environments. For a related cloud-focused supply-chain lens, OpenSSF publishes practical guidance on open source supply chain security.
How to judge whether the package was reconnaissance or credential access
Install-time script activity is not automatically credential theft, so the next step is to separate probing from confirmed access. Reconnaissance signs include metadata requests, environment enumeration, process discovery, and attempts to identify cloud or CI providers. Credential access becomes more serious when the package can read tokens, instance profiles, kube credentials, SSH material, or secret stores available to the runner.
If you can prove the package contacted metadata and retrieved anything usable, treat that as a credential incident, not merely suspicious package behavior. In that case, rotate the exposed material first, then hunt for reuse across cloud accounts, CI jobs, registries, and internal tooling. Where the package only attempted the call and failed, preserve logs and network traces so you can determine whether the control failed open or the attack was blocked.
That distinction is important because different controls failed in each case. Failed access may indicate insufficient network isolation, while successful retrieval may indicate overbroad runner permissions, exposed metadata services, or weak secret handling in the build path. Either way, the package should be removed from trusted workflows until you know exactly what it touched.
Risk and Threat Considerations
Install-time scripts that can reach cloud metadata create a direct path from dependency installation to cloud credential exposure. The main risk is that a routine package install becomes a privileged access event, especially in CI runners that sit close to production secrets or can assume cloud roles.
Failure mechanism: The package executes during install, reaches a metadata or secret endpoint, and harvests credentials or reconnaissance data before defenders notice. That can enable reuse of short-lived tokens, lateral movement into adjacent cloud services, or exfiltration through the build pipeline.
Impact: A single compromised runner can expose cloud roles, source control tokens, and downstream build secrets, forcing rotation and containment across multiple systems rather than one package rollback.
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 and MITRE ATT&CK define the specific risk controls and attack patterns relevant to this topic.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Install-time scripts can expose cloud credentials and tokens. |
| NHI-04 — Insecure Authentication | Metadata access can retrieve credentials used for authentication. | |
| NHI-05 — Overprivileged NHI | Runner credentials may grant more cloud access than the job needs. | |
| Recommendation — Rotate exposed secrets immediately and block install-time secret access. Treat metadata-backed credential retrieval as an authentication exposure and revoke it. Reduce runner privileges to the minimum needed for the install workflow. | ||
| MITRE ATT&CK | T1552 — Unsecured Credentials | The scenario centers on credentials exposed through build-time code execution. |
| Recommendation — Hunt for exposed credentials in logs, files, and metadata access paths. | ||
Practitioner Guidance
What to prioritise: Contain the runner and revoke any credentials that were reachable from it before you spend time proving the package was malicious. If the environment shares identity material across jobs, assume the blast radius is broader than the original install event.
What to verify: Confirm whether the runner could reach metadata, whether the package had outbound network access, and whether the build environment exposed long-lived secrets or role-assumption paths. If any of those are true, treat the install as a security incident until the credential scope is understood.
Practitioner takeaway: The key judgement is to stop exposure first and investigate second, because once install-time code can touch metadata, the question is no longer “did the build succeed?” but “what authority did the package briefly inherit?”
Related resources from NHI Mgmt Group
- How should teams reduce risk from malicious npm package installs?
- How should security teams contain a supply chain worm that uses npm install hooks to steal multi-cloud credentials?
- How do security teams know if install-time scripts are unsafe?
- How should security teams prevent a malicious npm package from stealing cloud credentials?