Dependency Review: A Closer Look at What You Pull In

Open source underpins the majority of modern software. A single repository may have only a handful of direct dependencies, but transitive dependencies multiply that number quickly. JavaScript repositories, for example, have a median of 683 transitive dependencies, according to the State of the Octoverse 2020 report. That broad reliance means you are consuming far more third-party code than you likely realize — and each layer introduces potential risk.

GitHub's dependency review feature, part of GitHub Advanced Security and announced at Universe 2020, aims to give developers visibility into dependency changes during pull request review. Instead of blindly trusting a manifest diff, you can inspect exactly what a PR introduces, changes, or removes — along with key metadata about each package.

What Makes a Dependency Risky

Not all dependencies are equal. Open source maintainers often do excellent work keeping packages patched and secure, but there are several risk categories to consider before adding a new package:

  • Vulnerabilities: Known security flaws in a dependency version may mean you need to update to a patched release.
  • Security posture: Maintainers without two-factor authentication (2FA) enabled are easier targets for account takeover, making their packages more susceptible to malicious modification.
  • Legal and compliance: License terms may restrict how the dependency can be used in your project.
  • Maintenance: Packages that are no longer supported or lack active contribution may leave you without fixes when issues arise.

Understanding these factors for each dependency manually is impractical at scale. The challenge is having enough context to make informed decisions before pulling code into your environment.

Existing Tools Catch Problems After the Fact

GitHub already offers visibility into your dependency landscape through the dependency graph, which maps upstream and downstream relationships for a given repository. When vulnerability information exists in GitHub's Advisory Database, Dependabot alerts you to affected dependencies and can open automated security updates with patches.

The limitation is timing. New dependencies are added to the dependency graph automatically, and Dependabot alerts surface only after a vulnerable package has already entered your environment. Ideally you would catch the issue during review, before the merge ever happens.

Reviewing Dependencies in Context

Reading a raw package.json or package-lock.json diff is error-prone — humans are not reliable parsers of JSON, XML, or YAML. The dependency review feature addresses this by rendering a rich diff in the pull request view when a manifest file changes.

For each dependency being added, modified, or changed, the review shows:

  • Known vulnerabilities for that version, including severity and whether a patched version is available
  • Age of the dependency, which helps assess whether updates are overdue
  • Usage data, based on number of dependents in the dependency graph, to flag less common packages
  • License information for the dependency

The feature works by comparing the dependency manifests of the destination branch and the branch being merged — the same manifests that power the dependency graph. That comparison identifies exactly what changed, then enriches the results with package metadata and vulnerability data from the GitHub Advisory Database. The process reruns whenever the pull request or its destination branch is updated, so the review always reflects the latest state.

Shifting Supply Chain Security Earlier

Shifting left means moving validation earlier in the development lifecycle, where developers can act on feedback before changes land. Security testing, for example, can happen during development rather than at deployment time. That reduces mistakes and speeds up delivery.

Dependency review applies this principle to supply chain security. Vulnerabilities can be caught while the pull request is still open, instead of being flagged by Dependabot after the code is already in production. The two tools complement one another: Dependabot alerts still matter for vulnerabilities discovered in existing dependencies after they are already in your environment, and Dependabot updates already shift work left by generating pull requests for security and version updates that developers can review directly.

Availability and Setup

Dependency review beta is currently available to all GitHub Enterprise Cloud (GHEC) customers, with rollout to public repositories planned over the following weeks. It is free for public repositories and included with GitHub Advanced Security for enterprise customers.

No configuration is required if the dependency graph is already enabled — the feature works automatically. Dependency graph is enabled by default for public repositories and can be turned on for private ones. For any pull request that modifies a manifest file, you just need read access and the rich diff will show dependency changes in review.