Notifications
Clear all
Topic starter
02/08/2026 12:25 pm
TL;DR: Malicious packages are being used to infiltrate npm and PyPI ecosystems through typosquatting, dependency confusion, maintainer phishing, and package hijacking, with the 2025 Verizon DBIR reporting that 30% of breaches now involve a third party. The control gap is not just detection after download, but governance over trust, dependency provenance, and developer access across the build pipeline.
NHIMG editorial — based on content published by Veracode: Malicious Packages: The Silent Threat to Your Codebase
By the numbers:
- 30% of breaches now involve a third party.
- Over 180 packages, including some owned by major organizations, were affected.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
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.
👉 Read Veracode's analysis of malicious packages in the software supply chain →
Malicious packages and supply chain trust: what should teams change?
Explore further
02/08/2026 1:24 pm
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.
A question worth separating out:
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.
👉 Read our full editorial: Malicious packages expose the codebase trust gap in software supply chains
