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 |
| 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.
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 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 автоматически открывает запросы на вытягивание для обновления родительской зависимости, если обновление доступно.
Отправленные зависимости недоступны в аналитике зависимостей вашей организации.
For more information, see Использование API отправки зависимостей.
Prioritization
Граф зависимостей может узнать о зависимостях тремя разными способами: статический анализ, автоматическую отправку и отправку вручную. Репозиторий может иметь несколько методов, которые могут привести к проверке одного манифеста пакета несколько раз, потенциально с разными выходными данными для каждой проверки. Граф зависимостей использует логику дедупликации для анализа выходных данных, приоритетизируя наиболее точные сведения для каждого файла манифеста.
Граф зависимостей отображает только один экземпляр каждого файла манифеста, используя следующие правила приоритета.
- Отправки пользователей имеют наивысший приоритет, так как они обычно создаются во время сборки артефактов, у них есть самая полная информация.
- Если есть несколько моментальных снимков вручную из разных детекторов, они сортируются по алфавиту по коррелятору и первому используемому.
- Если есть два коррелятора с одинаковым детектором, разрешенные зависимости объединяются. Дополнительные сведения о корреляторах и детекторах см. в разделе Конечные точки REST API для отправки зависимостей.
- Автоматическая отправка имеет второй приоритет, так как они также создаются во время сборки артефактов, но не отправляются пользователями.
- Результаты статического анализа используются, если другие данные недоступны.