Dependabot警报太多？沿着调用路径找到漏洞函数
同一个包名出现在警报中，修复顺序却未必相同。一个服务在处理请求时调用漏洞函数，另一个服务可能安装了包却没有使用该函数。GitHub于2026年10月28日推出的Dependabot可达性分析公开预览，让这种差异变得可见。
从已安装的包到调用路径
Dependabot识别存在漏洞的依赖版本，新分析则寻找仓库代码到受影响函数的路径。GitHub管理的Actions工作流使用CodeQL建立调用图，再与标明漏洞函数的整理后安全公告数据进行比对。
图中是我们编写的虚构代码：订单API通过辅助函数调用package.parseUnsafe，另一入口只调用package.formatLabel，因此在示例图中无法到达目标。这不是实际漏洞，也不是GitHub分析器的运行结果，而是说明为什么仅看包列表还不够。
四种结论各有含义
Reachable代表至少找到一条调用路径，不代表已经证明攻击能够成功。外部输入与生产环境使用情况仍然重要。警报最多展示五条示例路径，也不是全部路径清单。
Potentially reachable表示无法排除调用，应与Reachable一起优先处理。Unreachable表示分析完成但未找到路径；Reachability unavailable则表示无法给出结论。两者不能视为同样的安全信号。任何判定都不会自动关闭或忽略警报。
代码修改后，结论不会立即更新
启用功能会启动首次扫描，之后只要还有未关闭的Dependabot警报，就每24小时扫描一次。push不会立即触发扫描，公开预览期间也不能按需手动扫描。
今天删除漏洞调用后，旧Reachable可能仍会显示到下次扫描完成；新增调用后，旧Unreachable也可能暂时保留。第二张图是Python遍历虚构图的真实输出。对实际修复，应把扫描完成时间与当时分析的代码对应起来。
哪些仓库可以开始使用
公开预览面向GitHub Enterprise Cloud，包括数据驻留环境。需要JavaScript或TypeScript仓库、npm、Yarn或pnpm的lockfile，以及已启用的Dependabot alerts。无需GitHub Code Security许可证，预览扫描免费，也不消耗计费Actions分钟；不支持自托管runner。
功能默认关闭，可在Settings > Advanced Security中或通过自定义安全配置启用。一些大型monorepo可能触及三小时或资源限制而无法得出结论。严重性、EPSS和生产暴露情况仍需结合判断。新功能的价值，是让未关闭警报的处理顺序有更具体的依据。