確認する情報源を分ける
製品提供者の修正告知、WordPressのリリース情報、WPScanなどの専門DBを確認します。CVEは同じ問題を識別する番号であり、番号があること自体が侵害の証拠ではありません。DBへの掲載と提供元告知には時間差や表現差があることもあります。
レコードの読む順序
| 項目 | 読むポイント |
|---|---|
| 対象製品 | 配布元、slug、類似名の製品との差 |
| 影響版 | 範囲の上限・下限、修正版 |
| 前提条件 | 未認証か、投稿者などの権限が必要か |
| 影響 | 漏えい、権限昇格、改ざんなど |
| 補足 | 悪用状況、暫定策、告知の更新 |
自社への該当性を管理する
構成台帳に情報URL、確認日、該当有無、判断理由を記録します。削除済みと思っていた製品のファイルが残っていないかも確認します。「確認できない」は「非該当」にせず、追加調査として管理します。
通知の受信と実施を分けない
メールやフィードの受信先を組織で管理し、担当者と代替担当者を決めます。重大性に応じた連絡方法を設け、定期会議まで情報が止まらないようにします。本文のリンクは配布元を確認し、通知を装う不正な更新案内にも注意します。
CVSSと悪用情報を組み合わせる
CVSSの値は、評価に使う版やベクトルと一緒に読みます。認証条件や必要な操作が違えば、自社のリスク評価も変わります。既知の悪用情報は優先判断の材料になりますが、カタログに載っていないことが安全の証明になるわけではありません。同じ脆弱性が複数のDBに掲載される場合は、CVEや提供元の告知を軸に整理し、件数を単純に合計しないようにします。提供元が修正版や回避策を更新したら、台帳の判断も見直します。
よくある質問
CVE番号がない情報は無視してよいですか？
番号の有無だけで除外しません。製品提供者の修正告知や信頼できる報告が先に出る場合もあります。内容と対象を確認し、情報の確度を区別して管理します。
ツールで古い版と判定されたら必ず該当しますか？
外部推定はキャッシュや公開情報に影響されます。内部で現在版を照合し、提供者独自の修正がある場合はその根拠も確認します。外見の版だけで修正済みと断定することも避けます。