TL;DR: Malicious packages are exploiting typosquatting, dependency confusion, package hijacking and maintainer phishing to infiltrate npm and PyPI supply chains, and Veracode cites the 2025 Verizon DBIR figure that 30% of breaches now involve a third party. The control gap is governance over provenance, maintainer trust and developer access before code reaches the build pipeline.
At a glance
What this is: This is an analysis of how malicious open-source packages enter development pipelines and why trust in package provenance is the weak point, not just post-download detection.
Why it matters: It matters because software teams that treat dependency ingestion as a low-risk convenience can inherit malware, secrets exposure and supply chain compromise through ordinary build workflows.
By the numbers:
- 30% of breaches now involve a third party, according to the 2025 Verizon Data Breach Investigations Report cited by Veracode.
Context
Malicious packages turn ordinary dependency intake into an attack surface. In software supply chains, the security problem is not simply whether a package is vulnerable, but whether it can be trusted at the point of selection, publication and update, especially when build systems automatically consume it.
This article sits at the intersection of software supply chain security, developer access and identity governance. The identity angle is real because the attacker path often depends on stolen maintainer credentials, compromised package ownership and overly broad access to publishing workflows.
The broader lesson is that ecosystem trust is now a control plane problem, not just a code review problem. Organisations that only scan for known vulnerabilities after download miss the upstream governance failures that let malicious components enter the pipeline in the first place.
Key questions
Q: What breaks when malicious packages reach build pipelines unchecked?
A: Unchecked packages can execute before conventional controls inspect them, which means secrets, environment variables, and internal tokens can be exposed during install or runtime. Once those credentials are captured, attackers may pivot into CI, cloud services, or downstream tools. The failure is not just malware execution, but trust in package provenance without continuous validation.
Q: Why do maintainer phishing and account takeover make supply chain attacks so effective?
A: Because registry systems usually trust whoever controls the publishing identity. When an attacker steals maintainer credentials or hijacks an abandoned package, they inherit legitimate access to publish malicious versions that look authentic to dependency automation. That turns identity compromise into a distribution channel.
Q: How do security teams know if dependency controls are actually working?
A: Look for whether build systems prevent unauthorised version drift, whether package provenance is checked before install, and whether secret-handling code is isolated from broad application reach. If packages can change quietly and still access sensitive material, the control model is failing even if scans are passing.
Q: What is the difference between package scanning and package provenance controls?
A: Scanning evaluates what is already present in a package, while provenance controls decide whether the package should be trusted and admitted in the first place. Scanning is useful for detection, but provenance controls reduce the chance that a malicious or hijacked package ever enters the build pipeline.
Technical breakdown
How malicious packages exploit trust in dependency ecosystems
A malicious package is code published to a public registry with the intent to be installed by unsuspecting developers or automation. Attackers abuse naming ambiguity, including typosquatting and dependency confusion, to place a hostile package where a legitimate dependency is expected. They also hijack abandoned packages or weaponise package discovery in developer tooling. The technical weakness is that registry trust is often implicit, while package installation is automated and fast. Once dependency resolution selects the wrong artifact, the build system can ingest attacker-controlled code with little friction.
Practical implication: treat dependency resolution as an access control decision, not a routine developer convenience.
Why maintainer credentials and package ownership are high-value targets
Package ecosystems depend on account ownership, maintainer trust and publishing permissions. Phishing a maintainer, stealing a token or taking over an abandoned account gives the attacker a legitimate channel to publish trojanised versions of otherwise trusted libraries. This is an identity problem as much as a malware problem, because the registry accepts the actor that can prove publishing rights, not the intent behind the change. When maintainer identity is weakly protected, the attacker does not need to break the ecosystem, only to become a valid publisher inside it.
Practical implication: harden maintainer identity and publishing privileges as if they were production access.
Why detection alone fails once malicious code is in the pipeline
Traditional scanning helps find known bad packages or known vulnerabilities, but it does not reliably stop a newly weaponised dependency that looks legitimate at first sight. Malicious packages often aim to steal secrets, modify payment destinations, or persist long enough to spread further through CI and adjacent projects. That means the security issue is not limited to package content, but to the timing of execution, the automation around updates and the visibility teams have into what runs during build and install. The faster the pipeline, the narrower the response window.
Practical implication: combine package screening with runtime visibility in CI/CD and developer environments.
Threat narrative
Attacker objective: The attacker wants trusted distribution through public package ecosystems so malicious code, stolen secrets and downstream compromise spread at scale.
- Entry occurs when a developer or automation process installs a malicious package through typosquatting, dependency confusion or a hijacked maintainer account.
- Credential harvesting follows when phishing or package payloads steal maintainer tokens, developer secrets or CI environment variables.
- Escalation and propagation occur when the attacker publishes trojanised updates, compromises additional packages or uses the stolen access to broaden distribution.
- Impact is malware execution, secrets exfiltration, payment hijacking, repository exposure and wider software supply chain compromise.
Breaches seen in the wild
- TrapDoor supply chain campaign 2026: TrapDoor's 34+ malicious npm, PyPI and Crates.io packages stole developer credentials and hid instructions for AI coding assistants. No victims known.
- Shai Hulud npm malware campaign: Shai Hulud campaign: npm malware exposed secrets on GitHub.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Codebase trust is the real attack surface in modern supply chains: the decisive control gap is not whether a scanner can spot known malware, but whether the organisation can trust the package, the maintainer and the publishing path before install time. Typosquatting, dependency confusion and account takeover all exploit the same assumption that registry trust is good enough by default. Practitioners need to treat dependency intake as a governed trust decision, not a passive download event.
Developer identity now governs software supply chain risk: the article shows that maintainer phishing and account hijack are not side stories, they are the primary mechanism that makes malicious packages credible. That makes publishing rights, multifactor authentication and offboarding of abandoned maintainers central controls, not administrative detail. In identity terms, the supply chain fails when publication authority is easier to steal than to verify, and that is the governance assumption teams must fix.
Real-time package control must sit ahead of build execution: the four-hour window described in the attack sequence shows why post-download detection is too late for high-velocity pipelines. Security teams need policy enforcement at the ingestion point, plus visibility into what the package does during install, build and runtime. The practitioner conclusion is clear: prevent untrusted dependencies from entering the pipeline, rather than hoping to contain them after they do.
From our research library:
- Breaches involving third parties rose to 48% of all breaches, a 60% increase on the previous year, according to Verizon's 2026 Data Breach Investigations Report.
- Read next: AI Supply Chain Security and AI-BOM Guide
What this signals
Codebase trust is now a governance problem, not just a tooling problem: software teams that rely on open-source registries need policy controls at ingestion time, because package popularity does not equal provenance. The next step for practitioners is to close the gap between developer convenience and enforceable trust boundaries across build pipelines.
Supply chain compromise becomes an identity issue the moment maintainer access is stolen: malicious packages frequently succeed by taking over publishing identities rather than exploiting code alone. That means access review, offboarding and strong authentication for maintainers belong in the same risk conversation as dependency scanning.
The article's core signal is that speed amplifies exposure. When pipelines automatically accept public packages, the organisation needs a control model that verifies provenance before execution instead of assuming post-install detection can catch every malicious update.
For practitioners
- Enforce package provenance checks before install Block unvetted dependencies at the ingestion point and require provenance signals for public packages, internal mirrors and critical builds.
- Harden maintainer identity and publishing access Require strong authentication for package maintainers, review access to publishing rights and remove dormant or abandoned package owners.
- Monitor CI/CD for secret exfiltration behavior Add detections for unexpected outbound calls, secret access and repository visibility changes during package install and build stages.
- Inventory transitive dependencies continuously Maintain a live dependency map that includes transitive packages so security teams can isolate impacted components quickly when a malicious package appears.
Key takeaways
- Malicious packages exploit the trust assumptions baked into dependency intake, publishing rights and automated updates, which makes software supply chains vulnerable before code even reaches production.
- The article links this risk to a broader ecosystem pattern, including the fact that 30% of breaches now involve a third party according to the cited Verizon DBIR figure.
- The most effective control shift is to govern package provenance and maintainer identity upstream, then use scanning and runtime monitoring as secondary detection layers.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK and OWASP Non-Human Identity Top 10 address the attack and risk surface, while CIS Controls v8, SLSA and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | TA0006; TA0008 — Credential Access; Lateral Movement | The article centres on phishing, token theft and propagation through compromised package trust. |
| Recommendation — Map malicious package scenarios to TA0006 and TA0008, then hunt for credential theft and spread across build paths. | ||
| CIS Controls v8 | CIS-5 — Account Management | Maintainer and publishing account takeover is a core abuse path in the article. |
| Recommendation — Apply CIS-5 to review package maintainer accounts, remove dormant publishers and enforce strong authentication. | ||
| SLSA | Build provenance | The article is fundamentally about trusted build inputs and package provenance. |
| Recommendation — Use SLSA to require stronger provenance evidence before accepting third-party packages into builds. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article ties risk to who can publish, update and distribute packages in the supply chain. |
| Recommendation — Enforce PR.AA-05 so only approved identities can publish or update packages in production paths. | ||
| OWASP Non-Human Identity Top 10 | NHI-03 — Vulnerable Third-Party NHI | Compromised package maintainers and third-party publishing identities are central to the abuse pattern. |
| Recommendation — Treat third-party package maintainers as third-party NHIs and verify their lifecycle, ownership and access. | ||
Key terms
- Malicious Package: A malicious package is software published into a legitimate repository but designed to execute harmful code when installed. It abuses normal dependency workflows so that the attacker’s code reaches the environment through trust in the package ecosystem, not through a traditional exploit.
- Dependency Confusion: A supply chain attack in which a build system resolves a malicious public package instead of an intended internal one because of naming, versioning, or registry precedence. The risk is not only code substitution but automatic execution inside trusted pipelines that already contain valuable credentials.
- Package Hijacking: Package hijacking is the compromise of a legitimate package release or maintainer workflow so attackers can distribute malicious code under a trusted name. The risk rises when registries automatically publish new tags or execute package metadata without a strong quarantine step.
- Software Supply Chain Provenance: Software supply chain provenance is the record of where software came from, how it was built, and what changed along the way. It traces source code, dependencies, build steps, signing, and distribution artifacts so teams can verify origin, integrity, and accountability across development, release, and deployment.
Deepen your knowledge
The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance and secrets management concepts that help practitioners reason about publishing identity and trust boundaries. It is a useful fit for teams that need to connect identity controls to supply chain risk.
Published by the NHIMG editorial team on August 2, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org