GitHub 报告的依赖检测结果可能与其他工具返回的结果不同。这背后有充分的理由，了解 GitHub 如何为您的项目确定依赖关系会很有帮助。
缺失或未检测到的依赖
GitHub 生成并显示依赖数据的方式与其他工具不同。因此，如果您一直在使用其他工具来识别依赖关系，几乎肯定会看到不同的结果。请考虑以下内容。
-
GitHub Advisory Database 是 GitHub 用于识别易受攻击的依赖和恶意软件的众多数据源之一。它是一个免费的、经过策划的安全建议数据库，涵盖 GitHub 上常见的软件包生态系统。它包括直接从 GitHub 安全建议（GitHub Security Advisories）报告给 GitHub 的数据，以及官方源和社区来源的 feed。GitHub 对这些数据进行审查和策划，以确保不会向开发者社区共享错误或不可操作的信息。欲了解更多信息，请参阅 浏览 GitHub Advisory Database 中的安全建议。
-
依赖图会解析用户仓库中所有已知的包清单文件。例如，对于 npm，它会解析 package-lock.json 文件。它会构建一个包含仓库所有依赖及公开依赖方的图。此过程在您启用依赖图并且有人向默认分支推送时发生，并且包括对受支持的清单格式进行更改的提交。欲了解更多信息，请参阅 关于依赖图 和 故障排除依赖图。
-
Dependabot 会扫描任何推送到默认分支且包含清单文件的提交。当新增安全建议时，它会扫描所有现有仓库，并为每个受影响的仓库生成一个警报。Dependabot 警报在仓库层面聚合，而不是为每条建议生成单独的警报。欲了解更多信息，请参阅 关于 Dependabot 警报。
-
当您收到关于仓库中易受攻击依赖的警报时，会触发 Dependabot 安全更新。可能的情况下，Dependabot 会在您的仓库中创建一个拉取请求，将受影响的依赖升级到能够消除漏洞的最低安全版本。欲了解更多信息，请参阅 关于 Dependabot 安全更新 与 Dependabot 错误排查。
Dependabot 并不是按照计划定时扫描仓库，而是当有变化时触发扫描。例如，每次推送时添加新依赖（GitHub 会在每次推送时检查），或数据库中出现新安全建议时，都会触发扫描。欲了解更多信息，请参阅 关于 Dependabot 警报。
警报覆盖范围
Dependabot 警报会提示您需要更新的依赖（包括可以从清单或锁定文件中确定版本的传递依赖），而 Dependabot 安全更新仅在 Dependabot 能直接“修复”依赖时才提出变更建议，即以下情况：
- 直接依赖：在清单或锁定文件中明确声明的依赖
- 传递依赖：在锁定文件中声明的依赖
检查：未捕获的漏洞是否针对未在仓库的清单或锁定文件中指定的组件？
不受支持的生态系统
Dependabot 警报仅在我们能够提供高质量、可操作数据的生态系统中受支持。GitHub Advisory Database 中策划的安全建议、依赖图、Dependabot 安全更新以及 Dependabot 警报均针对多个生态系统提供支持，包括 Java 的 Maven、JavaScript 的 npm 与 Yarn、.NET 的 NuGet、Python 的 pip、Ruby 的 RubyGems，以及 PHP 的 Composer。有关我们为 Dependabot 警报支持的包生态系统概览，请参阅 依赖图支持的包生态系统。
值得注意的是，其他生态系统也可能存在安全建议。这些未经审查的安全建议由相应仓库的维护者提供，数据并未经过 GitHub 的策划。欲了解更多信息，请参阅 浏览 GitHub Advisory Database 中的安全建议。
检查：未捕获的漏洞是否针对不受支持的生态系统？
历史漏洞
GitHub Advisory Database 于 2019 年 11 月上线，最初回填了自 2017 年起在受支持生态系统中的安全建议。在向数据库添加 CVE 时，我们优先策划较新的 CVE 以及影响较新软件版本的 CVE。
对一些较早的漏洞仍有信息可查，特别是那些 CVE 影响面极广的情况，但仍有部分旧漏洞未纳入 GitHub Advisory Database。如果您需要将特定的旧漏洞纳入数据库，请通过 GitHub 支持门户 与我们联系。
检查：该未捕获的漏洞在国家漏洞数据库中的发布时间是否早于 2017 年？
安全建议数据库范围
某些第三方工具会使用未经策划的 CVE 数据，这些数据未经过人工检查或过滤。这意味着标记错误、严重性误判或其他质量问题的 CVE 会导致更频繁、更嘈杂且价值更低的警报。
由于 Dependabot 使用 GitHub Advisory Database 中经过策划的数据，警报的数量可能更少，但您收到的警报将更加准确且相关。
警报生成与聚合
当一个依赖包含多个漏洞时，会针对每个漏洞在“建议 + 清单”层面生成单独的警报。
旧版 Dependabot 警报会将同一依赖的所有漏洞聚合为单个警报。如果您访问旧版 Dependabot 警报的链接，系统会将您重定向到 Dependabot 选项卡，并过滤显示该依赖包和清单对应的漏洞。
GitHub 中的 Dependabot 警报计数显示的是警报总数，即漏洞数量，而非依赖数量。
检查：如果您看到的总数存在差异，请确认您没有将警报数量与依赖数量混淆。同时检查您是否正在查看全部警报，而不是已过滤的子集。
依赖忽略选项
您可以在配置文件中设置 Dependabot 忽略特定依赖，这将阻止对这些依赖进行安全更新和版本更新。如果您只想使用安全更新，需要通过配置文件覆盖默认行为。更多信息请参阅 通过配置文件覆盖默认行为以防止激活版本更新。有关忽略依赖的说明，请参阅 忽略特定依赖。
GitHub Actions 版本的 monorepo 限制
如果您的仓库包含多个 GitHub Actions（例如在 monorepo 中），您使用的标签格式会影响 Dependabot 对 Action 版本的检测和更新方式。
- 破折号（
-）分隔符（例如，@my-action-v0.1.0）- Dependabot 可能会将多个 Action 合并为单个依赖项，或无法正确检测新版本。这是因为 Dependabot 依赖基于斜杠的标签解析来区分不同的 Action。
- 斜杠（
/）分隔符（例如，@my-action/v0.1.0）- Dependabot 能够正确检测并独立更新每个 Action，因为斜杠构成的层级标签结构符合 Dependabot 的解析逻辑。
建议：对于包含多个 Action 的 monorepo，请使用 name/version（斜杠）格式的 Action 标签。这可确保 Dependabot 正确解析标签层级并独立更新各个 Action。
-
示例
# Recommended: namespaced with slash uses: my-org/monorepo/my-action@my-action/v0.1.0 # Not recommended: dash uses: my-org/monorepo@my-action-v0.1.0