1. 検出とトリアージ
セキュリティシグナルの発生源:- GitHub Security Advisories（GHSA）および非公開の脆弱性報告。
- 報告に機密性がない場合の公開 GitHub issue／ディスカッション。
- 自動化されたシグナル: Dependabot、CodeQL、npm アドバイザリ、シークレットスキャン。
- 影響を受けるコンポーネント、バージョン、トラスト境界への影響を確認する。
SECURITY.mdの対象範囲と対象外の規則を使用して、セキュリティ問題か、ハードニング／対応不要かを分類する。- インシデント所有者が分類に応じて対応する。
2. 深刻度
3. 対応
- 報告者に受領を通知する（機密性がある場合は非公開で）。
- サポート対象のリリースおよび最新の
mainで再現し、リグレッションカバレッジを備えたパッチを実装して検証する。 - 重大／高: 実務上可能な限り迅速に修正版リリースを準備する。
- 中／低: 通常のリリースフローでパッチを適用し、緩和策のガイダンスを文書化する。
4. コミュニケーションと開示
影響を受けるリポジトリの GitHub Security Advisories、修正版のリリースノート／変更履歴エントリ、および状況と解決について報告者への直接のフォローアップを通じて情報を伝える。 重大／高のインシデントでは、必要に応じて CVE を発行し、調整された開示を行う。リスクの低いハードニングに関する指摘は、影響とユーザーへの露出に応じて、CVE を発行せずにリリースノートまたはアドバイザリに記載する場合がある。5. 復旧とフォローアップ
修正のリリース後:- CI およびリリース成果物で修正措置を検証する。
- 簡潔なインシデント後レビューを実施する: タイムライン、根本原因、検出上の不足、再発防止計画。
- ハードニング／テスト／ドキュメントに関するフォローアップタスクを追加し、完了まで追跡する。
関連項目
- セキュリティポリシー — 報告対象範囲とトラストモデル。
- 脅威モデル