To catch malicious packages in CI/CD, do four things in order: lock your dependency versions, check every new or changed package against known malicious package reports, restrict what installs can run, and monitor for drift after merge. Locking comes first because you cannot judge changes you cannot see.
How is this different from vulnerability scanning?
A vulnerable package is a good package with a bug. A malicious package is built to do harm: steal credentials, open a backdoor or run a miner. Version ranges, typo names and hijacked accounts are the usual delivery routes. A CVE database will not list a package that was published an hour ago and removed tomorrow.
So the checks differ. You need reports of malicious packages, signals about how a package behaves, and controls on what an install may do.
Step 1: Lock what you install
Commit lock files and install from them in CI, so the build uses exactly the versions you reviewed. Without a lock, a pipeline can pull a newer release than the one a developer tested, and that release may be the poisoned one.
Make dependency changes visible. A pull request that changes a lock file should be easy to review, with a diff of added and updated packages.
Step 2: Check against known malicious package reports
The OpenSSF malicious packages project is described as an open source database of reports of malicious packages published on open source repositories. It stores reports in the Open Source Vulnerability format, which makes them consumable by tools. The repository covers any ecosystem supported by the OSV schema.
On each pull request, compare added or changed packages with such reports and block a match. A commercial or in-house feed can sit alongside it. Safeguard's malware detection classifies packages across major ecosystems and can enforce in the pipeline, which you can see in the dependency inventory demo.
Open the dependency inventory demo
Step 3: Limit what an install can run
Many package managers can run scripts at install time. That is a feature attackers use. Where your tooling allows, disable install scripts by default and allow them per package that needs them. Run installs in a build environment with no access to production secrets and limited network access.
This step matters because reports lag. A new malicious package may not be listed yet, so containment reduces what it can do in the meantime.
Step 4: Watch for drift
After merge, keep checking. A package that was fine at install can be reported later, so rescan your inventory when new reports arrive. Alert on unexpected changes, such as a dependency that appears in a build but not in the lock file.
Look for warning signs
Signals are not proof, but they help a reviewer. A very new package with a name close to a popular one. A package whose maintainer changed recently. An install script that fetches something from the network. A big jump in size between versions. Treat any of these as a reason to read before you merge.
Honest limits
No detection catches everything. Reports depend on someone finding the package first, and behavior analysis can be evaded. Combine checks with least privilege in the build environment so a miss does limited harm. If you find one in your build, treat it as an incident: rotate every secret the build could read and review what shipped.
What to do
- Commit lock files and install from them in CI.
- Review dependency changes as their own diff in each pull request.
- Check added packages against malicious package reports and block matches.
- Disable install scripts by default, and allow them per package.
- Run builds without production secrets and with limited network access.
- Rescan the inventory when new reports arrive.
- Write a short response plan: rotate secrets, find affected builds, redeploy.
Quick check
Does a vulnerability scanner catch malicious packages?
Not reliably. Vulnerability databases track flaws in legitimate software. Malicious packages need separate reports and behavior checks.
What should I do if a malicious package ran in my build?
Assume the build environment's secrets were exposed. Rotate them, review what that build produced, and rebuild from a clean state.
Sources
Last reviewed: 18 October 2026.
