GitHub 报告的依赖项检测结果可能不同于其他工具返回的结果。 这是有原因的，它有助于了解 GitHub 如何确定项目的依赖项。
为什么似乎缺少某些依赖项？
GitHub 生成和显示依赖项数据不同于其他工具。 因此，如果您过去使用其他工具来识别依赖项，则几乎可以肯定您会看到不同的结果。 考虑以下事项：
-
GitHub Advisory Database 是 GitHub 用来识别漏洞依赖项的数据源之一。 它是一款免费的、具有整理功能的数据库，用于检测 GitHub 上常见软件包生态系统的漏洞信息。 它包括从 GitHub Security Advisories 直接报告给 GitHub 的数据，以及官方馈送和社区来源。 这些数据由 GitHub 审查和整理，以确保不会与开发社区分享虚假或不可行的信息。 更多信息请参阅“浏览 GitHub Advisory Database 中的安全漏洞”和“关于 GitHub Security Advisories”。
-
依赖项图解析用户仓库中所有已知的包清单文件。 例如，对于 npm，它将解析 package-lock.json 文件。 它构造所有仓库依赖项和公共依赖项的图表。 当启用依赖关系图时，当任何人推送到默认分支时，都会发生这种情况，其中包括对支持的清单格式进行更改的提交。 更多信息请参阅“关于依赖关系图”。
-
Dependabot 扫描对包含清单文件的默认分支的任何推送。 添加新的漏洞记录时，它会扫描所有现有仓库，并为每个存在漏洞的仓库生成警报。 Dependabot 警报 在仓库级别汇总，而不是针对每个漏洞创建一个警报。 更多信息请参阅“关于易受攻击的依赖项的警报”。
-
Dependabot 安全更新 在您收到关于仓库中漏洞依赖项的警报时触发。 在可能的情况下，Dependabot 会在您的仓库中创建拉取请求，以将易受攻击的依赖项升级到避免漏洞所需的最低安全版本。 更多信息请参阅“关于 Dependabot 安全更新”和“排除 Dependabot 错误”。
Dependabot 不会按计划扫描仓库中的漏洞依赖项，而是在发生某些变更时扫描。 例如，当新的依赖项被添加到 GitHub 时（对于每次推送都会进行此项检查），或者当新的漏洞被发现并添加到通告数据库时，就会触发扫描。
为什么我没有收到某些生态系统的漏洞警报？
GitHub 对漏洞警报的支持限于一组可提供高质量、可操作数据的生态系统。 GitHub Advisory Database 中经整理的漏洞、依赖关系图、Dependabot 警报 和 Dependabot 安全更新等功能适用于多个生态系统，包括 Java’s Maven、JavaScript’s npm 和 Yarn、.NET’s NuGet、Python’s pip、Ruby's RubyGems 以及 PHP’s Composer。 我们将在今后继续增加对更多生态系统的支持。 有关我们支持的包生态系统的概述，请参阅“关于依赖项图”。
值得注意的是，GitHub 安全通告可能存在于其他生态系统中。 安全通告中的信息由特定仓库的维护员提供。 此数据的整理方式与支持的生态系统整理信息的方式不同。
检查：未捕获的漏洞是否适用于不受支持的生态系统？
依赖项图是否只查找清单和锁文件中的依赖项？
依赖项图包含在环境中明确声明的依赖项的信息。 也就是说，在清单或锁定文件中指定的依赖项。 依赖项图通常还包括过渡依赖项，即使它们没有在锁定文件中指定，也可以通过查看清单文件中的依赖项来实现。
Dependabot 警报 提醒您应更新的依赖项，包括可从清单或锁定文件确定版本的过渡依赖项。 Dependabot 安全更新仅在可直接“修复”依赖项的情况下建议更改，即，在以下情况下：
- 在清单或锁定文件中明确声明的直接依赖项
- 在锁定文件中声明的过渡依赖项
依赖项图不包括“宽松”依赖项。 “宽松”依赖项是指从另一个来源复制并直接或在存档文件（例如 ZIP 或 JAR 文件）中检入仓库的单个文件，而不是在包管理器的清单或锁定文件中引用的文件。
检查k：是否存在仓库清单或锁定文件中未指定组件的未捕获漏洞？
依赖项图是否检测使用变量指定的依赖项？
依赖项图在清单被推送到 GitHub 时分析它们。 因此，依赖项图无法访问项目的构建环境，从而无法解析清单中使用的变量。 如果在清单中使用变量指定名称，或指定依赖项的版本（更常见），则该依赖项不会包括在依赖项图中。
检查: 在清单中缺少的依赖项是否使用变量声明其名称或版本？
是否存在影响依赖项图数据的限制？
是的，依赖项图有两个限制类别：
-
处理限制
这会影响 GitHub 中显示的依赖项图，还会阻止 Dependabot 警报 的创建。
仅为企业帐户处理大小超过 0.5 MB 的清单。 对于其他帐户，将忽略超过 0.5 MB 的清单，并且不会创建 Dependabot 警报。
默认情况下， GitHub 对每个仓库处理的清单不会超过 20 个。 对于超出此限制的清单，不会创建 Dependabot 警报。 如果您需要提高限值，请联系 GitHub 支持 或 GitHub 高级支持。
-
可视化限制
这会影响 GitHub 中依赖项图的显示内容。 但是，它们不会影响 Dependabot 警报 的创建。
仓库依赖项图的依赖项视图只显示 100 个清单。 通常这就足够了，因为它明显高于上述处理限制。 处理限制超过 100 的情况下，对于任何未在 GitHub 中显示的任何清单，仍会创建 Dependabot 警报。
检查：在超过 0.5 MB 的清单文件或包含大量清单的仓库中是否存在缺少的依赖项？
Dependabot 是否会针对已知多年的漏洞生成警报？
GitHub Advisory Database 于 2019 年 11 月推出，并在最初回顾性包含了受支持生态系统的漏洞信息（从 2017 年开始）。 将 CVE 添加到数据库时，我们会优先处理较新的 CVE，以及影响较新版本软件的 CVE。
提供了一些有关较旧漏洞的信息，尤其是在这些 CVE 特别普遍的地方，但一些较旧的漏洞未包含在 GitHub Advisory Database 中。 如果您需要将一些特定的旧漏洞包含在数据库中，请联系 GitHub 支持 或 GitHub 高级支持。
检查：未捕获的漏洞在国家漏洞数据库中的发布日期是否早于 2017 年？
为什么 GitHub Advisory Database 使用已发布漏洞数据的子集？
有些第三方工具使用未经人为检查或过滤的未整理 CVE 数据。 这意味着 CVE 带有标签或严重错误或其他质量问题，将导致更频繁，更嘈杂且更无用的警报。
由于 Dependabot 使用 GitHub Advisory Database 中的精选数据，因此警报量可能较少，但是您收到的警报将是准确和相关的。
是否每个依赖项漏洞都会生成单独的警报？
当一个依赖项有多个漏洞时，只会为该依赖项生成一个汇总警报，而不是针对每个漏洞生成一个警报。
GitHub 中的 Dependabot 警报 计数显示警报总数，即有漏洞的依赖项数量，而不是漏洞的数量。
单击以显示警报详细信息时，您可以查看警报中包含多少个漏洞。
检查: 如果您所看到的总数有出入，请检查您是否没有将警报数量与漏洞数量进行比较。
