摘要

  • GitHub 将忽略定义为带理由的告警状态；尚未修复的已忽略告警可以重新打开。
  • 依赖图中的发现、忽略理由和实际修复属于不同证据层。
  • 任何“已修复”结论都需要把这些层与构建和部署记录连接起来。

“已忽略”让告警列表更易管理，但它不应成为运行结果的代名词。GitHub 要求为被忽略的开放 Dependabot 告警提供理由，例如修复已经开始、告警不准确、脆弱代码未被使用、没有修复带宽，或风险对该项目可容忍。每个理由都是一个有限的分诊陈述，而不是对源代码、依赖解析、测试、发布或生产环境的总括判断。

GitHub 的文档给出了清楚的边界：未修复但已忽略的告警可以重新打开。因此，忽略并非没有价值；它可以保留一次审阅决定。但“修复已开始”并不证明工作已完成，“未被使用”也不自动覆盖另一条调用路径，“可容忍风险”更不会自行说明是谁有权替受影响的服务接受何种风险。

告警的起点也不是完整运行清单。GitHub 的依赖图可读取清单和锁文件，也可使用图任务或提交的数据；静态分析并不拥有构建环境，无法解析所有变量。锁文件能更准确地记录解析版本，却不能证明某次构建确实采用了该版本，或某个已发布制品已经安装。Dependabot 可以提出安全更新的拉取请求，这又只是另一个步骤：提议不是审阅，审阅不是合并，合并不是制品，制品不是运行观察。

Daniel Kade 建议保存六部分修复凭据：告警及其范围、忽略理由和决定权限、精确源状态与解析结果、已审阅变更、构建测试制品，以及有限的部署观察。敏感标识可受保护，记录之间的连接不能用状态标签代替。

来源

  1. GitHub Docs — Viewing and updating Dependabot alerts
  2. GitHub Docs — How the dependency graph recognizes dependencies
  3. GitHub Docs — Vulnerable dependency detection
  4. GitHub Docs — REST API endpoints for Dependabot alerts