security-alert

Topics in the source

• Dependabot Security Alert Triage Workflow
• なぜ security alert を update PR と別 skill で扱うのか
• 前提条件
• ホスト repo に依存する慣習について
• 手順
• 1. Security alert の収集
• 2. 各 alert のリスク分析
• advisory の脆弱範囲を自分の pin と突き合わせる

Dependabot の security alert（GitHub Advisory に基づく脆弱性アラート）を一括でトリアージし、 direct / transitive を判別して適切な修正方法で解決する。トラッキング Issue を作成し、修正 PR を 出し、判断結果と根拠を ADR に記録する。 dependabot skill は Dependabot が開いた 依存更新 PR を捌く。security alert は別物として扱う。 security alert は gh api repos/{owner}/{repo}/dependabot/alerts から取得する。open PR 一覧 には現れない。 alert に対応する PR が存在しないことがある。脆弱なパッケージが transitive 依存の場合、 bump すべき直接の宣言行が package.json に無いため、Dependabot は security update PR を 合成できず、alert だけが残る。 alert の state は安全性の証明ではない。GitHub の auto-triage は通知量を減らすために alert を autodismissed にするが、脆弱版は lock に残ったままである（ステップ 1）。 transitive 依存の解決には、bot PR のマージではなく package manager の override 機構 （pnpm overrides / npm overrides / yarn resolutions）を使うことが多い。 このため、dependabot skill の「open PR を列挙してトリアージ」とは収集元も解決手段も異なる。 本 skill は特に transitive 依存で PR が起票されないケースを主対象にする。 gh auth status で GitHub 認証済みであること ホスト repo が Dependabot security alert を有効化していること（リポジトリ設定の "Dependabot alerts"） alert / advisory の取得のため gh api および WebFetch でアクセスできること alert を読むには gh のトークンに securityevents スコープ（または対象 repo の admin / security 権限）が必要 本 skill には以下の任意（optional）ステップが含まれる。ホスト repo がその慣習を採用して いない場合は該当ステップをスキップする。 status ラベル: status: ラベル運用がある repo のみ、トラッキング Issue のラベルを 更新する。 ADR: doc

This is an excerpt. Refer to the complete source and its current requirements.