Protect Against Open Source Malware Attacks with Semgrep Supply Chain

Last week, the application security world was rocked by Sha1-Hulud, the latest in an unprecedented string of supply chain attacks that highlights how threat actors are embedding sophisticated malware into the supply chain. These infected packages, distributed through trusted registries like npm, PyPI, and Go Module, have brought the problem of malicious open source dependencies to the forefront of supply chain security. 

In order to shore up defenses against this emergent threat, Semgrep now provides malicious dependency detection as a generally available feature included with Semgrep Supply Chain.

The Summer of OSS Discontent 

With all eyes on the most recent attack, it’s easy to forget that this is merely the latest in what has been a tumultuous few months for supply chain security. For example, in September 2025, a single npm contributor was compromised by a phishing attack, which resulted in a cryptostealer malware being pushed to a number of npm packages, totalling over 2 billion weekly downloads. 

Within one hour, the attack was picked up by the security community and the packages were removed from npm. Semgrep's security research team immediately followed suit by publishing the following rules for all customers, helping them rapidly detect and remove the malicious packages. 

duckdb@1.3.3
@duckdb/node-api@1.3.3
@duckdb/node-bindings@1.3.3
@duckdb/duckdb-wasm@1.29.2

Still, that was just one of 3 supply chain attacks in 2 weeks: in total these attacks have shaken the AppSec world, and reminded everyone of the risk implicit in the use of open source packages—if imported code is not scanned for malicious dependencies. The most recent worm attack put that reminder in big, bold, flashing letters.

What are Malicious Dependencies?

Malicious dependencies are third-party code libraries, packages, or modules that you intentionally include in your project but which contain hidden, harmful functionality designed to steal data, damage systems, or take control of your software.

Unlike typical third party vulnerabilities that result from outdated versions of open source dependencies, malicious dependencies are software packages, or package versions, that are actually designed for nefarious purposes. These include, but are not limited to, stealing data, inserting backdoors, or breaking functionality when used in an application.

What makes malicious dependencies particularly threatening is that they are disguised as legitimate components, typically entering through trusted package ecosystems like npm, PyPI, and Maven Central. Attackers exploit the openness of these platforms and the speed at which developers adopt third-party code. Once published, even briefly, a harmful package can spread across countless downstream projects.

Think of it like hiring a contractor to build a room in your house, but that contractor secretly installs a backdoor, copies all your keys, or siphons money from your bank account. You invited them in, trusting they would only do the job you asked, but they abused that trust. 

In-Depth Explanation

Modern software is built on a foundation of open-source components. Developers use package managers (like npm for JavaScript, pip for Python, Maven for Java, or NuGet for .NET) to easily pull in these dependencies, saving significant time and effort.

Malicious dependencies exploit this ecosystem and trust model. They can be introduced in several ways:

How They Get Into Your Project

• Typosquatting: Attackers publish packages with names very similar to popular ones (e.g., lodash vs. Iodash with a capital 'i', or requrest instead of request). A developer makes a simple typo during installation and gets the malicious package.

• Brandjacking/Namespace Squatting: Creating a package that appears to be associated with a well-known company or project.

• Compromised Legitimate Packages: A popular, legitimate package is taken over by an attacker (e.g., through a hijacked maintainer account) and a malicious update is pushed to all its users.

• Dependency Chain Attacks (Supply Chain Attacks): You install a legitimate package "A," which depends on a package "B," which in turn depends on a malicious package "C." You never directly chose to install "C," but it's now in your project. This is the most common and insidious path.

• Open-Source Maintainer Sabotage: In rare cases, a disgruntled maintainer of a legitimate package intentionally adds malicious code to their own project.

What They Do (The Malicious Payload)

Once installed and run, the malicious code can execute a wide range of harmful actions:

• Data Theft:

  • Steal environment variables (which often contain API keys, database passwords, and other secrets).

  • Read files from the system (e.g., SSH keys, configuration files, source code).

  • Capture user data from your application (like login credentials or credit card numbers).

• Cryptocurrency Mining (Cryptojacking): Use your server's CPU resources to mine cryptocurrency for the attacker's benefit, slowing down your application and increasing your infrastructure costs.

• Backdoors and Remote Access: Establish a persistent connection to an attacker-controlled server, allowing them to run arbitrary commands on your system.

• Code Obfuscation: The malicious code is often heavily obfuscated (scrambled) to avoid detection by automated security scanners and human reviewers.

• Dependency Confusion / Substitution Attacks: In corporate environments, a malicious package with the same name as an internal, private package is published to a public registry. The build system might accidentally pull the public, malicious version instead of the intended internal one.

Our approach to malicious dependency detection

Malicious packages are designed to evade detection. With most AppSec teams still struggling to solve the primary, yet unwieldy problem of getting vulnerability backlogs under control, tackling the threat of malicious dependencies has historically fallen outside their typical purview. In many cases, given how rare these types of incidents used to be, many organizations would rely on tools like their endpoint (EDR), or extended detection and response (XDR) systems to flag these threats.

The limitation of this approach, however, is that the new wave of self-replicating worms, for example, would have already proliferated across an organization’s codebase by the time the latter tools can detect them. This is why it’s crucial that known bad packages be weeded out during build time—before they infiltrate prod. Malicious dependency detection offloads from customers the onus of implementing an adequate defence against this strain of supply chain attacks, bringing Semgrep’s security expertise to bear on the problem.

To do this, we leverage the power of the security community. We start by integrating data from OSV.dev, the world’s largest distributed database of malicious packages, where data typically appears within minutes to a few hours of being reported and confirmed in a source database. This allows us to leverage continuously aggregated advisories published by organizations like GitHub Security Lab, OpenSSF, and Google's own security teams, as well as data from PyPI Advisory Database and the GitHub Security Advisory Database, which helps to ensure rapid updates.

On top of that, we also continuously monitor external sources like X, and security communities on Slack, among others, for major security incidents and malicious package reports. The security team generates rules that protect your environment against the latest threats, so that when a compromised dependency is installed, it’s quickly flagged by Semgrep. We presently have over 80,000 rules for the detection of malicious packages, with new rules being added continually. What this means in the real world is that, to date, we have responded to all major open source malware attacks in under 4 hours.

What it looks like for you

In the case of duckdb, mentioned in the opening, the malicious dependency findings looked like this:

Basically, once the rule got published, Semgrep Supply Chain users could see findings from malicious dependencies in the Dependencies tab, and the rules for those malicious dependencies in the Advisories tab. AppSec teams were able to filter specifically for malicious dependency findings or for security advisories related to malicious dependencies.

What’s New for GA?

We’ve taken the feedback from our beta customers, and along with major performance improvements, added some cool new functionality as well:

Policies

Of all the improvements over beta, the addition of dependency is malicious as a supply chain policy condition was the most requested feature from our customers, and is probably the most impactful. With the ability to select all, or a subset of projects, and configure parameters like transitivity and CVE, in a few clicks teams can block malicious code from being introduced into production.

API integration

While displaying security findings in a UI is common, exposing them via an API unlocks powerful automation and integration possibilities that are essential for modern DevOps and security practices.

As part of the GA release, malicious dependency detection now includes the ability to use a is_malicious query parameter via the API to filter only malicious dependencies to the /findings endpoint.

The ability to hook malicious dependency findings into any tool we don't natively support—for example, in-house reporting, other ticketing systems besides Jira, or a vulnerability management system—can transform dependency management from a manual, siloed function into an integrated, automated, and data-driven practice that can keep pace with modern development.

Jira Integration

Using Jira tickets to manage security findings is a foundational practice for bridging the gap between security teams and development teams. It brings structure, accountability, and traceability to the vulnerability management process.

While typical vulnerabilities only really matter on the main branch, malicious package findings are almost always critical, and thus need to be prioritized even on non-primary branches. As an extension of our Jira integration, Semgrep Supply Chain customers will now get a dedicated checkbox to create tickets for malicious dependencies on any branch, helping security teams quickly review incoming automated findings on their Jira board, and set the correct priority and assignee before the development team even sees them.

Using Jira for malicious dependency findings helps operationalize vulnerability management, transforming abstract security risks into concrete, actionable, and trackable work items that integrate seamlessly into the development lifecycle.

Protect yourself now from open source malware attacks

The introduction of malicious dependency detection as a generally available feature for all Semgrep Supply Chain customers is a major step forward that covers a serious gap among many teams. But the repeated attacks over the last few months ominously point to a new normal where embedded malignant packages can wreak havoc on organizations. So Semgrep will continue to invest in this area with the aim of making future attacks as pain-free for our customers as possible. For more information on how to configure policies, as well as incident response guidelines, check out the docs page.