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의 종속성 그래프 기능에 추가하여 프로젝트의 모든 종속성을 보다 완벽하게 파악할 수 있습니다.
종속성 그래프는 리포지토리의 매니페스트 또는 잠금 파일(예: JavaScript 프로젝트의 package-lock.json 파일)에서 식별되는 종속성 외에 API를 사용하여 제출하는 모든 종속성을 보여 줍니다. 종속성 그래프 보기에 대한 자세한 내용은 리포지토리의 종속성 탐색을(를) 참조하세요.
제출된 종속성은 알려진 취약성에 대해 Dependabot alerts 및 Dependabot security updates를 받게 됩니다. GitHub Advisory Database의 지원되는 에코시스템 중 하나에서 발생한 종속성에 대한 Dependabot alerts만 가져옵니다. 이러한 에코시스템에 대한 자세한 내용은 GitHub 권고 데이터베이스에 관한 정보을(를) 참조하세요. 종속성 제출 API을(를) 통해 제출된 전환 종속성의 경우 업데이트를 사용할 수 있으면 Dependabot에서 자동으로 끌어오기 요청을 열어 상위 종속성을 업데이트합니다.
제출된 종속성은 조직의 종속성 인사이트에서는 사용할 수 없습니다.
For more information, see 종속성 제출 API 사용.
Prioritization
종속성 그래프는 정적 분석, 자동 제출, 수동 제출이라는 세 가지 방법으로 종속성에 대해 알아볼 수 있습니다. 하나의 리포지토리에 여러 스캔 방식이 구성되어 있을 수 있으며, 이로 인해 동일한 패키지 매니페스트가 여러 번 스캔될 수 있으며, 각 스캔마다 서로 다른 결과가 나올 수 있습니다. 종속성 그래프는 중복 제거 논리를 사용하여 출력을 구문 분석하여 각 매니페스트 파일에 대해 가장 정확한 정보의 우선 순위를 지정합니다.
종속성 그래프는 다음 우선 순위 규칙을 사용하여 각 매니페스트 파일의 인스턴스를 하나만 표시합니다.
- 사용자 제출은 일반적으로 아티팩트 빌드 중에 생성되며, 가장 완전한 정보를 포함하고 있기 때문에 가장 높은 우선 순위를 갖습니다.
- 서로 다른 감지기의 수동 스냅샷이 여러 개 있는 경우, 관련자 및 사용된 첫 번째 스냅샷을 기준으로 사전순으로 정렬됩니다.
- 동일한 감지기를 사용하는 두 개의 관련자가 있는 경우, 해결된 종속성이 병합됩니다. 관련자 및 감지기에 대한 자세한 내용은 종속성 제출에 대한 REST API 엔드포인트을(를) 참조하세요.
- 자동 제출은 아티팩트 빌드 중에 생성되지만 사용자가 제출하지는 않기 때문에 두 번째로 높은 우선 순위를 갖습니다.
- 정적 분석 결과는 다른 데이터를 사용할 수 없는 경우에 사용됩니다.