脆弱性スキャン結果の誤検知を切り分ける 3 手

いつ使うか

• 脆弱性スキャナや ASM の結果を報告・チケット化するとき
• 「うちには関係ない項目では？」と言われがちなとき
• 深刻度「高」が大量に出て、どれから手を付けるか迷うとき

手順（上から順。多くは 1 手目で決着）

1 手目: 版を照合する（机上）

検知が前提とする製品名・バージョン範囲と、現物の構成を突き合わせる（構成管理表だけで決め打ちしない）。

ここで片が付く典型:

• 該当製品を使っていない（応答ヘッダからの推測違い）
• 使っているが範囲外（既に修正済み）
• ディストリが版番号を上げずに修正だけ取り込んでいる（版番号は古く見えるが中身は修正済み → パッケージ更新履歴で確認）

2 手目: 条件を確かめる（設定）

版が範囲内でも、悪用条件が揃っていなければ「いまは成立しない」。

例:

• 該当モジュールが無効のままか
• 外部から到達できる経路か（管理ポートが内部のみか）
• 悪用に管理者権限が要るか、認証なしで届くか

「対応不要」と言い切らず、「現在の設定では成立しない。設定変更時に再評価」 と書く。設定は変わる。

3 手目: 実際に触って確かめる（合意のうえで）

机上で決着しないものだけ。バージョン取得・設定確認・応答確認。

事前に必ず決めること: 顧客の承諾（いつ・どの機器・何をするか）、本番か検証か、影響時の連絡先。確認のつもりの操作が本番障害になり得るので、単独判断で走らない。

渡す形（消さず、扱いを決める）

検知を消さず、箱分けして根拠を残す。

【対応が必要】N 件
  例）製品A 3.2.1 → 3.2.7（CVE-… / 認証なしで外部到達可）

【現時点では成立しない】N 件 ※再検査 YYYY-MM-DD
  例）モジュール M は無効。有効化前に再評価

【誤検知と判断】N 件
  例）製品C と推測されているが実体は製品D。確認: 管理画面スクショ（日付）

【未判定】残り ※期限を書く

「誤検知」には確認方法を必ず書く。根拠がないと半年後に同じ調査をやり直す。

やりがちな失敗

1. ツール深刻度だけで並べる（到達できない「高」より、外部に開いた「中」が先）
2. 誤検知を黙って消す（次の担当がゼロから調べ直す）
3. 全件判定し切るまで出さない（まず対応必須分を出し、残りに期限を付ける）

注意点

• これは報告・トリアージの手順であり、スキャナの置き換えではない
• 実機確認は権限・契約・変更管理の範囲内で行う

出典

• @yousukezan · 2026-10-13
• 元記事（Qiita, Intect-i）: qiita.com