Because install and test workflows frequently expose credentials that developers and CI systems rely on every day. Attackers know those secrets are more valuable than the package itself, since they can unlock cloud APIs, source control, deployment tools, and signing processes. In supply-chain attacks, secret capture is often the real objective.
Why This Matters for Security Teams
Malicious packages are effective because they sit inside trusted software workflows, where developers, build runners, and automation agents already have broad access to repositories, registries, cloud consoles, and signing services. The package itself is rarely the end goal. The real value is the credential material exposed during install, test, or post-install execution. That makes secret theft a fast path from a single dependency compromise to broader environment access.
Security teams often underestimate how many secrets exist outside formal vaults. Tokens can appear in environment variables, local caches, CI logs, package manager configs, or ephemeral job contexts. Once exposed, they can be reused immediately unless short-lived, tightly scoped, and continuously monitored. Current guidance in the OWASP Non-Human Identity Top 10 is useful here because many of these tokens belong to machines and automation rather than people, which changes how they should be governed.
In practice, many security teams encounter secret theft only after a suspicious package has already been published, installed, and used to access downstream systems, rather than through intentional control testing.
How It Works in Practice
Package-based secret theft usually follows a simple pattern. A malicious dependency executes code during install, setup, build, or test hooks. That code enumerates accessible files, process environment, command history, package manager state, and CI variables. It then sends any discovered credentials to an attacker-controlled endpoint or writes them into an external drop location for later retrieval.
The impact depends on where the package is executed. A developer laptop may expose source control tokens and local cloud credentials. A CI runner may expose deployment keys, artifact signing material, and registry write access. A build system with broad trust can give an attacker a bridge into production pipelines, especially if secrets are reusable and not bound to device, workload, or session context.
- Limit install-time execution wherever possible, especially for unreviewed dependencies and transitive packages.
- Prefer short-lived secrets over long-lived static tokens, and scope them to one workflow or service.
- Separate human credentials from non-human identities used by CI, bots, and agents.
- Monitor for unusual package behavior, such as outbound connections, filesystem enumeration, or secret access patterns.
- Use controls from NIST SP 800-53 Rev 5 Security and Privacy Controls to anchor access control, audit logging, and system integrity requirements.
The defensive model is not just malware detection. It is reducing what a malicious package can see, how long any exposed secret remains useful, and how quickly suspicious activity is detected and revoked. These controls tend to break down when CI environments reuse shared runners with persistent credentials, because a single compromise can reach multiple projects and secrets at once.
Common Variations and Edge Cases
Tighter package and secret controls often increase build friction, requiring organisations to balance developer velocity against exposure reduction. That tradeoff is real, especially in polyglot repositories, monorepos, and legacy pipelines where installers expect broad network access or local secret availability.
There is no universal standard for this yet, but current guidance suggests treating package execution as a high-risk trust boundary when it occurs in privileged automation. Some environments can disable install scripts safely; others rely on them for legitimate build steps and must use sandboxing, allowlists, or isolated build agents instead.
Edge cases matter. A package that is harmless on a developer workstation may be dangerous in CI because the runner has broader access to signing keys or artifact stores. Similarly, a secret that looks low value in isolation may become critical when combined with role chaining, federated trust, or NHI reuse across services. That is why the intersection between software supply chain security and NHI governance is increasingly important: secret theft often succeeds by abusing identities that were never designed for human-style lifecycle management.
For practitioners building policy and review criteria, the key question is not only whether a package is trusted, but whether its execution context can observe secrets that should never be present there. That distinction is central to understanding the OWASP Non-Human Identity Top 10 and aligning it with workflow protections.
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 ATLAS address the attack and risk surface, while NIST CSF 2.0, NIST AI RMF and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-1 | Malicious packages often steal machine tokens and service creds, not human passwords. |
| NIST CSF 2.0 | PR.AC-1 | Secret theft is enabled by excessive access in build and install contexts. |
| NIST AI RMF | If packages target AI pipelines, model and data supply-chain risk must be governed. | |
| NIST SP 800-53 Rev 5 | SA-11 | Secure development controls support review and testing of third-party packages. |
| MITRE ATLAS | AML.TA0001 | Adversaries use supply-chain access to collect credentials for later compromise. |
Inventory and harden non-human identities so package execution cannot reach reusable secrets.
