Blocking malicious open source dependencies in pull requests with Minder and OSV.dev

Most teams today use vulnerability scanners to find CVEs in their open source dependencies. While avoiding dependencies with known vulnerabilities is important, these scanners may neglect to flag malicious or deprecated packages that don’t have any CVEs, even though these packages may pose an even greater threat to your supply chain. 

As of today, you can now use Minder, Stacklok's software supply chain security platform, to flag and block pull requests that contain malicious or deprecated packages. You may choose to combine this with your preferred vulnerability scanning tool, or use Minder's native capability to flag and block pull requests that contain dependencies with known vulnerabilities, so that unsafe dependencies are never merged into your code.

In this post, we'll explain more about how Minder can flag and block unsafe dependencies in your PRs using data from the open source OSV.dev project, and walk you through how to do this.

Background: Strengthening dependency security in Minder

Malicious dependencies allow hostile actors to execute code they control wherever your application runs, giving them access to computing resources and bypassing any security measures you may have set up. A good example of malware injection is the recent XZ Utils vulnerability, where a backdoor was obfuscated and introduced into a dependency relied upon by critical, widely used software such as SSH. Meanwhile, deprecated packages have no maintainers to keep versions up-to-date and patch any CVEs that could arise in the future; they’re also prime candidates for hostile takeovers. 

That’s why we’ve added support in Minder to scan and block pull requests that contain malicious and deprecated packages. To do this, we're ingesting data on malicious packages from the open source OSV.dev project, as well as data on deprecated packages from the package registries that support this today (including npm and Python). Our goal is to help you catch these unsafe dependencies in your pull requests so that they can't be inadvertently merged into your code.

“When we founded the OSV Project and the OSV Schema, our goal was to enable automated, accurate, and distributed management of vulnerabilities in OSS dependencies in a developer-centric way. So it's great to see that Stacklok is using OSV to help developers automatically detect malicious and unsafe dependencies before they merge their code.”

Oliver Chang

Co-founder, OSV; Senior Manager, Google Open Source Security Team

Supporting the open source OSV.dev Project and OSV Schema

OSV is an open source project created and sponsored by Google. It helps improve open source security by aligning on a standardized format for vulnerability data that can be used by both vulnerability database producers and open source consumers. It consists of two parts: 

• The OSV Schema (now an OpenSSF project), a standardized schema for vulnerabilities and malicious packages reporting that has been adopted by multiple reporting databases encompassing 24 ecosystems, including GitHub, many language ecosystems, and several Linux distributions such as Ubuntu.

• Reference infrastructure (including the OSV.dev site, API, and tooling) that aggregates and indexes vulnerability data from databases that use the OSV schema.

Aligning on a standard schema for vulnerabilities and malicious packages reporting makes it easier for developers and security teams to automate and triage vulnerability reporting; they don’t have to have different processes for different language ecosystems. You can learn more about the OSV project here.

How Minder uses OSV data to flag and block known malicious packages

Let’s walk through the process of how we’re ingesting data from OSV about malicious packages; flagging those packages; and then allowing you to block PRs that contain them.  

Ingesting and analyzing data on malicious packages

Stacklok’s free-to-use web app, Trusty, provides data and scoring on the supply chain risk of open source packages. It includes packages from five different ecosystems (Python, JavaScript, Java, Go, and Rust). 

Trusty regularly ingests data from OSV.dev to determine whether any of these open source packages have been reported to be malicious. When a package is reported as such, Trusty does three things:

1. It automatically gives those packages a score of “0” to indicate high risk

2. It adds a flag at the top of the page to warn developers that the package is not safe to use

3. It suggests alternative packages that are safer to use

An example of a malicious package flagged in Trusty

Using Trusty data to block PRs with malicious and deprecated packages

Minder now includes a managed policy template that enables you to block pull requests that contain malicious and/or deprecated packages, based on data from Trusty. With Minder, you can apply this policy template consistently across all of your project repos so that your team is always protected from inadvertently merging unsafe code. 

Here’s an example of what this policy looks like, customized for JavaScript projects:

---
version: v1
type: profile
name: malicious-dependencies
display_name: Flag and block malicious dependencies
context:
  provider: github
alert: "on"
pull_request:
  - type: pr_trusty_check
    def:
      action: review # Enable minder to review pull requests
      ecosystem_config:
        - name: npm
          score: 5
          allow_malicious: false

Note that this policy requires the latest version of the pr_trusty_check rule type to be installed. 

Now let’s take a look at what the developer sees in the pull request when this policy is in place. Minder will flag the malicious packages in the PR, and include contextual data informing the project developers of any known details about the bad packages:

Example PR comment in Minder, flagging malicious dependencies

Using Minder to block PRs containing dependencies with known vulnerabilities

As mentioned at the start of this post, many organizations use vulnerability scanners to identify dependencies with known vulnerabilities. In addition to configuring Minder to block PRs with malicious or deprecated packages, you can also use Minder to enforce the following actions:

• Block and comment on PRs containing dependencies with known vulnerabilities (using data from OSV.dev); automatically request changes to upgrade to new versions, whenever possible

• Comment on PRs containing dependencies that pose a high supply chain risk, based on their Trusty score (calculated on factors including repo and author activity levels and verifiable proof of origin / Sigstore provenance)

The easiest way to do this is to use Minder’s managed policy template for Dependency Security. In Minder's UI, policy templates can be applied in one click across all of your repositories, to easily keep your projects protected.

Above: Minder's managed policy template for Dependency Security, as applied in the UI

Here’s an example of what the developer sees after you’ve applied this policy template. When it finds dependencies with known vulnerabilities, Minder will comment on PRs with a “vulnerability report” like below:

Whenever possible, Minder also aims to save you time by automatically requesting a change to upgrade to a version with no known vulnerabilities: 

Next Steps

We want to continue to expand our ability to flag risky dependencies in your pull requests. For example, our roadmap includes adding a policy in Minder to block and/or add comments to pull requests based on the licenses of the dependencies they import. 

Minder's code base is open source, so feel free to open an issue for any features you'd like to see next, or send us a message in Discord.