GitHubの実行時コンテキスト連携を使い倒す：CVSS偏重から「本当に危険な脆弱性優先」へ

GitHubが実行時リスク情報（例：Dynatrace連携）を脆弱性優先度に取り込めるようになった意義は大きいです。従来の課題は、脆弱性件数は多いのに「何から直すべきか」が曖昧なことでした。CVSSだけで並べると、実害の小さい項目に工数を使い、公開面で危険な経路を後回しにしがちです。

なぜ静的スコアだけでは足りないのか

同じHighでも、実行されていないコンポーネントと、インターネット公開中の本番ワークロードでは意味が違います。静的診断だけでは次が判定できません。

• その成果物は本番にデプロイ済みか
• 外部到達可能か
• 機微データ経路に載っているか
• 実行時設定で悪用可能性が上がっていないか

この情報がないと、トリアージ会議は「強い言い方をした人が勝つ」状態になります。

現場で使える4軸スコア

運用しやすく監査説明もしやすい4軸で十分です。

1. 脆弱性そのものの深刻度
2. デプロイ有無（稼働中かどうか）
3. 露出状況（外部公開、横展開リスク）
4. データ重要度（個人情報・決済・規制対象）

この4軸でキューを分けるだけで、修正順は大幅に改善します。

GitHub上の運用設計

実行時情報を“閲覧用ダッシュボード”で終わらせず、キュー運用に落とします。

• Aキュー：デプロイ済み + 外部公開（当スプリント対応）
• Bキュー：デプロイ済み + 内部限定（計画修正）
• Cキュー：未デプロイ（負債整理）

この分類なら、開発チームも優先理由を理解しやすく、レビューの納得感が上がります。

実装ステップ

1. 実行時テレメトリを連携
2. リポジトリとワークロード対応を整備
3. ラベル付与を自動化
4. リスク別SLAを設定
5. リスク階層ごとにMTTRを計測

特に重要なのは、リポジトリと実行体の対応精度です。ここが崩れると優先度の品質が一気に落ちます。

経営報告で見るべき指標

経営に必要なのは「総件数」より次の指標です。

• 外部公開かつ未修正の件数
• 本番高リスク経路の中央値修正時間
• サービス単位のリスク集中度

実行時コンテキストを使うと、これらを直接示せるため、投資判断や体制再編の根拠が明確になります。

よくある失敗

• ツール追加で満足して運用を変えない
• 所有者メタデータを放置する
• 全脆弱性に同一SLAを適用する
• インシデント後に優先基準を更新しない

運用設計が変わらなければ、可視化が増えてもリスクは下がりません。

まとめ

これからの脆弱性管理は「件数管理」ではなく「露出削減管理」です。GitHubのコード情報と実行時リスクを統合し、危険な順に直せる体制を作ることが、最短で安全性を高める道です。