Because build agents and developer tooling often hold broad delegated access to repositories, signing systems, and release infrastructure. When malicious code runs during install, it can read secrets before the build finishes, turning a package event into an identity breach that can propagate into mobile release paths.
Why install-time execution turns npm into a secret-exposure event
Install-time attacks matter because package managers are often trusted to run code before the build is fully isolated or complete. That code can execute in the same environment that holds repository tokens, signing credentials, cloud access keys, or release automation secrets, so the package install step becomes a direct path to identity compromise rather than just dependency risk.
The key issue is timing and privilege. If a malicious package runs during installation, it can inspect environment variables, local files, cached credentials, and process context before controls such as artifact signing or deploy gates have a chance to intervene. In practice, that means a routine dependency update can expose the same secrets that protect source code, CI/CD pipelines, and downstream release systems.
This is why package-manager abuse so often overlaps with secret theft: the attacker does not need to defeat the build outright if the build agent already carries delegated authority. A stolen token from a runner or developer workstation may be enough to reach GitHub, container registries, mobile signing services, or package publishing systems, and those paths can be reused long after the original install finishes.
For a broader view of the mechanism, the Ultimate Guide to NHIs, What are Non-Human Identities is useful because it frames build credentials, service principals, and similar machine-access material as identities with lifecycle and privilege concerns. Install-time compromise is dangerous precisely because it targets those delegated identities while they are active and reachable.
Why CI/CD tokens and mobile build identities are especially exposed
CI/CD systems tend to concentrate privileges. A single runner may hold repo write access, package publish rights, deployment tokens, signing inputs, or access to cloud services used for build and test. Mobile delivery makes that even more sensitive because the build chain often touches code signing, notarization, provisioning profiles, app-store publishing, crash telemetry, and protected release artifacts.
Mobile build identities are valuable targets because they are used at the point where software becomes shippable. If an attacker can read or replay those credentials, they may not just steal source access, they may be able to alter release output, replace artifacts, sign malicious builds, or pivot into update channels that reach end users. That is why a package install running inside the build context can have consequences far beyond the local machine.
The same pattern shows up in real supply-chain incidents where npm activity led to credential theft and secret exposure. NHIMG’s Shai Hulud npm malware campaign and Nx s1ngularity attack 2025 both show how package compromise can turn into secret harvesting, token abuse, and exposure of developer and pipeline credentials. Those incidents illustrate the practical bridge between install-time execution and identity theft.
For mobile-specific exposure, NHIMG’s iOS apps leaking hard-coded secrets is a useful reminder that mobile ecosystems already suffer from secret sprawl. When build identities are weakly bounded, package-time execution can reach the credentials that should have stayed confined to signing and release workflows.
What a safer build model needs to change
The defensive response is not to assume install hooks are harmless, because they are part of the execution surface. A safer model treats dependency installation as an untrusted action, separates it from release credentials, and assumes any code that runs during install may attempt secret discovery or token reuse. That posture is especially important when build systems share the same environment for dependency resolution, testing, packaging, and release.
Practically, the strongest control is to reduce what the install step can see. Build identities should be narrow, ephemeral where possible, and separated from signing and publishing identities. Release tokens should not be present during dependency installation unless there is a documented reason, and mobile signing credentials should be isolated so a compromised package cannot directly reach them.
Where teams rely on npm heavily, the risk is not only malicious code in one package but also the blast radius created by overbroad build trust. NHIMG’s Guide to the Secret Sprawl Challenge and ArtiPACKED 2024 both reinforce the same lesson: secrets become exploitable when they are left available in pipeline-adjacent places for longer than necessary.
Risk and Threat Considerations
Install-time npm attacks are attractive because they exploit a trusted automation step that already has access to the very credentials defenders want to protect. Once a malicious package runs, the attacker may gain enough material to publish code, access repositories, impersonate build infrastructure, or tamper with mobile release artifacts without needing a second foothold.
Failure mechanism: The install hook executes before the build is fully complete, reads tokens or signing material from the runner or developer environment, and exfiltrates them for later reuse in CI/CD, repository, or release paths.
Impact: Stolen build identities can enable source tampering, unauthorized publishing, compromised mobile releases, and wider lateral movement through connected developer and delivery systems.
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 OWASP API Security Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Install-time malware can read CI/CD and signing secrets from build environments. |
| NHI-05 — Overprivileged NHI | Build and mobile release identities often hold more access than install steps need. | |
| NHI-07 — Long-Lived Secrets | Persistent tokens in runners make package-install compromise more damaging. | |
| Recommendation — Remove secrets from install-time environments and rotate any exposed credentials immediately. Scope build identities to the minimum permissions needed for each pipeline stage. Replace long-lived build tokens with short-lived credentials and rotate them aggressively. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | Stolen CI/CD tokens and build credentials can be replayed as valid auth material. |
| Recommendation — Harden token issuance and require sender-constrained or short-lived authentication where possible. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | CI/CD tokens and mobile signing secrets need lifecycle control and timely rotation. |
| AC-6 — Least Privilege | Build agents should not retain broad access to repo, signing, and release systems. | |
| Recommendation — Manage, rotate, and revoke build credentials as soon as exposure is suspected. Limit each build identity to the smallest set of actions required for its stage. | ||
Practitioner Guidance
What to verify: Confirm which credentials exist during dependency installation, not just during deploy. If a token can publish, sign, or modify repositories, it should not be resident in the same execution context as unreviewed install-time code.
What good looks like: Install steps run with the minimum readable secret set, build and release identities are separated, and mobile signing or publishing credentials are only introduced at the latest possible stage. If the same runner can both install packages and release artifacts, treat that as a higher-risk condition.
Practitioner takeaway: The important boundary is not “trusted build versus untrusted package,” it is “what secrets are reachable while untrusted code is executing.” The safer the token scoping and identity separation, the less value an install-time compromise can extract.
Related resources from NHI Mgmt Group
- Why do build-time tampering attacks on CI/CD pipelines create such high risk for downstream software consumers?
- Why do CI/CD runners and build tools increase NHI risk?
- Why do CI/CD tokens increase supply chain risk when they are over-scoped?
- Why do build-time dependencies increase source theft risk in CI and developer workstations?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 12, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org