Malicious packages expose the codebase trust gap in software supply chains

At a glance

What this is: This is an analysis of how malicious open-source packages enter modern build pipelines and why dependency trust, maintainer compromise, and rapid propagation make them hard to contain.

Why it matters: It matters to IAM and security teams because package maintainer accounts, CI credentials, and transitive dependencies are identity and access problems as much as they are code integrity problems.

By the numbers:

• 30% of breaches now involve a third party.
• Over 180 packages, including some owned by major organizations, were affected.

👉 Read Veracode's analysis of malicious packages in the software supply chain

Context

Malicious packages are not just a software quality issue. They are a supply chain trust problem where an attacker uses the legitimacy of open-source distribution, maintainer accounts, and automated dependency resolution to move code into environments that developers assume are safe. In practice, the first failure is often identity related: a stolen maintainer credential, a compromised account, or a trusted namespace abused for delivery.

For IAM and NHI practitioners, the identity boundary now extends into software delivery. Developer accounts, CI tokens, package publishing rights, and secrets in build environments become part of the attack surface, which means package abuse should be treated as an access-governance and secrets-governance issue, not only a malware screening problem.

Key questions

Q: What breaks when malicious packages are not controlled at the source?

A: When package provenance is weak, attackers can use trusted registries and familiar dependency names to inject code into development pipelines. That can expose secrets, corrupt builds, and create a downstream path for malware or backdoors. The failure is not just detection speed. It is the absence of governance over who can publish, which sources are trusted, and how package identity is verified.

Q: Why do malicious packages create an identity risk as well as a code risk?

A: Because the attack usually depends on stolen maintainer credentials, abused publishing rights, or compromised CI tokens. Those are identities with authority, not just technical artefacts. When they are over-privileged or poorly monitored, an attacker can publish malicious updates or move laterally into build systems. Identity governance is therefore part of supply chain defence, not a separate concern.

Q: How do security teams know if dependency controls are actually working?

A: Look for evidence that unapproved packages are blocked before install, that package sources are restricted to known registries, and that maintainer or pipeline credentials are short-lived and auditable. If builds still accept unexpected versions, if secrets appear in logs, or if revoked access does not stop publishing, the controls are not working as intended.

Q: Who is accountable when a malicious package reaches production systems?

A: Accountability usually sits across security, engineering, and platform operations. Engineering controls the dependency choices, security defines the detection and response requirements, and platform teams govern build pipelines and package trust policies. Frameworks such as NIST CSF, NIST 800-53, and MITRE ATT&CK support shared ownership of prevention, detection, and response.

Technical breakdown

How malicious packages enter trusted build flows

Attackers use typosquatting, dependency confusion, and dependency hijacking to exploit the way package managers resolve names and versions. A small naming mistake, a higher public version number, or an abandoned dependency can redirect builds toward attacker-controlled code. Because these mechanisms ride on trusted registries and normal developer workflows, they bypass many perimeter controls. The technical risk is amplified when organisations rely on unverified package sources, broad registry access, or unsigned and unpinned dependencies.

Practical implication: restrict package sources, pin dependencies, and block unexpected version resolution before code reaches the build stage.

Why maintainer compromise becomes a secret-exfiltration event

Phishing against package maintainers and account takeover are especially dangerous because publishing rights can be converted into malware distribution almost immediately. Once a trusted account is compromised, attackers can push trojanized releases that harvest browser tokens, environment variables, CI secrets, or payment details. This is an identity problem because the attack succeeds through legitimate credentials and trusted publishing authority, not through exploit code alone. In NHI terms, the maintainer account and pipeline secrets are high-value identities that need stronger lifecycle control and monitoring.

Practical implication: apply phishing-resistant MFA, least-privilege publishing rights, and rapid revocation for package maintainer and CI identities.

How self-propagating package malware scales impact

Worm-like package malware extends compromise by reinfecting other projects, republishing malicious dependencies, and weaponising trusted developer tools to collect secrets. That shifts the incident from a single bad package to a recursive propagation problem across repositories and environments. Detection based only on known vulnerable package names is too slow because the malicious behaviour can be newly generated, nested inside legitimate tooling, and triggered after installation. Behavioural monitoring and runtime controls matter because the package itself is only the delivery mechanism; the real impact occurs when the malicious code can execute, exfiltrate, or alter downstream systems.

Practical implication: monitor post-install behaviour, quarantine suspicious dependency activity, and contain access to repositories and CI environments quickly.

Threat narrative

Attacker objective: The attacker aims to turn trusted software distribution into a repeatable path for code execution, secret theft, and downstream supply chain compromise.

1. Entry occurs when attackers deliver malicious packages through typosquatting, dependency confusion, or compromised maintainer accounts.
2. Escalation follows when the package executes in developer or CI environments and harvests secrets, tokens, or account credentials.
3. Impact occurs when the attacker uses stolen access to publish malicious updates, exfiltrate sensitive data, or propagate compromise across additional packages.

NHI Mgmt Group analysis

Software supply chain compromise is increasingly an identity abuse problem, not only a code trust problem. Malicious packages succeed when maintainers, publishing rights, and CI secrets are treated as low-risk operational conveniences rather than governed identities. That means package abuse belongs in the same governance conversation as NHI sprawl, secrets exposure, and privileged access. Practitioners should treat publishing authority and build-system credentials as governed identities, not incidental tooling.

Secret exposure is the force multiplier that turns package compromise into enterprise impact. Once an attacker can harvest tokens or environment variables from a build process, the package itself becomes only the first foothold. This is why the OWASP Non-Human Identity Top 10 and NHI governance practices matter here: the attack surface is the credential path into build and release systems. The practical conclusion is to govern secrets, not just scan code.

Dependency trust needs a named control concept: package provenance assurance. In this context, provenance assurance means knowing where a dependency came from, who can publish it, and whether the build system is allowed to accept it. That is broader than vulnerability management because many malicious packages are not originally vulnerable, they are intentionally harmful. Practitioners should design controls around source verification, namespace protection, and publishing lifecycle governance.

Real-time behavioural detection has to complement pre-install blocking. The article is right to emphasise prevention, but the operational reality is that no static allowlist will catch every package abuse pattern. Organisations need both source-level policy and runtime detection for unexpected network calls, file access, or secret access after installation. The field is moving toward layered supply chain assurance, and teams that still rely on scanning alone will miss the shortest attack paths.

Build and release pipelines are becoming privileged execution zones. The more automation an organisation uses, the more valuable CI identities, registry tokens, and package signing rights become to attackers. That creates a governance obligation to map these identities, constrain their scope, and revoke them quickly when abuse is detected. Practitioners should align supply chain security with identity governance rather than managing it as a separate security silo.

What this signals

Package provenance assurance: the next control frontier is not only preventing malicious downloads, but proving that every dependency, maintainer, and publishing path is expected. That pushes software supply chain security closer to identity governance, because the real question is who is authorised to introduce code into a trusted pipeline.

As package abuse becomes more closely tied to credential theft, teams should expect secrets sprawl to remain the easiest bridge from developer compromise into broader environment access. Our research on leaked secrets shows why cleanup lag matters: once credentials escape into logs, builds, or repos, the response window is already constrained.

Security and platform teams should plan for tighter coupling between dependency policy, secrets handling, and CI identity lifecycle. The organisations that reduce exposure fastest will be the ones that treat registry access, maintainer approval, and pipeline tokens as governed identities rather than convenience accounts.

For practitioners

• Lock down package publishing identities Require phishing-resistant MFA, short-lived publishing access, and explicit approval for maintainers who can release to npm or PyPI namespaces used by the organisation.
• Enforce dependency provenance controls Pin package versions, restrict registries to approved sources, and block unexpected namespace resolution such as dependency confusion or typosquatting patterns.
• Treat CI secrets as high-risk NHI assets Inventory pipeline tokens, rotate them on a fixed schedule, and remove broad reuse across repositories so a single package compromise cannot fan out across builds.
• Add behavioural checks after install Monitor for unusual secret reads, outbound connections, and repository changes after package installation, then quarantine the build if those actions appear.
• Build an offboarding process for abandoned dependencies Review ownership for packages that your pipelines still trust, and replace or fork dependencies where maintainer inactivity creates hijack risk.

Key takeaways

• Malicious packages exploit trust in open-source distribution and often succeed through identity abuse, not just code injection.
• The attack window can be extremely short, which means detection after installation is necessary but not sufficient.
• Teams need package provenance controls, strong maintainer governance, and tighter management of CI secrets and publishing identities.

Key terms

• Malicious Package: A malicious package is software published to a repository with harmful intent, even if it looks like a normal library. It may steal secrets, install malware, or create a backdoor when installed in a developer or build environment.
• Dependency Confusion: Dependency confusion is an attack where an external package is published with the same name as an internal dependency, often at a higher version number. Build systems that trust public registries may select the attacker-controlled package during dependency resolution.
• Package Hallucination: Package hallucination occurs when an LLM suggests a package name that does not exist, creating a gap attackers can exploit. If the suggested name is later registered by an attacker, developers may unknowingly install malicious code from a seemingly plausible source.
• Access Provenance: Access provenance is the record of how an identity was created, approved, used, and withdrawn. In NHI governance, it is the evidence trail that lets teams prove an account is legitimate, explainable, and still within its intended access boundary.

What's in the full article

Veracode's full article covers the operational detail this post intentionally leaves for the source:

• Step-by-step examples of malicious package techniques including typosquatting, dependency confusion, and dependency hijacking.
• Veracode Package Firewall usage context for blocking suspicious packages before they reach the development workflow.
• Software Composition Analysis guidance for mapping transitive dependencies and prioritising remediation.
• Developer training and CI/CD policy examples for reducing exposure to package-based attacks.

👉 Veracode's full post covers the attack patterns, business impact, and defence steps in more operational detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and secrets management in a way that helps practitioners connect access control to real operational risk. It is designed for security and identity teams that need a shared language for governing identities across modern systems.