Automated package campaigns raise risk because they can flood registries with seemingly normal packages that later become useful for credential harvesting, miner loading, or broader supply chain abuse. CI/CD systems are attractive because they often install dependencies at scale and trust package ecosystems by default. Once trust is established, a malicious package can become an entry point.
Why package campaigns are especially effective against build pipelines
Automated package campaigns work because build systems are designed to trust dependency resolution, repeat installs, and human review at scale. A single malicious package can sit quietly until it is pulled into CI/CD, where automation expands the blast radius far faster than a manual workstation install would. That makes the campaign valuable even before it steals anything.
The key risk is not just that a package is malicious, it is that modern delivery pipelines often treat package activity as routine. Registries, build agents, and dependency bots create high-volume, low-friction opportunities for an attacker to blend in, wait for adoption, and then trigger a payload when the package is installed or executed inside a privileged build context. NHIMG’s Shai Hulud npm malware campaign and Nx Package Attack, 2,300+ Credentials Leaked both show how package-level compromise turns build-time trust into broad exposure.
One useful statistic here is that 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools. That matters because package campaigns often aim to reach those exact surfaces once they are inside the build flow, especially where tokens, signing material, or cloud credentials are present in environment variables or pipeline configuration. NHI Mgmt Group’s Ultimate Guide to Non-Human Identities is useful background on why those exposed materials remain such a persistent control gap.
What changes when the package becomes part of the pipeline
At the registry level, a campaign can look like normal software publishing: new package names, frequent releases, dependency churn, and plausible maintainer activity. The security shift happens when CI/CD systems automatically fetch, build, test, or publish with those packages in scope. At that point the package is no longer just software, it is an execution path into the delivery system itself.
That is why these campaigns are so attractive for credential harvesting and supply chain abuse. A malicious dependency can read build logs, inspect environment variables, exfiltrate signing keys, or alter artifacts before they are promoted downstream. In a build environment, the impact is often amplified by shared runners, cached credentials, broad repository access, and trust in third-party dependencies. The Reviewdog GitHub Action supply chain attack and CI/CD pipeline exploitation case study illustrate how pipeline trust and secret handling can be abused once code is allowed to run in the delivery path.
There is also a scale effect that is easy to underestimate. A package campaign that compromises one developer laptop is bad; a campaign that compromises a shared build job, a reusable action, or a popular transitive dependency can affect many repositories at once. That is why the threat is often less about one bad package and more about the automation surrounding it.
Risk and Threat Considerations
Automated package campaigns increase exposure because they combine stealth, scale, and execution privilege. The attacker does not need every package to succeed, only enough installations inside trusted build environments to harvest secrets, tamper with outputs, or establish persistence through the software supply chain.
Failure mechanism: The package is introduced through normal dependency resolution, then executes during install, test, or build steps where it can access credentials, network access, caches, and artifact publishing paths. The campaign succeeds when defenders assume package installation is routine and do not inspect what the build runner can reach.
Impact: Compromised CI/CD systems can leak secrets, sign malicious artifacts, poison downstream releases, and spread the compromise to every application that consumes the pipeline outputs. At that point the incident moves from a single package event to a broader supply chain trust failure.
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, OWASP Agentic AI Top 10 and MITRE ATT&CK address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS 6 — Access Control Management | Build pipelines need tight access and secret exposure control to limit package-driven compromise. |
| CIS 16 — Application Software Security | Package campaigns exploit software supply-chain and dependency handling inside delivery workflows. | |
| Recommendation — Restrict CI/CD permissions and revoke unnecessary access paths from build runners and accounts. Harden software acquisition and dependency handling to reduce malicious package exposure. | ||
| NIST CSF 2.0 | PR.AC — Identity Management, Authentication and Access Control | CI/CD trust and package execution become dangerous when access controls and identities are too broad. |
| PR.DS — Data Security | These campaigns often target secrets, tokens, and signing material in pipeline environments. | |
| PR.IP — Information Protection Processes and Procedures | Package intake, dependency review, and build integrity are core process controls for this threat. | |
| Recommendation — Apply least privilege to build identities and constrain what packages can access during execution. Protect secrets and signing material used by CI/CD workflows. Add dependency verification and release integrity checks to software delivery processes. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Secrets and Credential Management | Package campaigns often harvest secrets embedded in CI/CD systems and build contexts. |
| NHI-03 — Privilege and Access Control | A malicious package becomes far more dangerous when build identities have excessive privilege. | |
| NHI-08 — Third-Party and Supply Chain Risk | Automated package campaigns are a direct third-party supply-chain abuse pattern. | |
| Recommendation — Move build secrets into managed vaults and rotate any credentials exposed to package execution. Limit build and release identities to the minimum access needed for each pipeline stage. Assess dependency sources and verify package provenance before promotion into CI/CD. | ||
| OWASP Agentic AI Top 10 | A3 — Tool and Action Authorization | Build automation can behave like an agent when it is allowed to execute package actions with authority. |
| Recommendation — Authorize only the specific build actions and package operations each automation step requires. | ||
| MITRE ATT&CK | T1195 — Supply Chain Compromise | Automated package campaigns are a supply-chain compromise path into CI/CD systems. |
| Recommendation — Model package ingestion and build execution as supply-chain compromise attack surfaces. | ||
Practitioner Guidance
What to prioritise: Treat dependency installation paths as execution surfaces, not passive inputs. Focus first on the build identities, stored secrets, and artifact-signing privileges that a package can touch if it runs inside CI/CD.
What to verify: Confirm which pipelines auto-install dependencies, which runners have network egress, and whether package scripts are allowed to execute by default. If the answer is “all of them,” assume a package campaign can reach sensitive material unless proven otherwise.
Common mistake: Reviewing package popularity or typosquatting risk without checking what the build environment exposes after install. The exposure usually comes from pipeline privilege and secret placement, not from the package name alone.
Practitioner takeaway: The real control question is whether a package can become executable inside a trust boundary that already contains secrets or release authority. If yes, the campaign risk is not theoretical, it is a direct supply chain access path.
