脆弱性診断やバグバウンティの高度化により、組織が保有するシステムから膨大な数の脆弱性が発見される時代になりました。ところが「見つける力」が上がるほど、逆説的に「直す力」の不足が露呈します。あるセキュリティ企業の報告では、短期間に約2万件の脆弱性が見つかった一方で、修正に至ったのは1%未満という厳しい結果が示されました。この数字は個別企業の怠慢というより、サイバー防衛が抱える構造的限界を象徴しています。
脆弱性の“発見”と“解消”は別ゲーム
脆弱性管理はしばしば「スキャンしてパッチを当てる」単純な作業として理解されがちですが、実務はまったく異なります。発見フェーズはツールと人員を投入すれば加速できます。一方、解消フェーズは開発・運用・調達・業務部門の合意形成を伴い、スループットが急激に落ちます。修正率1%未満という数字は、発見件数の分母が増えたことだけでは説明しきれず、修正を阻むボトルネックが複層的に存在することを示します。
なぜ修正が進まないのか：現場で起きている5つの詰まり
棚卸しの不備：資産が把握できない
「どのサーバーの、どのサービスの、どのバージョンに問題があるのか」を正確に把握できないと、修正計画は立ちません。クラウドやSaaS、子会社・委託先、短命な開発環境などが増え、資産台帳が追いつかない組織は少なくありません。発見はできても、責任主体や管理者が曖昧だと修正の所有権が宙に浮きます。
誤検知・重複・重要度のぶれ：優先順位が崩壊する
脆弱性の報告は、同一原因の重複、環境依存の誤検知、実害が成立しない指摘が混在します。CVSS等のスコアだけで並べ替えると、インターネットに露出していない内部系の指摘が上位に来る一方、ビジネス影響が大きい露出資産の軽微な設定不備が埋もれることがあります。トリアージ（精査）に人手が必要な時点で、修正が渋滞します。
運用停止リスク：パッチは“正しいが危険”になり得る
業務システムは可用性が最優先のケースが多く、パッチ適用で障害が起きれば損失は甚大です。レガシー環境、サポート切れOS、依存関係が複雑なミドルウェアでは、修正のたびに検証環境の準備・回帰テスト・リリース調整が必要です。結果として「今は止められない」が常態化し、リスクが先送りされます。
契約と責任の分断：直す権限がない
外部ベンダーが保守するパッケージ、SaaS、委託開発などでは、利用企業が脆弱性を見つけても、修正実装は契約範囲外ということが起こります。改修見積や納期調整が必要になり、セキュリティの緊急度と調達プロセスの時間軸が一致しません。脆弱性管理を「技術課題」ではなく「契約・ガバナンス課題」として捉え直す必要があります。
人材不足と“セキュリティ負債”：直す側が足りない
発見件数が増えるほど、修正に必要なエンジニアリング工数、QA、SRE/運用工数も増えます。しかし現実には、修正担当は既存開発・保守に追われ、セキュリティ修正は割り込みタスクとして積み上がります。これが慢性的な「セキュリティ負債」となり、修正率の低下を招きます。
「見つけた数」より「減らした量」をKPIにする
発見件数の多さは活動量の指標にはなりますが、防御力の指標にはなりません。重要なのは、攻撃者に悪用される確率と事業影響の大きさを下げることです。KPIは次のように再設計すべきです。
- インターネット露出資産の重大脆弱性の平均修正日数（MTTR）
- 期限内修正率（例：Criticalは7日、Highは30日など）
- 再発率（同種の設定不備や依存関係の放置が繰り返されていないか）
- 例外承認の件数と滞留期間（リスク受容が適切に管理されているか）
修正率を押し上げる実務アプローチ
リスクベース・トリアージ：EPSSと露出面を組み合わせる
CVSSに加え、悪用可能性の予測指標（例：EPSS）や、当該資産が外部公開か、認証要否、機密データの有無、横展開の起点になり得るかといった露出面・重要資産性を掛け合わせ、優先順位を現実的な数に絞ります。「全件対応」から「上位X件を確実に潰す」運用への転換が必要です。
“まず塞ぐ”緩和策：仮想パッチと設定変更を標準化
アプリ改修やパッチ適用が間に合わない場合、WAF/IDSのシグネチャ、リバースプロキシのルール、危険機能の無効化、アクセス制御（IP制限・認証強化）、脆弱なエンドポイントの停止など、短期の緩和策で攻撃面を減らします。重要なのは、緩和策を「例外」ではなく「標準手順」として整備し、監査可能にすることです。
パッチ適用を“イベント”から“継続プロセス”へ
定期メンテナンス枠、検証の自動化、段階的ロールアウト、ロールバック手順の整備により、パッチ適用を日常運用に埋め込みます。特にクラウドでは、イミュータブルな更新（新しいイメージへ置換）を前提にすると、修正のスループットが上がりやすくなります。
SBOMと依存関係管理：同じ脆弱性を“全体に一括適用”する
OSS依存が多い現代では、単一のライブラリ脆弱性が多数のプロダクトに波及します。SBOM（ソフトウェア部品表）や依存関係の可視化を進め、「どこに影響があるか」を即時に特定できる体制が修正率を左右します。加えて、ビルド時点で脆弱な依存をブロックするガードレール（CI/CDでのポリシー適用）を導入すれば、流入量そのものを減らせます。
ガバナンス設計：SLAと例外承認を経営のルールにする
修正が進まない最大の理由は、優先順位が「経営課題」として確定していないことです。重大度別の修正SLA、未達時のエスカレーション、例外承認の責任者と期限、委託先を含む責任分界点を明文化し、セキュリティを“お願い”から“約束”へ変える必要があります。
修正率1%未満が突きつける教訓
膨大な脆弱性の発見は、可視化という意味で前進です。しかし、修正率が極端に低い状態は、攻撃者から見れば「選び放題」の状況でもあります。重要なのは、すべてを直す理想論ではなく、限られたリソースで被害を最小化する現実解です。資産管理、優先順位付け、緩和策、継続的なパッチ運用、依存関係の統制、そしてガバナンス。これらを一体として設計しなければ、“見つけるほど苦しくなる”構造は変わりません。
サイバー防衛の成熟度は、スキャン結果の件数ではなく、重大なリスクを期限内に減らせる組織能力で測られるべきです。発見を成果とする段階から、解消を成果とする段階へ。今、問われているのはその転換です。