The dependency graph can identify your project's dependencies using the following methods.
| Method | How it works |
|---|---|
| Static analysis | Parses manifest and lock files in your repository |
| Dependabot graph jobs | Uses a Dependabot GitHub Actions workflow to generate dependency snapshots |
| Automatic submission | Runs a built-in GitHub Actions workflow to resolve build-time dependencies |
| API отправки зависимостей | Accepts 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, or when a dependency changes in its own repository.
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. In addition, indirect dependencies inferred from manifest files (rather than lock files) are excluded from vulnerability checks.
Automatic dependency submission
Some ecosystems resolve indirect dependencies at build time, so static analysis can't see the full dependency tree. When you enable automatic dependency submission for a repository, GitHub automatically identifies the transitive dependencies in the repository for supported ecosystems. See Поддерживаемые экосистемы пакетов графа зависимостей.
In the background, automatic dependency submission runs a GitHub Actions workflow that generates the complete tree and uploads it using the API отправки зависимостей. Automatic dependency submission runs on GitHub-hosted runners by default and counts toward your GitHub Actions minutes. Optionally, you can choose to run it on self-hosted runners or более крупные бегуны.
To enable automatic dependency submission, see Настройка автоматической отправки зависимостей для репозитория.
Dependabot graph jobs
This method uses a special type of Dependabot job that builds a dependency snapshot and uploads it to the dependency submission API. This is currently only supported for Go dependencies.
This approach is similar to automatic dependency submission, but does not incur charges for GitHub Actions minutes. It can also access organization-wide configurations for private registries you've set up for Dependabot.
The API отправки зависимостей
You can call the 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 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.
Rest API можно использовать для отправки зависимостей для проекта. Так вы сможете добавлять зависимости, например разрешаемые при компиляции или сборке программного обеспечения, в функцию графа зависимостей GitHub, чтобы создать более полную картину всех зависимостей проекта.
На графе зависимостей отображаются все зависимости, которые вы отправили через этот API, а также те, которые определены в файлах манифеста или блокировки, размещенных в репозитории (например, файл package-lock.json в проекте JavaScript). Дополнительные сведения о просмотре граф зависимостей см. в разделе Изучение зависимостей репозитория.
Отправленные зависимости будут получать Dependabot alerts и Dependabot security updates по всем известным уязвимостям. Вы получите только Dependabot alerts для зависимостей, которые находятся из одной из поддерживаемых экосистем для GitHub Advisory Database. Дополнительные сведения об этих экосистемах см. в разделе Сведения о базе данных GitHub Advisory. Для транзитивных зависимостей, отправленных через API отправки зависимостей, Dependabot автоматически открывает запросы на вытягивание для обновления родительской зависимости, если обновление доступно.
Отправленные зависимости будут отображаться в проверке зависимостей, но недоступны в аналитике зависимостей вашей организации.
Примечание.
API проверки зависимостей и API отправки зависимостей работают вместе. Это означает, что API проверки зависимостей будет включать зависимости, отправленные через API отправки зависимостей.
For more information, see Использование API отправки зависимостей.
Prioritization
Граф зависимостей может узнать о зависимостях тремя разными способами: статический анализ, автоматическую отправку и отправку вручную. Репозиторий может иметь несколько методов, которые могут привести к проверке одного манифеста пакета несколько раз, потенциально с разными выходными данными для каждой проверки. Граф зависимостей использует логику дедупликации для анализа выходных данных, приоритетизируя наиболее точные сведения для каждого файла манифеста.
Граф зависимостей отображает только один экземпляр каждого файла манифеста, используя следующие правила приоритета.
- Отправки пользователей имеют наивысший приоритет, так как они обычно создаются во время сборки артефактов, у них есть самая полная информация.
- Если есть несколько моментальных снимков вручную из разных детекторов, они сортируются по алфавиту по коррелятору и первому используемому.
- Если есть два коррелятора с одинаковым детектором, разрешенные зависимости объединяются. Дополнительные сведения о корреляторах и детекторах см. в разделе Конечные точки REST API для отправки зависимостей.
- Автоматическая отправка имеет второй приоритет, так как они также создаются во время сборки артефактов, но не отправляются пользователями.
- Результаты статического анализа используются, если другие данные недоступны.