Introducing the Trusty Dependency Risk Action: Automatically scan PRs for unsafe dependencies

We’re excited to introduce the new Trusty Dependency Risk GitHub Action, which can help you automatically check each PR for malicious, deprecated, or otherwise unsafe dependencies, and find safer alternatives. Read on below for more details about how this works. 

Background: About Trusty

Before we get into the details of the new Trusty action, let’s talk more about how Trusty works. Trusty is a free-to-use web app that developers and security engineers can use to look up the supply chain risk of their open source dependencies and find safer alternatives. Trusty indexes millions of open source packages across five language ecosystems, including Go, Java, JavaScript, Rust, and Python. 

At Stacklok, we use Trusty’s supply chain analysis data for threat detection and reporting. For example, last week, our security research team used Trusty data to detect an npm starjacking attack on the Roblox Node.js library. (We were able to report this attack quickly to GitHub’s Trust and Safety team, and they’ve since removed the package from the npm registry.) 

We can use the malicious package mentioned above, noblox-ts, to better understand Trusty.

The image above shows the package noblox-ts listed in Trusty. For each OSS package like this one, we provide data and analysis to help developers understand at a glance whether the package is safe to use. This information includes:

1. Supply chain risk score (Trusty Score): Each open source package indexed in Trusty is given a score, from 0-10. Scoring is based on our analysis of public package data, including repo and author activity; package status; proof of origin (provenance); and whether the package shows characteristics of malicious attacks, like typosquatting. In this case, because noblox-ts is a known-malicious package, its score is automatically lowered to 0. 

2. Malicious, archived, and deprecated package identification: Trusty ingests data on malicious, deprecated, and archived packages from OSV.dev, GitHub repositories, and package managers (like crates or npm). Based on this data, we display a warning on the package’s page in Trusty, like the one shown above, to make sure developers know not to use it. We also automatically assign these packages a “0” score.

3. Alternative packages: With Trusty, we don’t want to just tell developers that a package isn’t safe; we want to make it easier for them to find a safer one. Trusty uses generative AI to identify safer open source alternatives that provide similar functionality, like the reputable “roblox-ts” package in the example above.

How the Trusty Dependency Risk Action works

While trustypkg.dev is a great site to use when you’re researching open source dependencies for your project, we know that developers don’t want to add an additional step to their process. So we created the Trusty Dependency Risk Action to automatically check each PR in your repository to make sure that your dependencies are safe, and to give developers the opportunity to replace an unsafe dependency before they merge their code. 

When the Trusty GitHub Action runs, it will comment on your PR with a report that looks similar to this:

It will outline both failed and successful (e.g., high-scoring) dependencies in your PR, and provide a link back to the package on trustypkg.dev to view the full analysis and alternatives. You’ll be able to see at a glance whether a dependency is malicious, archived, or deprecated, so you can make sure to remove that dependency before merging. 

In the report above, you can see that the “bugsnagmw” package failed because it’s marked as malicious, and the other two packages, “scriptoni” and “notifyjs,” failed because they’re reported to be archived (and in the case of “scriptoni,” also deprecated).  

Within the report, you can also get more details on the package’s scoring dimensions:

If the package was built and signed using Sigstore, you can see confirmation of its source repository and the workflow it was built from:

And finally, for low-scoring packages, you can see a list of alternative packages that you could use:

Using the Trusty Dependency Risk Action

To use the Trusty Dependency Risk Action, you can add the following yaml to your workflow:

name: TrustyPkg Dependency Check

on:
  pull_request:
    branches:
      - main

jobs:
  trusty_pkg_check:
    runs-on: ubuntu-latest
    name: Check Dependencies with TrustyPkg
    steps:
      - name: Checkout code
        uses: actions/checkout@v2
      - name: TrustyPkg Action
        uses: stacklok/trusty-action@v0.0.7
        with:
          global_threshold: 5
          provenance_threshold: 5
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

You can also configure the following inputs, to customize the thresholds for when a dependency is flagged:

• global_threshold: The minimum score required for a dependency to be considered high quality. Anything below this score will fail the action.

• repo_activity_threshold: The minimum score required for a repo to be considered actively maintained. Anything below this score will fail the action.

• author_activity_threshold: The minimum score required for an author to be considered actively maintaining their packages. Anything below this score will fail the action.

• provenance_threshold: The minimum score required for a package to have a proven source of origin. Anything below this score will fail the action.

• typosquatting_threshold: The minimum score required for a package to be considered not typosquatting. Anything below this score will fail the action.

• fail_on_malicious: Whether to fail the action if a package is malicious. Default is true.

• fail_on_deprecated: Whether to fail the action if a package is deprecated. Default is true.

• fail_on_archived: Whether to fail the action if a package is archived. Default is true.

After you’ve added the Trusty action to your repository, it will be triggered every time a pull request is made. The action will check to see if the pull request introduces new dependencies for any of Trusty’s supported package managers (including crates, npm, Maven, PyPI, and go). If a dependency fails based on what you’ve configured above, Minder will block the pull request from being merged and provide a comment on the PR with the report.

Enforcing policy to block unsafe dependencies at an organizational level

Using the Trusty GitHub Action can help you automatically check PRs in a specific repository for unsafe open source dependencies. If you want to enforce this check as a policy at an organization-wide level, you can use Minder Cloud, Stacklok’s software supply chain security platform. 

Minder Cloud includes an out-of-the-box template for dependency security with this policy already in place. The Dependency Security policy template also includes a policy to check and block pull requests that contain dependencies with known vulnerabilities, based on data from OSV.dev. You can apply these policies in one click across all of your organization’s repositories to keep unsafe dependencies out of your production code.

Minder Cloud includes a pre-configured policy for checking pull requests for unsafe dependencies using Trusty data.

We hope that the Trusty GitHub Action and corresponding capability in Minder can make it easier for you to catch malicious, deprecated, and otherwise unsafe dependencies before they’re merged into your production code. If you have any feedback on how we could make this more useful for you, please consider joining our Discord server and letting us know!

Megan Bruce

Director of Product Marketing - Stacklok