Creating a more comprehensive dependency graph with build time detection

Closing the Gaps in GitHub’s Dependency Graph

GitHub’s dependency graph has long relied on static analysis of committed manifest files. While effective for many ecosystems, this approach leaves blind spots—particularly for package managers that resolve dependencies at build time or pull in transitive packages that aren’t listed in source files. To address this, GitHub has introduced a new API that lets you upload dependency data directly from your build environment, complementing static scans with runtime information.

Why Static Scans Aren’t Always Enough

The dependency graph only sees what’s declared in checked-in files. For tools like Maven, the pom.xml specifies direct dependencies, but transitive dependencies—which may carry their own vulnerabilities—are absent from the repository. The picture is even more limited for Gradle and sbt, where dependency resolution happens during the build and can vary based on environment conditions or unpinned version ranges. In these cases, a static snapshot of the repository is insufficient for an accurate dependency graph.

Submitting Dependency Data at Build Time

The dependency submission API accepts a straightforward list of dependencies tied to a specific commit SHA. The natural implementation is a GitHub Action in your CI pipeline that sends the build-time dependency set to GitHub. The launch includes an official action for Go, which enables transitive dependency detection for Go projects and delivers a more precise view of your dependencies. Community-built actions for other package managers are expected to follow.

If no ready-made action fits your setup, you can build your own. The API requires submissions in a documented format associated with a commit SHA. The Dependency Submission Toolkit simplifies conversion and submission, helping you create an action tailored to your package manager and repository structure while still yielding the same improved dependency graph.

What Submitted Dependencies Look Like

Once uploaded, the dependency graph displays the most recent set of dependencies submitted to your default branch. If multiple workflows submit dependencies for different package managers, the latest submission from each workflow is included in the graph. Data uploaded this way is treated as the authoritative, current state for those components.

Early Beta and the Roadmap

The dependency submission API is currently in early beta. GitHub is actively developing enhancements, including the ability to view metadata for submitted dependencies, access historical submission records, and reflect submitted dependencies in features like dependency review and dependency insights. Feedback is being collected via GitHub Discussions to shape the API’s evolution.

Getting Started

To integrate build-time dependency reporting into your workflow, refer to the official documentation for API usage details, or begin with the Dependency Submission Toolkit to write your own detector and generate submissions for any package manager.