How the dependency graph recognizes dependencies

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 de envio de dependência	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 Ecossistemas de pacotes com suporte a gráficos de dependência.

In the background, automatic dependency submission runs a GitHub Actions workflow that generates the complete tree and uploads it using the API de envio de dependência. 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 executores avançados.

To enable automatic dependency submission, see Configuração do envio automático de dependência para o repositório.

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 de envio de dependência

You can call the API de envio de dependência 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 de envio de dependência 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.

Você pode usar a API REST para enviar dependências para um projeto. Isso permite que você adicione dependências, como aquelas resolvidas quando o software é compilado ou criado, ao recurso de gráfico de dependências do GitHub, fornecendo uma visão mais completa de todas as dependências do seu projeto.

O gráfico mostra todas as dependências que você envia usando a API, além de quaisquer dependências identificadas por meio de arquivos de manifesto ou de bloqueio no repositório (por exemplo, um arquivo package-lock.json em um projeto JavaScript). Para obter mais informações sobre exibição do grafo de dependência, confira Explorar as dependências de um repositório.

As dependências enviadas receberão Dependabot alerts e Dependabot security updates para quaisquer vulnerabilidades conhecidas. Você só obterá os Dependabot alerts das dependências de um dos ecossistemas compatíveis com o GitHub Advisory Database. Para saber mais sobre esses ecossistemas, confira Sobre o banco de dados de avisos do GitHub. Para dependências transitivas enviadas por meio de API de envio de dependência, o Dependabot abrirá automaticamente solicitações de pull para atualizar a dependência pai, se uma atualização estiver disponível.

As dependências enviadas serão mostradas na revisão de dependência, mas não estão disponíveis nos insights de dependência da sua organização.

For more information, see Usar a API de envio de dependências.

Prioritization

O grafo de dependência pode aprender sobre dependências de três maneiras diferentes: análise estática, envio automático e envio manual. Um repositório pode ter vários métodos configurados, o que pode fazer com que o mesmo manifesto do pacote seja verificado várias vezes, potencialmente com saídas diferentes de cada verificação. O grafo de dependência usa a lógica de eliminação de duplicação para analisar as saídas, priorizando as informações mais precisas para cada arquivo de manifesto.

O grafo de dependência exibe apenas uma instância de cada arquivo de manifesto usando as regras de precedência a seguir.

1. Os envios de usuário têm a prioridade mais alta, pois geralmente são criados durante compilações de artefatos que têm as informações mais completas.
   • Se houver vários instantâneos manuais de detectores diferentes, eles serão classificados em ordem alfabética por correlator e pelo primeiro usado.
   • Se houver dois correlacionadores com o mesmo detector, as dependências resolvidas serão mescladas. Para obter mais informações sobre correlacionadores e detectores, consulte Pontos de extremidade da API REST para envio de dependências.
2. Os envios automáticos têm a segunda prioridade mais alta, pois também são criados durante compilações de artefato, mas não são enviados pelos usuários.
3. Os resultados da análise estática são usados quando nenhum outro dado está disponível.