Developer tips: How to keep malicious packages out of your codebase

Open-source components can streamline software building, making them a developer’s best friend—or worst enemy, if a supply-chain attacker decides to poison a package.

Software supply-chain management company Sonatype identified 394,877 new open-source malware packages in Q4 2025, representing a whopping “476% increase compared to the previous three quarters combined.” (The company said the increase was due largely to a self-replicating malware campaign.)

This attack often begins with a threat actor compromising a developer’s account, then publishing a malicious package to a trusted repository. Other developers pull from that source to create their own apps and services, spreading the malware.

Oh, great. More Dune. The latest attack—a “mini Shai-Hulud” (named after a cinematic sandworm)—compromised legitimate software packages and installed malicious credential-stealing updates that spread along connected dependencies.

As of May 19, a single stolen token with publish rights led to compromises across 633 malicious package versions in the npm software-registry ecosystem, according to research from application security platform Endor Labs.

And to make the attack even tougher to detect: The token-taking malware uses valid provenance markers.

We spoke with software pros about how to defend against malicious packages, even when they appear to be trusted.

Ignorance is bliss. Enable the “ignore-scripts” flag where possible, according to Peyton Kennedy, senior security researcher at Endor Labs. (Kennedy wrote a post of mitigation tips in that May post, including rotating credentials on npm publish tokens and cloud-platform account keys.) “When you enable the ‘ignore-scripts,’ these pre- and post- execute steps, where a lot of these credential harvesters hide, don’t end up executing,” Kennedy said.

Use lockfiles. A lockfile is a compiled, approved dependency list. Without one, a fresh install may pull the new version of a piece of software automatically—a process that attackers are taking advantage of, according to Kennedy.

“Attackers are exploiting that desire of wanting to be on the latest version of the software, whether that be for functionality or just maintenance…they’re exploiting that need for speed that developers have within their deployment cycle,” Kennedy said. (App security platform Semgrep recently shared a summary of lockfiles and the languages that support them.)

Watch for install-time anomalies. Is something that usually takes five seconds to install suddenly taking 15 minutes? That kind of behavior likely warrants investigation, Kennedy warned.

Use your mirrors. Provide a local copy—a mirror—of your codebase, that only gets updated after a “cooldown” period of a few days following a new version, according to Guillaume Valadon, staff cybersecurity researcher at secrets-protection company GitGuardian.

IT pros can use open-source tools or enterprise-artifact repositories to create a mirror—a server that sits between developers and, say, a public npm registry. The internal proxy caches the package and applies a company’s policies before serving it, Valadon wrote in a follow-up email to IT Brew, “Two policies do the real work: a 24- to 72-hour cooldown on new versions, so most malicious releases get yanked before a developer sees them, and an allowlist, so new dependencies need one-time approval before anyone can pull them.”

Today’s CISOs are figuring out how to address the growing problem.

“We’ve seen a lot of attacks with malicious npm packages, and it’s something that is hard to balance,” Sandra McLeod, CISO at Zoom, told us in May. “You want to enable your developers to be able to move quickly, to innovate and to have quick development cycles in terms of testing and trialing, but at the same time, you need to know that there’s real diligence being put into: What software are they working with? Are we ensuring that that software is coming from approved sources?”