Why your project’s dependency list is only half the story

Modern software is rarely built from scratch. The manifest file at the root of your project lists the packages you directly include, but each of those packages brings its own dependencies, which in turn depend on other libraries. GitHub engineer Eric Sorenson notes that in some cases, 95–97% of your code is actually someone else’s. GitHub’s dependency graph maps that hidden layer, showing every external package your project touches, both directly and transitively.

The graph treats each package as a node and each dependency relationship as an edge, producing a structured view of your software’s supply chain. That visibility is the foundation for Dependabot alerts: when a vulnerability is disclosed in any package in your tree, GitHub can tell you it’s there, how it got there, and what you can do about it.

Understanding direct versus transitive dependencies

Consider a project with 21 direct dependencies listed in package.json that resolves to roughly 1,000 total dependencies once everything pulled in along the way is counted. The dependency graph helps you distinguish between the two groups:

  • Direct dependencies are the ones you explicitly declare and control.
  • Transitive dependencies arrive as dependencies of your dependencies, often without your direct awareness.

That distinction matters when a vulnerability surfaces. If a library like Log4j ends up in your project, the graph shows whether it was added directly or rode in with another package. That tells you whether the fix is yours to make or depends on an upstream maintainer releasing a patched version.

How Dependabot builds on the graph

Dependabot runs on top of the dependency graph, so enabling the graph is what activates Dependabot’s vulnerability alerts and automatic fix pull requests. When you review alerts, a practical approach is to filter for direct dependencies first. Those are the packages you can actually modify or replace. Transitive dependencies may require waiting for an upstream fix, so prioritize the issues you can act on immediately.

Enabling the dependency graph

The dependency graph is enabled per repository under Security > Dependency Graph in your repository settings. Turning on Dependabot enables the graph automatically.

If your language ecosystem doesn’t support automatic package discovery, community-maintained GitHub Actions can generate a Software Bill of Materials (SBOM) and submit it to GitHub’s Dependency Submission API. The dependency graph and Dependabot alerts are free for all repositories.

The takeaway

You can’t secure what you can’t see. The dependency graph reveals the open source libraries that make up the bulk of your codebase, and it gives Dependabot the information it needs to alert you to known vulnerabilities. Enabling it gives you a realistic picture of your software’s actual footprint—and a means to act on it.