TL;DR: Persistent malicious package campaigns in 2025 pointed to industrial-scale supply-chain abuse, with 3,180 confirmed packages and heavier activity in October, November and December, according to Xygeni. Build pipelines need stronger containment and behavioural checks because package installs can still reach secrets, tokens and automation credentials.
Editorial analysis by NHI Mgmt Group, based on content published by Xygeni: “Malicious Packages 2025 Recap: Malicious Code and NPM Malware Trends”.
Key questions
A: Malicious packages are dangerous because they execute where developers compile and install software, which often gives them access to source, build environments, and inherited secrets.
Q: How do security teams know whether a malicious package has spread across the environment?
A: They need cross-application visibility that ties package names, versions, and dependency relationships to deployed assets.
Q: What breaks when malicious packages can publish many near-identical versions?
A: Reputation-based review breaks first, because repeated releases can look like healthy maintainer activity even when they are used to evade detection.
Practitioner guidance
- Enforce lockfile-only installs in CI/CD Use npm ci or pip install --require-hashes so the dependency tree cannot drift during build execution.
- Harden build environments against secret exposure Run package installation in containers or runners that do not contain long-lived tokens, broad environment variables, or writable secret stores.
- Block builds on suspicious package behaviour Fail the pipeline when a package shows obfuscation, unexpected install hooks, unpublished maintainer changes, or IOC matches.
Bottom line: Malicious package campaigns in 2025 were not isolated events but a scaled pattern of supply-chain abuse aimed at developer and build environments.
Glossary terms: Supply Chain Abuse, Malicious Package, Version Inflation, Build-Time Trust Boundary
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
Package ecosystems have become an access layer, not just a distribution layer. Once build systems install third-party code with secret access, the package registry is effectively part of the trust perimeter. The article's evidence shows attackers are optimising for automation, not user endpoints, which makes CI/CD governance the real control surface. Practitioners should treat dependency intake as privileged execution.
A question worth separating out:
Q: Should organisations prioritise package control over post-install scanning?
A: Yes, when the package can execute during installation. Post-install scanning still has value, but it arrives after the most dangerous trust boundary has already been crossed. Organisations should prioritise controls that prevent untrusted code from running in environments that contain secrets or production-connected credentials.
👉 Read our full editorial: Open-source malware in 2025 shows supply-chain abuse at industrial scale