Skip to main content
ドキュメントには頻繁に更新が加えられ、その都度公開されています。本ページの翻訳はまだ未完成な部分があることをご了承ください。最新の情報については、英語のドキュメンテーションをご参照ください。本ページの翻訳に問題がある場合はこちらまでご連絡ください。

このバージョンの GitHub Enterprise はこの日付をもって終了となります: 2022-06-03. 重大なセキュリティの問題に対してであっても、パッチリリースは作成されません。 パフォーマンスの向上、セキュリティの改善、新機能のためには、最新バージョンのGitHub Enterpriseにアップグレードしてください。 アップグレードに関する支援については、GitHub Enterprise supportに連絡してください。

Troubleshooting the detection of vulnerable dependencies

If the dependency information reported by GitHub Enterprise Server is not what you expected, there are a number of points to consider, and various things you can check.

GitHub Enterprise Server によって報告された依存関係の検出結果は、他のツールから返される結果とは異なる場合があります。 これには理由があり、GitHub がプロジェクトの依存関係をどのように決定するかを理解しておくと便利です。

Why do some dependencies seem to be missing?

GitHub generates and displays dependency data differently than other tools. Consequently, if you've been using another tool to identify dependencies you will almost certainly see different results. Consider the following:

  • GitHub Advisory Database is one of the data sources that GitHub uses to identify vulnerable dependencies. It's a free, curated database of vulnerability information for common package ecosystems on GitHub. It includes both data reported directly to GitHub from GitHub Security Advisories, as well as official feeds and community sources. This data is reviewed and curated by GitHub to ensure that false or unactionable information is not shared with the development community. For more information about advisory data, see "Browsing security vulnerabilities in the GitHub Advisory Database" in the GitHub.com documentation.

  • The dependency graph parses all known package manifest files in a user’s repository. For example, for npm it will parse the package-lock.json file. It constructs a graph of all of the repository’s dependencies and public dependents. This happens when you enable the dependency graph and when anyone pushes to the default branch, and it includes commits that makes changes to a supported manifest format. For more information, see "About the dependency graph" and "Troubleshooting the dependency graph."

  • Dependabot scans any push, to the default branch, that contains a manifest file. When a new vulnerability record is added, it scans all existing repositories and generates an alert for each vulnerable repository. Dependabotアラート are aggregated at the repository level, rather than creating one alert per vulnerability. For more information, see "About Dependabotアラート."

  • Dependabot doesn't scan repositories for vulnerable dependencies on a schedule, but rather when something changes. For example, a scan is triggered when a new dependency is added (GitHub checks for this on every push), or when a new vulnerability is added to the advisory database and synchronized to your GitHub Enterprise Server instance. For more information, see "About Dependabotアラート."

Do Dependabotアラート only relate to vulnerable dependencies in manifests and lockfiles?

Dependabotアラート advise you about dependencies you should update, including transitive dependencies, where the version can be determined from a manifest or a lockfile.

Check: Is the uncaught vulnerability for a component that's not specified in the repository's manifest or lockfile?

Why don't I get vulnerability alerts for some ecosystems?

GitHub limits its support for vulnerability alerts to a set of ecosystems where we can provide high-quality, actionable data. Curated vulnerabilities in the GitHub Advisory Database, the dependency graph, and Dependabotアラート are provided for several ecosystems, including Java’s Maven, JavaScript’s npm and Yarn, .NET’s NuGet, Python’s pip, Ruby's RubyGems, and PHP’s Composer. We'll continue to add support for more ecosystems over time. For an overview of the package ecosystems that we support, see "About the dependency graph."

It's worth noting that GitHub Security Advisories may exist for other ecosystems. The information in a security advisory is provided by the maintainers of a particular repository. This data is not curated in the same way as information for the supported ecosystems.

Check: Does the uncaught vulnerability apply to an unsupported ecosystem?

Does Dependabot generate alerts for vulnerabilities that have been known for many years?

The GitHub Advisory Database was launched in November 2019, and initially back-filled to include vulnerability information for the supported ecosystems, starting from 2017. When adding CVEs to the database, we prioritize curating newer CVEs, and CVEs affecting newer versions of software.

Some information on older vulnerabilities is available, especially where these CVEs are particularly widespread, however some old vulnerabilities are not included in the GitHub Advisory Database. If there's a specific old vulnerability that you need to be included in the database, contact your site administrator.

Check: Does the uncaught vulnerability have a publish date earlier than 2017 in the National Vulnerability Database?

Why does GitHub Advisory Database use a subset of published vulnerability data?

Some third-party tools use uncurated CVE data that isn't checked or filtered by a human. This means that CVEs with tagging or severity errors, or other quality issues, will cause more frequent, more noisy, and less useful alerts.

Since Dependabot uses curated data in the GitHub Advisory Database, the volume of alerts may be lower, but the alerts you do receive will be accurate and relevant.

Further reading