クラウドセキュリティプラットフォームは、ルールに違反するたびに検出結果（ファインディング）を生成し、それらは重大度順に並べられたキューに積み上がっていきます。Sola Securityの研究チームは、各検出結果を実際に存在する環境に照らして検証すると、この順序がどう変わるのかを検証しました。
研究者のLeon Goldberg氏とGal Engelberg氏は、サードパーティ製クラウドセキュリティプラットフォームが検出した結果を再評価するAIエージェントを構築しました。2つの商用プラットフォームが8つの本番環境で検出した9,967件のHIGH評価の結果に適用したところ、エージェントは75.1%の評価を変更しました。多くは引き下げられ（58.5%）、引き上げられたものは16.6%でした。
すべての環境に同じ重大度
クラウドの検出結果の重大度は、それを検出したルールによって決まります。599件のベンダールールは、失敗した99,073件の検出結果に対し、対象のリソースや環境にかかわらず、それぞれ常に1つの重大度だけを割り当てていました。研究者らは「静的な重大度は、その状態が一般的に持つリスクを反映したものにすぎません。それに基づいて並べたキューは、一般的なケースの順序になります」と述べています。
「ルールに盛り込めるのは、作成者があらゆる環境に共通して一度だけ記述できる文脈にとどまります」と研究者らは指摘します。「特定の環境でその状態にどれほどの価値があるかを決める文脈は、別の場所にあります」。たとえば、問題を指摘されたリソースが何かに接続されているか、そのリソース上でワークロードが稼働しているかといった情報です。
評価基準には、こうした文脈を反映するための枠が用意されています。CVSSには、基本スコアを個々の展開環境に合わせて調整する環境メトリクスがあり、NISTのリスク評価ガイダンスも、発生可能性を導入済みの対策と結び付けています。研究者らは「静的な重大度では、その枠が空白のままです」と指摘しています。
エージェントの証拠ルール
エージェントは検出結果ごとに、攻撃者がその問題をどう悪用するかという仮説を立てます。そのうえで、リソースの構成、接続された関連リソース、他のセキュリティ製品が保持するデータから証拠を集めます。
エージェントの証拠ポリシーでは、「重大度を引き上げるには、引き下げる場合より多くの証拠が必要」とされています。評価を下げるには、その問題の具体的な悪用方法を相殺する性質が観測されている必要があります。評価を上げるには、その環境で状態がより深刻であることを示す証拠に加え、経路上にファイアウォールや許可リスト（アローリスト）など、想定される他の防御策がないかの確認が求められます。それ以外は、ベンダーの評価がそのまま維持されます。
同じルールでも、評価は上下どちらにも動く
クラウドのAPIを通じて判断材料を確認できた検出結果は、6つの典型パターンに分類されました。最大のパターンは全体の32.3%を占め、何にも接続されていない、あるいは孤立した不活性なリソースでした。そのほか、インターネットから到達できないリソース、稼働中のサービスが存在しないケース、送信元の制限が厳しいケース、アカウントレベルのブロックがある場合も引き下げの要因となりました。環境内でインターネットへの公開が確認されたパターンは、主に重大度の引き上げにつながりました。
138件のルールのうち62件では、エージェントが検出結果を、ある場合は引き下げ、別の場合は引き上げていました。そのうち57件のルールでは、同じ1つの環境の中で両方の結果が生じています。たとえばセキュリティグループのルールは、そのグループが内部ロードバランサーだけを前面に置いている場合は評価が下がり、環境内にインターネットからの経路が見つかった場合は評価が上がりました。
判定の約半数（49.0%）は、指摘されたリソースの外にある証拠、つまりアセットグラフ上の接続リソースや他製品のデータに基づいていました。研究者らは次のように説明しています。「外部の証拠は評価の引き下げに集中しています。ある検出結果が安全だと示すには、そこに至るあらゆる経路を排除しなければならないためです」。さらに「本番環境ではルールの重大度と実態との乖離が大きく、それを埋めるには環境全体からの証拠が必要です」と結論づけています。
稼働中のインフラで事実を検証
エージェントの判定が確かな根拠に基づいているかを確かめるため、研究者らは8つのAWSアカウントに対して読み取り専用のプローブを実行しました。エージェント自身のデータは使わず、判定の決め手となった事実をクラウドプロバイダーから直接再取得しています。プローブで確認できた判定については、稼働環境の状態がエージェントの示した事実と99.4%一致しました。プローブで確認できなかった検出結果をすべて誤りとして数えると、この数値は81.8%に下がりました。
プローブが検証したのは判定の裏付けとなる事実であり、見直し後の重大度が適切だったかどうかは、この研究では答えが出ていません。著者らは、AIが検出結果を読み解くことと、それに基づいて行動することとは別だと線を引いています。
Goldberg氏とEngelberg氏は「検出結果を環境ごとに検証しながら読み解くことは、検出結果に自律的に対処するための前提条件です」と主張しています。そのうえで「読み取りと実行では、影響範囲、元に戻せるかどうか、承認の要否が異なります」と注意を促し、「本研究が測定したのは読み取りのみです」と付け加えました。
研究の限界
この研究が対象としたのは、2つのプラットフォームのHIGHキューに対する1つのシステムの判定にとどまり、再評価された検出結果の92%はAWSのものでした。稼働環境での検証は1つのプラットフォームと5種類のリソースに限られ、各判定の決め手となった事実を検証したものの、最終的な評価そのものは確認していません。
当初MEDIUMまたはLOWだった検出結果は対象外でした。また、インシデントのデータもないため、引き上げられた検出結果が実際に悪用される可能性が高いのか、引き下げられた検出結果が悪用されにくいのかは、ベンダーの評価が示すところと比べて不明のままです。エージェントが見落とした判断材料を示す再現率（リコール）も測定されていません。
翻訳元: https://www.helpnetsecurity.com/2026/10/13/cloud-security-findings-severity-ai-agent/
