Enterprise Server 3.20 is currently available as a release candidate.

How the dependency graph recognizes dependencies

The dependency graph automatically analyzes manifest files. You can submit data for dependencies that cannot be detected automatically.

Who can use this feature?

The dependency graph is available for all repositories.

In this article

The dependency graph can identify your project's dependencies using the following methods.

MethodHow it works
Static analysisParses manifest and lock files in your repository
Dependency submission APIAccepts dependency data you submit programmatically

Once dependencies are in the graph, you can receive Dependabot alerts and Dependabot security updates for any known vulnerabilities.

Static analysis

When you enable the dependency graph, GitHub scans your repository for supported manifest files and parses each package's name and version. The graph updates when you change a supported manifest or lock file on your default branch.

Static analysis can identify:

  • Direct dependencies explicitly defined in a manifest or lock file
  • Indirect dependencies—dependencies of these direct dependencies, also called "transitive dependencies"—but only if they are defined in a manifest or lock file, not if they are resolved at build time

For the most reliable graph, you should use lock files (or their equivalent), because they define exactly which versions of the direct and indirect dependencies you currently use. Lock files also ensure that all contributors to the repository are using the same versions, which will make it easier for you to test and debug code.

The dependency submission API

You can call the dependency submission API in your own script or workflow. This is useful if:

  • You need to submit transitive dependencies that cannot be detected from lock files.
  • You need to create custom logic or are using an external CI/CD system.

Dependencies are submitted to the dependency submission API in the form of a snapshot. This is a list of dependencies associated with a commit SHA and other metadata, reflecting the current state of your repository.

If you are calling the API in a GitHub Actions workflow, you can use a pre-made action for your ecosystem that automatically gathers the dependencies and submits them to the API. Otherwise, you can write your own action or call the API from an external system.

Submitted dependencies are not available in your organization's dependency insights.

For more information, see Using the dependency submission API.

Prioritization

A repository can use multiple methods for dependency submission, which can cause the same package manifest to be scanned multiple times, potentially with different outputs from each scan. Dependency graph uses deduplication logic to parse the outputs, prioritizing the most accurate information for each manifest file.

Dependency graph displays only one instance of each manifest file using the following precedence rules.

  1. User submissions take the highest priority, because they are usually created during artifact builds they have the most complete information.
    • If there are multiple manual snapshots from different detectors, they are sorted alphabetically by correlator and the first one used.
    • If there are two correlators with the same detector, the resolved dependencies are merged. For more information about correlators and detectors, see REST API endpoints for dependency submission.
  2. Automatic submissions have the second-highest priority since they are also created during artifact builds, but are not submitted by users.
  3. Static analysis results are used when no other data is available.