要約

  • GitHub は dismiss を理由付きのアラート状態として扱い、未修正の dismiss 済みアラートは再開できるとしている。
  • 依存関係グラフの検出、dismiss の根拠、運用上の修正は別々の証拠面である。
  • 修正完了を述べるには、状態表示ではなく記録の連結が必要である。

アラートを dismiss すると一覧は静かになるが、実行中のシステムが安全になったことにはならない。GitHub は、修正開始、不正確、脆弱なコードは使われない、対応余力がない、許容できるリスクという理由を文書化している。これらはそれぞれトリアージの説明である。どれも、特定の変更がレビューされ、ロックされた依存関係が解決され、テスト済みの成果物が実際に展開されたという証拠ではない。

未修正の dismiss 済みアラートを再開できるという案内は、境界を端的に示す。dismiss は判断を保存できるが、完了状態ではない。fix_started は作業が終わる保証ではなく、not_used は特定の経路についての結論にすぎない。tolerable_risk も、そのリスクを誰がどのサービスについて引き受ける権限を持つかを自動では示さない。

検出の土台も実行環境そのものではない。GitHub の依存関係グラフはマニフェスト、ロックファイル、グラフジョブ、提出データを利用できる。静的解析はビルド環境にアクセスせず、変数をすべて解決できない。ロックファイルは解決済み版をよく示せるが、ビルド、リリース、インストールを証明しない。Dependabot の pull request は提案であり、承認、マージ、成果物、稼働観測とは別の段階である。

Daniel Kade は、アラートの範囲、dismiss の理由と権限、ソースと解決結果、レビュー済み変更、ビルドとテストの成果物、限定された展開観測を一組の六部記録として残すことを勧める。状態の色ではなく、この連結が説明責任を支える。

出典

  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