About the dependency graph
The dependency graph is a summary of the manifest and lock files stored in a repository and any dependencies that are submitted for the repository using the dependency submission API. For each repository, it shows dependencies, the ecosystems and packages it depends on.
For each dependency, you can see the vulnerability severity. You can also search for a specific dependency using the search bar. Dependencies are sorted automatically by vulnerability severity.
GitHub Enterprise Server does not retrieve license information for dependencies, and does not calculate information about dependents, the repositories and packages that depend on a repository. For more information, see "About the dependency graph."
In this article, you can see what the supported ecosystems are.
Supported package ecosystems
The recommended formats explicitly define which versions are used for all direct and all indirect dependencies. If you use these formats, your dependency graph is more accurate. It also reflects the current build set up and enables the dependency graph to report vulnerabilities in both direct and indirect dependencies.
Package manager | Languages | Recommended formats | All supported formats |
---|---|---|---|
Cargo | Rust | Cargo.lock | Cargo.toml , Cargo.lock |
Composer | PHP | composer.lock | composer.json , composer.lock |
NuGet | .NET languages (C#, F#, VB), C++ | .csproj , .vbproj , .nuspec , .vcxproj , .fsproj | .csproj , .vbproj , .nuspec , .vcxproj , .fsproj , packages.config |
GitHub Actions workflows | YAML | .yml , .yaml | .yml , .yaml |
Go modules | Go | go.mod | go.mod |
Maven | Java, Scala | pom.xml | pom.xml |
npm | JavaScript | package-lock.json | package-lock.json , package.json |
pip | Python | requirements.txt , pipfile.lock | requirements.txt , pipfile , pipfile.lock , setup.py |
pnpm | JavaScript | pnpm-lock.yaml | package.json , pnpm-lock.yaml |
pub | Dart | pubspec.lock | pubspec.yaml , pubspec.lock |
Python Poetry | Python | poetry.lock | poetry.lock , pyproject.toml |
RubyGems | Ruby | Gemfile.lock | Gemfile.lock , Gemfile , *.gemspec |
Swift Package Manager | Swift | Package.resolved | Package.resolved |
Yarn | JavaScript | yarn.lock | package.json , yarn.lock |
Notes:
-
If you list your Python dependencies within a
setup.py
file, we may not be able to parse and list every dependency in your project. -
GitHub Actions workflows must be located in the
.github/workflows/
directory of a repository to be recognized as manifests. Any actions or workflows referenced using the syntaxjobs[*].steps[*].uses
orjobs.<job_id>.uses
will be parsed as dependencies. For more information, see "Workflow syntax for GitHub Actions." -
Dependabot will only create Dependabot alerts for vulnerable GitHub Actions that use semantic versioning. You will not receive alerts for a vulnerable action that uses SHA versioning. If you use GitHub Actions with SHA versioning, we recommend enabling Dependabot version updates for your repository or organization to keep the actions you use updated to the latest versions. For more information, see "About Dependabot alerts" and "About Dependabot version updates."
Package ecosystems supported via dependency submission actions
You can use the dependency submission API to add build-time dependencies to the dependency graph, or to add dependencies from package managers and ecosystems of your choice to the dependency graph, even if the ecosystem is not in the supported ecosystem list above. Dependency information from these submitted dependencies will, in turn, flow into Dependabot updates and Dependabot alerts.
Dependencies submitted to a project using the dependency submission API will show which detector was used for their submission and when they were submitted. For more information on the dependency submission API, see "Using the dependency submission API."
You typically use the dependency submission API in a GitHub Actions workflow to submit dependencies for your project when your project is built. The simplest way to use the dependency submission API is by adding a pre-made action to your repository that will gather and convert the list of dependencies to the required snapshot format and submit the list to the API. You can find links to the currently available actions in the table below.
Ecosystem | Action |
---|---|
Go | Go Dependency Submission |
Gradle | Gradle Dependency Submission |
Maven | Maven Dependency Tree Dependency Submission |
Mill | Mill Dependency Submission |
Scala | Sbt Dependency Submission |
NuGet and others | Component Detection dependency submission action |
Note: For the Component Detection dependency submission action, other supported ecosystems include Vcpkg, Conan, Conda, Crates, as well as NuGet.
For example, the following Go Dependency Submission workflow calculates the dependencies for a Go build-target (a Go file with a main
function) and submits the list to the dependency submission API.
name: Go Dependency Submission
on:
push:
branches:
- main
# The API requires write permission on the repository to submit dependencies
permissions:
contents: write
# Environment variables to configure Go and Go modules. Customize as necessary
env:
GOPROXY: '' # A Go Proxy server to be used
GOPRIVATE: '' # A list of modules are considered private and not requested from GOPROXY
jobs:
go-action-detection:
runs-on: ubuntu-latest
steps:
- name: 'Checkout Repository'
uses: actions/checkout@v4
- uses: actions/setup-go@v5
with:
go-version: ">=1.18.0"
- name: Run snapshot action
uses: actions/go-dependency-submission@v1
with:
# Required: Define the repo path to the go.mod file used by the
# build target
go-mod-path: go-example/go.mod
#
# Optional. Define the repo path of a build target,
# a file with a `main()` function.
# If undefined, this action will collect all dependencies
# used by all build targets for the module. This may
# include Go dependencies used by tests and tooling.
go-build-target: go-example/cmd/octocat.go
You can also create your own action. For more information, see "Using the dependency submission API."