Now available in Trusty: Vulnerability and license information for open source packages
We’ve added support in Trusty to include vulnerability and license data for open source packages across five language ecosystems: Python, Rust, Go, Java, and JavaScript. In this post, we’ll walk you through the details of the data we’re now providing, and how you can use it to make safer choices about your open source dependencies.
An example of open source license information in Trusty for react (a JavaScript library)
Open source licenses are generally classified as permissive or “copyleft” licenses. Permissive licenses, like the MIT License or the Apache 2.0 License, give you broad permissions to modify and redistribute the open source code, even using it in your closed source or proprietary software projects. Conversely, copyleft licenses like GNU GPL generally only let you modify and redistribute the open source code if you do not change the distribution terms; the goal is to ensure the code remains open and freely available. It’s important to make sure that, before you use a dependency, you understand whether its license type is compatible with the goals for your project.
How we source open source license data
To display open source license information in Trusty, we pull license data from two sources:
The package’s source code repository, e.g., on github.com
The package manager repository, e.g., npm for JavaScript packages
What is a license’s Blue Oak Council level?
As shown above, Trusty displays information on the Blue Oak Council levels. Blue Oak Council is a nonprofit led by internationally recognized legal experts on open source licensing, including Heather Meeker.
It provides free information about open source software licenses, including a list of permissive licenses rated as Gold, Silver, Bronze, or Lead (with Gold being the most permissive). These ratings are based on the license’s level of permissiveness and legal rigor, and are intended to be used for policy enforcement. Blue Oak suggests that most organizations can comfortably accept software under any license rated Bronze or better, while highly regulated organizations may require Silver or Gold licenses.
In Trusty, we display the Blue Oak Council rating for open source packages to help developers and security engineers understand at a glance how permissive a package’s license is, and whether it’s OK to use that package in their software projects.
What does it mean for a license to be “OSI-approved”?
Trusty displays information about whether a package’s license is approved by the Open Source Initiative, or OSI. OSI provides a widely accepted definition of “open source” that outlines required distribution terms for open source software. Those terms include free redistribution and access to source code, among other factors. OSI-approved licenses have gone through a public review process to ensure that they comply with this definition, allowing software to be freely used, modified, and shared.
Open source packages with licenses that have a Blue Oak rating of Bronze or above and are OSI-approved can provide extra assurance for developers and security teams that the open source code can be freely used, modified, and shared.
Open source vulnerability information in Trusty
Trusty has historically provided data and analysis on open source risk factors, like verifiable proof of origin, repository and author activity levels, and potential supply chain attacks like typosquatting or starjacking. We’ve now added vulnerability information as an additional data point for packages, to help developers avoid taking a dependency that contains high-severity vulnerabilities.
Trusty’s vulnerability data (and data on malicious packages) comes from OSV.dev, an open source vulnerability database and schema created and sponsored by Google.
An example of vulnerability information displayed in Trusty for lodash v.4.17.11
What’s included in Trusty’s vulnerability data
Trusty pulls in the ID, summary information, and severity of each vulnerability, to help developers and security engineers assess whether or not the package is safe to use. Severity levels are from the CVSS scoring system, a vulnerability scoring system designed to provide an open and standardized method for rating vulnerabilities.
What can I do with this data?
Our goal in providing vulnerability and license data in Trusty is to make it easier for developers and security teams to understand whether an open source package is safe to use, and compliant with organizational policies.
Developers: Make safer choices about your open source dependencies
For developers, understanding license and vulnerability information for open source package can help you make a better decision about whether you should include that package in your own software project. For example, if you’re writing code for proprietary software, you’ll need to make sure that you choose dependencies with a permissive license. You can use Trusty to quickly verify that your license has a high Blue Oak Council rating and will allow you to redistribute the code under different terms.
Similarly, if an open source package has vulnerabilities with a severity level of “High” or “Critical,” you’ll likely want to avoid that package (though notably, not all vulnerabilities are actually exploitable). You can use Trusty’s “Alternative Packages” list to find a similar package that doesn’t have high-severity vulnerabilities.
An alternative package suggestion for python-oauth2, a deprecated package
License and vulnerability data is only part of the data that Trusty includes. You can also use Trusty to quickly assess the supply chain risk of a package, based on factors like repo and author activity levels and verifiable proof of origin.
Trusty supply chain risk data for pandas, a popular open source Python library
AppSec and DevSecOps teams: Apply and enforce developer-friendly open source security policies
With Stacklok’s supply chain security platform, Minder, you can use data from Trusty to apply policies that help developers find and fix security issues before they merge their code and shift context.
For example, Minder includes a pre-written policy (or “rule type”) that can flag pull requests that introduce dependencies with known CVEs; known malicious or deprecated status; or low Trusty scores, indicating a supply chain risk. Developers will experience this as a comment on their pull request with details about the dependency’s risk, and suggested alternatives for safer packages to use, so they can fix the issue before merging.
An example of an automated comment on a pull request from Minder, indicating that a dependency in the code that the developer is trying to merge has a low Trusty score and is marked as deprecated.
We hope these new features in Trusty will help you find safer open source dependencies! Here's how you can get started with these features now:
Visit trustypkg.dev to view vulnerability and license information and supply chain risk for open source packages.
