スキャンツールの精度は着実に向上しています。組織は今、業界の歴史上どの時点よりも多くのシステムにわたって、より多くの脆弱性を発見できるようになりました。しかしセキュリティ企業Vicariusの調査は、その発見の後に生まれるギャップ、つまり修正の割り当て、承認、展開、確認という一連の作業に潜む問題を指摘しています。

同社は米国と英国において、従業員数500人から2,000人の組織に所属するIT・サイバーセキュリティ責任者300人を対象に調査を実施しました。修復作業の平均58%は人手による直接的な介入を必要としています。自動化された発見・スキャン・報告は、調査対象全体で一般的になりつつあります。しかし何を修正すべきかを決定し、変更を実行に移す作業は、依然として人に依存したままです。人をループから完全に排除した組織はわずか7%にとどまり、この傾向は企業規模や業種を問わず一貫していました。
脆弱性を発見したチームは、通常それを修正できない
発見と修正の作業は、しばしば異なるグループが担っています。発見したチーム内で一貫して脆弱性を修復できない組織は大多数を占め、その割合は82%に達します。修復作業は引き継ぎ、責任の共有、そして担当が次々と別のグループへ移っていくワークフローに依存しています。引き継ぎが一つ発生するたびに、遅延が積み重なっていきます。
そもそも責任の所在自体が定義されていないケースも少なくありません。回答者の3分の1以上が、修復の責任は状況次第で決まる、あるいは曖昧なままだと答えています。修正作業の担当が定まっていない場合、どのチームが動くべきかを調整している間に作業は滞ってしまいます。
「発見」が単なる「引き継ぎ」になっている
重大な脆弱性への対応は、多くの場合、事務作業から始まります。最も一般的な最初のアクションは、JiraやServiceNowといったシステムでチケットを起票することで、回答者の42%がこれを挙げています。チケットは作業を追跡する手段にすぎません。その背後にある脆弱性は、依然として優先順位付け、担当割り当て、承認、修正、そして確認という工程を経る必要があります。
組織のおよそ4分の1は、自社のプラットフォームから自動的に修復アクションを展開しています。それ以外の組織では、脆弱性が発見された瞬間、対応の必要な文脈や適切なツール、あるいは迅速に動くための権限を持たない担当者に問題が渡されてしまいます。多くのチームは重大な脆弱性を発見するための強力な仕組みを構築してきました。しかし、それに対応するための同等に強力な仕組みを構築できているチームは、まだ多くありません。
ループを完結させたわずかな組織には共通点がある
ごく一部の組織は、修復作業から人手を完全に排除することに成功しており、その特徴は際立っています。Vicarius社のCEOであるRoi Cohen氏によれば、この20組織はいずれも同じ道筋をたどってそこに到達したといいます。「これは、それぞれ異なる経路でたどり着いたグループではありません。到達した全員が、同じ道を通ってきたのです」と同氏はHelp Net Securityに語りました。
これらの組織にはいずれも3つの共通点がありました。まず、発見から検証まで、修復作業をすべて単一のプラットフォーム上で完結させていました。調査対象全体の平均が3種類のツールを併用しているのとは対照的です。次に、承認のための引き継ぎを挟むことなく、現場チームに検出事項を修正する権限を与えていました。これは調査対象組織の5分の1未満しか実現できていない体制です。そして最後に、最も厳格な「完了」の定義を採用しており、検証済みの再スキャンによってのみクローズと見なしていました。Cohen氏は、自動化はこうした地ならしの結果として生まれるものだと説明します。「自動化それ自体では取り除けない摩擦を、すでに取り除いた後に初めて実現するものなのです」と同氏は述べています。
既知の脆弱性が繰り返しインシデントに発展している
最も鋭い指摘は、すでに把握されていたはずの脆弱性に関するものです。過去1年間にセキュリティインシデントを経験した組織のうち、そのインシデントの発生以前から自社のインベントリに記録されていた脆弱性が原因だったケースは79%にのぼります。検知そのものは機能していました。しかし対応が間に合わなかったのです。
回答者の約半数が、インシデントの原因となった脆弱性は30日から90日前から既知だったと答えています。自動化やAIを駆使して脆弱性の発見と悪用を高速化する攻撃者たちは、この対応の遅れの中に付け入る隙を見出し続けています。
「修正済み」の定義が侵害の有無を左右する
「完了」の定義は組織によって大きく揺れがあります。回答者の半数は、修正が展開され、再スキャンによって検証された後にのみ脆弱性をクローズしています。残る半数は、確認を伴わないパッチの配布、チケットの担当割り当て、あるいは経営陣によるリスクの正式な受容といった、より緩やかな基準に頼っています。
この選択は結果と密接に結びついています。Cohen氏は回答者を「修復済み」の定義ごとにグループ分けし、各グループの既知脆弱性によるインシデント発生率を照合しました。検証済みの再スキャンを要件とする組織では65.8%だったのに対し、それより緩い定義を採用するグループはいずれも89%から93%の範囲に集中していました。同氏の集計によれば、最も緩い定義を用いるチームは、すでに存在を把握していた脆弱性によって侵害される確率がおよそ40%高くなります。「この点については統計的な検証を行いましたが、データセット全体の中でも特に統計的に明確な結果の一つでした」と同氏は述べています。
Cohen氏はこの2つの発見を一つの言葉に集約しています。「すでに知っていた脆弱性で侵害される組織と、そうならない組織との違いは、検知能力の優劣ではありません。『完了』が『露出がなくなったこと』を意味するのか、それとも『誰かがそれを記録しただけ』なのか、その違いなのです」と同氏は語りました。
障壁は組織の内部にある
修復作業における摩擦は、多くの場合プロセスに起因します。回答者のほぼ全員が何らかの形でこれを経験していると答えました。最も多く挙げられた障壁は優先順位の競合で、修復作業のために確保された時間がなく、障害対応やプロジェクト、事業上の要求に押しのけられてしまう状況です。承認や変更管理の手続きがそれに続きます。多くのチームは修正方法もその手段もすでに把握していますが、遅延は承認や調整の段階で発生しているのです。
翻訳元: https://www.helpnetsecurity.com/2026/07/16/ciso-vulnerability-remediation-gap/