「うわっ…、アラート多すぎ…？」思考停止にならずに次へ進むための、脆弱性トリアージ

こんにちは、@tak-tak_beng です。
この記事は 脆弱エンジニアの Advent Calendar 2025 の10日目の記事です。

昨年の自社アドベントカレンダーで、「SBOMを利用した脆弱性管理の導入準備あれこれ」という記事を書きました。

今年は 「実際にやってみたら、やっぱり一筋縄ではいかなかった」 という、お話をお届けしています。

初日は主に技術面での躓きの話を書きましたが、2日目は管理面の話を書いていきます。

1. 脆弱性の可視化

苦労してSBOMを登録し、いよいよ運用を開始。
プロダクト毎の脆弱性状態を可視化する段階にたどり着きました。

具体的な中身は伏せますが、 🟥Critical（赤） や 🟧High（オレンジ） のアラートが並んでいました。

「利用しているライブラリに脆弱性の報告がある」ことは、「理論上脆弱性がある」ことを示すものですが、「製品として実際に攻撃が可能である」ことを示すものではない ことに注意してください。
また、SBOMの取り組みとは別に、製品リリース前には社内外の専門チームによる脆弱性診断を行っています。

ツールの特性上、ライブラリのバージョンをもとに機械的にマッチングされるため、実際には影響を受けないものも多く含まれる「過検知(False Positive)」の状態 となります。
とはいえ、頭では理解していましたが、具体的な数値とグラフで可視化されたインパクトは絶大でした。

プロダクトマネージャーや上位レイヤーの人たちも、この状況を見て

「うわっ…、アラート多すぎ…？」

と、衝撃を受けたようです。可視化の力恐るべし。

2. トリアージの壁

意識は高まりました。しかし、「じゃあ明日から全部対応しよう」とはなりません。 ここが現実の辛いところです。

表示されているCVSSスコアはあくまで「そのライブラリ単体での評価」であり、実際のプログラムへの影響度（実際にその関数を使っているか等）までは考慮されていません。

現場の悩み

• Criticalだけで〇〇件もある…どこから手を付ければ？
• 本当に影響があるのか調査するだけで日が暮れる
• ライブラリのバージョンを上げると動かなくなるリスクがある

結果として、実際のトリアージ（優先順位付け）の進め方に悩んで手が止まってしまうという状況に陥りました。
CVSSスコアだけを見せられても、開発者は「で、どこから手をつければよいの？」の判断がつかなかったのです。

3. まずは状況を整理する

この膠着状態を打破するために導入したのが、CISA（米国土安全保障省）が公開している KEV (Known Exploited Vulnerabilities) カタログ です。

これは「理論上の脆弱性」ではなく、「実際に攻撃に使われていることが確認された脆弱性」 のリストです。

「CVSSスコアが高いやつを全部直して」
　↓
「もし、KEVカタログに載っている（＝野放しにすると実際に攻撃される）脆弱性が検出されたら、最優先で潰してください」

というように、指示を具体的にすることで、後続のアクションを取りやすくしました。

Dependency-Trackで検出された脆弱性と、KEVカタログのマッチング方法は、Dependency-Trackのドキュメントに記載されているPowerShellを参考にしてbashスクリプトを作成し、新規にKEVカタログとマッチングした脆弱性があった場合はSlackへ通知するようにしています。

KEVカタログとのマッチング処理概要(エラー処理等は省いています)

#!/bin/bash
# 必要なコマンドのPATH設定など
export PATH=/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin

# --- 設定 (環境に合わせて変更) ---
API_BASE_URL='http://your-dependency-track-host:8081'
API_KEY='your_api_key'
URL_CISA='https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json'
SLACK_WEBHOOK_URL='https://hooks.slack.com/services/xxxx/xxxx/xxxx'
REPORT_DIR="/path/to/reports"

# ファイル定義（当日分、前日分、差分）
TODAY_FILE="$REPORT_DIR/$(date +%Y%m%d)_kev-match-list.csv"
YESTERDAY_FILE="$REPORT_DIR/$(date -d "yesterday" +%Y%m%d)_kev-match-list.csv"

# 1. KEVカタログ(JSON)の取得
KEV_CATALOG=$(curl -s "$URL_CISA")

# 2. KEV脆弱性ごとにループ処理
echo "$KEV_CATALOG" | jq -c '.vulnerabilities[]' | while read -r vulnerability_json; do
    
    CVE_ID=$(echo "$vulnerability_json" | jq -r '.cveID')
    
    # Dependency-Track API: CVEを含むプロジェクトを検索
    GET_PROJECT_URI="$API_BASE_URL/api/v1/vulnerability/source/NVD/vuln/$CVE_ID/projects"
    HTTP_RESPONSE=$(curl -s -H "X-Api-Key: $API_KEY" "$GET_PROJECT_URI")
    
    # 該当プロジェクトがあればループ
    echo "$HTTP_BODY" | jq -c '.[]' | while read -r project_json; do
        PROJECT_UUID=$(echo "$project_json" | jq -r '.uuid')

        # 該当コンポーネントのループ
        echo "$project_json" | jq -r '.affectedComponentUuids[]' | while read -r component_uuid; do
            
            # コンポーネント詳細を取得
            GET_COMPONENT_URI="$API_BASE_URL/api/v1/component/$component_uuid"
            COMP_HTTP_BODY=$(curl -s -H "X-Api-Key: $API_KEY" "$GET_COMPONENT_URI")
            
            # CSVに行を追加 (CVE, プロジェクト名, コンポーネント名など)
            echo "\"$CVE_ID\",\"$PROJECT_NAME\",..." >> "$TODAY_FILE"

        done
    done
done

# 3. 前日分との差分チェックと通知
if [ -f "$YESTERDAY_FILE" ]; then
    # commコマンドで「今日増えた分」のみを抽出
    NEW_MATCHES=$(comm -13 <(sort "$YESTERDAY_FILE") <(sort "$TODAY_FILE"))

    if [ -n "$NEW_MATCHES" ]; then
        # Slackへ通知
        PAYLOAD=$(jq -n --arg text "*新規KEV検出:*\n\`\`\`$NEW_MATCHES\`\`\`" '{"text": $text}')
        curl -X POST -H 'Content-type: application/json' --data "$PAYLOAD" "$SLACK_WEBHOOK_URL"
    else
        # 差分がなければ前日分を削除してクリーンアップ
        rm "$YESTERDAY_FILE"
    fi
fi

効果

この施策による効果として、「実際に攻撃に使われている」という事実は、対応しようという動きを強力に後押しすることができます。
トリアージの進め方に悩んで手が止まってしまっていた開発チームからも対応実施への具体的な反応が返ってくるようになりました。

4. 今後に向けて

今回痛感したのは、「CVSS値だけ並べられても、次のアクション（意思決定）は取れない」 ということです。

商用の脆弱性管理ツールのセールストークを聞いていると、「対応の優先順位付けをAIが自動で！」といった機能を売りにしたものがありますが、まさにそこが全人類共通の悩みなんだと実感しました。

次の一手：SSVCと教育

KEVカタログは強力ですが、それだけではカバーしきれない部分もあります。
現在は、SSVC (Stakeholder-Specific Vulnerability Categorization) の考え方を取り入れたトリアージ手法を検討中です。

SSVCとは、「決定木（Decision Tree）」を用いた判断モデルで、「重大度」で評価するCVSSとは異なり、

• 脆弱性の悪用状況
• システムの外部露出度
• 攻撃者にとっての有用性
• 影響の大きさ

を評価することで、

• 可能な限り迅速に対応
• 通常よりも迅速に対応
• 定期メンテナンス時に対応
• 現状維持

のカテゴリに分類していくものです。

このSSVCの考え方を、

• 勉強会の開催 : 脆弱性管理・トリアージの基礎知識を広める
• ワークショップ : 実際の脆弱性を見ながら「自分たちならどう判断するか」を体験してもらう

といった形で、開発・運用チームに浸透させていこうと計画しています。

昨年の記事は、

セキュリティは担当者だけが頑張っても広げるのが困難なので、少しずつ草の根で意識を広げていきたいところです。

と結びましたが、ツールを入れるだけでなく、開発者自身が「これは今直すべきか？」を判断できるような文化を作っていくことで、草の根の意識拡大が進むようにしていきたいです。

---

さいごに

SBOM運用は「入れて終わり」ではなく「入れてからが地獄（そして本番）」です。
同じような課題を持っている方の参考になれば幸いです！

また、ビジネスエンジニアリング株式会社では自社でも独自の アドベントカレンダー を実施しています。よろしければこちらもご覧ください！