Shifting supply chain security left with dependency review

Anywhere from 65-94% of active repos rely on open source code, with the variability depending on the ecosystem, according to the State of the Octoverse 2020 report, we know that although a repo might only have a handful of direct dependencies, it has many hidden, indirect dependencies-with JavaScript being the clear winner with a median 683 transitive dependencies. So. Many. Dependencies.

Given that the use of open source isn’t slowing down any time soon, you need to feel confident in what you’re consuming as part of your software supply chain. To do this, you need transparency as to which dependencies you have, and what’s in them.

Dependency review is a new GitHub Advanced Security feature released this year at Universe that allows you to easily understand your dependencies before you introduce them to your environment. As part of a pull request, you can see what dependencies you’re introducing, changing, or removing, and information about their vulnerabilities, age, usage, and license.

In this post, we’ll dig into how dependency review works, and how you can use it to help reduce risky dependencies in your environment while shifting security left.

Understanding your dependencies ensures you understand potential risks they introduce to your environment

Dependencies can be risky. Dependencies are not code you wrote, so you don’t really know what’s in them-kind of a mystery ground meat from the local supermarket. You should be fine, right?

Not all dependencies are created equal-and many open source contributors do an awesome job in developing and maintaining packages, including actively responding to security reports. There are several risks you might encounter when introducing dependencies to your environment that you’ll want to be aware of:

• Vulnerabilities: If your dependency has known vulnerabilities, well, maybe you should update it to a patched version.
• Other security risks: A dependency might have properties that make it more susceptible to being attacked, or harder to detect an attack. For example, if the maintainer doesn’t have two-factor authentication (2FA) enabled, it is easier for a malicious actor to take over their account and modify the dependency.
• Legal and compliance risks: You may be restricted in how you use the dependency, to ensure that you’re in line with what’s specified in the license.
• Maintenance risks: If a dependency is no longer supported, or not widely used or contributed to, you may want to consider a viable alternative.

To help assuage these fears and determine your risk profile, you’ll want to know as much as you can about a given dependency. This could include, for a given dependency: who wrote it, when it was contributed, how it’s been reviewed for security issues, any known vulnerabilities, supported versions, license information, and much more. But that’s just a given dependency-and if you have hundreds of these, it’s hard to track down this information and review it.

GitHub already finds vulnerable dependencies in your environment with Dependabot

To understand and manage your dependencies on GitHub, you can use dependency graph and Dependabot. Dependency graph identifies all upstream dependencies and public downstream dependents of a repository or package. Then based on vulnerability information from GitHub’s Advisory Database, Dependabot sends you an alert and when possible an update, to make it easier for you to apply a patch to your environment.

When you introduce a new dependency to your environment, it’s automatically added to the dependency graph. If you’re unlucky and that dependency has a vulnerability, then Dependabot will let you know. But wait, couldn’t we have prevented this altogether? Ideally, you’d catch the vulnerability before it’s added to your environment.

Dependency review helps you catch vulnerabilities before they’re introduced

If you’ve ever reviewed a pull request that changes a dependency manifest file, however, such as a package.json or package-lock.json, then you know how difficult it can be to see exactly what changed. People aren’t great JSON, XML, or even YAML parsers-and you shouldn’t be expected to parse this information yourself.

With Dependency review, in a GitHub pull request modifying a manifest file, the files changed view now natively gives you information on which dependencies you’re adding, modifying, or changing. For each dependency, you also have:

• Vulnerability information, for vulnerabilities in that dependency version, including severity and whether a newer, patched version exists,
• Age of the dependency, which can help identify when you need to update,
• Usage, in the number of dependents a dependency has in the dependency graph, which can help identify when you’re using a less common dependency, and
• License information for the dependency.

Dependency review works by comparing dependency manifests for both the destination branch and the branch you’re merging. These are the same manifests that power the dependency graph. In a pull request, we compare the manifests to identify what’s changed, and combine that with package metadata and vulnerability information from the GitHub Advisory Database. This process repeats whenever the pull request is updated or the destination branch is updated, so you’ll always understand the impact of a pull request on dependencies.

Dependency review helps you shift supply chain security left

Shifting left is a change to move validation processes to earlier in the development lifecycle, where development teams are, so that they can take action before changes are applied to their environment. By moving steps like testing, including security testing, from a final gate at deployment time to an earlier step, fewer mistakes are made, and developers can move more quickly.

By reviewing dependencies in a pull request, before merging, you can shift supply chain security left. Rather than Dependabot alerts notifying you of a vulnerability after you’ve introduced it to your environment, you can catch it before introducing it with dependency review. However, you still need both-after all, Dependabot alerts also notify you of new vulnerabilities that are discovered in existing dependencies. And Dependabot updates already help you shift left today, sending you pull requests, for both security and version updates. Instead of leaning on the security team using an issue to track progress, there’s already a pull request for the development team to review.

Try it out

Dependency review beta is now available for all GitHub Enterprise Cloud (GHEC) customers and will be rolling out for all public repositories over the coming weeks. This feature is free for public repositories and part of GitHub Advanced Security for GitHub Enterprise customers.

If you have dependency graph enabled, you don’t need to do anything to enable dependency review, it just works. Dependency graph is on for all public repos, and can be enabled for private repos In a repo where you have read access, for a pull request that modifies a manifest file, click on the rich diff to get a new, better view of your dependencies in review.

Learn more in documentation or by watching GitHub Checkout.

Written by

William Bartholomew

@iamwillbar