AIで脆弱性を検証する：発見だけでは守れない

脆弱性スキャナーは、毎週のように数百件の検出結果を出します。そのうち実際に攻撃者が悪用できるのはどれかという問いに、即答できるチームは多くありません。

見つけることと、本当に攻撃できるか確かめることは別の工程です。後者を担う AI ディープスキャンの考え方を順に見ていきます。

01 / 「見つける」と「攻撃できるか確かめる」は、別の工程

発見はポートやバナー、TLS 証明書、使用技術の推定から候補の一覧を作る工程です。候補はあくまで候補で、そこに実在の確認は含まれていません。

図1：候補を挙げる工程と、実在を確かめる工程

深掘り：枠組みの側でも分けてある

CTEM は5つの工程のうちに検証（Validation）を明確に置いています。発見した脆弱性が本当に悪用できるかを確かめないと、対応の順番が信頼できないからです。全体像はCTEM とはに、攻撃面の把握はASM の解説で扱いました。

外から見える情報だけで判断している以上、避けられない誤差があります。脆弱に見えても実際には塞がっている、という組み合わせが3通りあるからです。

図2：外から見えるだけでは決まらない 3 つの場合

深掘り：どれも「嘘の検出」ではない

スキャナが間違っているわけではなく、外から見える範囲では判断がつかない、というだけです。だから検出を消すのではなく、確かめる工程を足して切り分けます。

未検証の一覧をそのまま渡すと、直す側にも報告する側にも負担が移ります。いちばん重いのは、アラート自体が信用されなくなることです。

図3：検証を飛ばしたぶんが、あとから戻ってくる

深掘り：機械的な絞り込みだけでは足りない

EPSS や KEV で絞れば件数は減りますが、それは脆弱性そのものの性質を見た絞り込みです。「このシステムで本当に悪用できるか」は、その資産に対して確かめないと分かりません。スコアの読み分けはCVSS・EPSS・KEVで扱いました。

対象の文脈を踏まえて、AI がその脆弱性に特化した検証コードを作り、遠隔から実行します。データの変更や削除は行わず、結果は3つに分かれます。

図4：検証の結果は 3 つに分かれる

深掘り：全部を能動検証するわけではない

対象になるのは、能動的に再現できて、なおかつ優先度や根拠の確度が一定以上の脆弱性です。遠隔かつ非破壊という性質上、資格情報の先や破壊的な経路までは届きません。検証不可には、資格情報が要るもの、時間切れになったもの、実行そのものができなかったものが入ります。

有効にするかどうかを決めるのはお客様で、実行はいつでも一時停止と再開ができます。能動的に確かめる工程である以上、制御はこちらが握らない設計にしました。

確かめた事実は、そのまま順位付けへ戻る仕組みです。再現しなかったものはTDLが1段階下がり、一覧の下のほうへ移ります。

図5：確かめた事実を、順位付けへ戻す

深掘り：それでも一覧から消さない

再現しなかったことは、存在しないことの証明にはなりません。スキャンの経路が塞がれていただけかもしれないので、消さずに順番だけを下げて残します。順位付けの仕組みはTER バンドにあります。

自社の外部攻撃面の検証は、14日間無料で試せます。

付録：検証の結果と、対象にする条件

表1：検証の結果

表2：能動検証の対象にする条件

条件	中身
能動的に再現できる型か	遠隔から非破壊で確かめられる種類の脆弱性であること
優先度が一定以上か	順位付けで上位に来ているもの
根拠の確度が一定以上か	検出の裏付けが弱すぎないもの
お客様が有効にしているか	実行はいつでも一時停止・再開できる

問うべきは脆弱性が何件あるかではなく、攻撃できる脆弱性がどこに何件あるかです。発見で候補を挙げ、検証で実在を確かめ、成立したものへ人手を寄せるのが、限られた手数での回し方になります。

検証の結果の区分は、2026年8月17日に PentaTrail のデータ定義を参照して確認したものです。