発見と解消の非対称性
脆弱性診断やバグバウンティの高度化で、短期間に大量の脆弱性が洗い出される時代である。一方、ある報告では約2万件を検出しても修正は1%未満にとどまった。これは担当者の怠慢というより、修正工程が合意形成や検証を伴う「別ゲーム」であることを示す。スキャン強化だけでは防御力は上がらない。
解消は開発・運用・調達・業務部門を跨ぎ、可用性や納期の制約を受ける。結果としてバックログが膨らみ、攻撃者にとっては「選び放題」の状態になり得る。情シスは検出数ではなく、事業影響の大きいリスクを期限内に減らす運用へ転換すべきである。
修正が滞留する典型ボトルネック
第一に資産棚卸しの不備である。クラウド、SaaS、委託先や短命環境が増えるほど、責任主体が曖昧になり、修正の所有権が宙に浮く。どのシステムのどのバージョンかが特定できなければ計画も立たない。台帳と管理者の紐付けが出発点となる。
第二に誤検知・重複・重要度のぶれで優先順位が崩壊する。CVSSの並べ替えだけでは、露出面や業務重要度が反映されず、トリアージ工数が詰まる。第三にパッチ適用の停止リスクである。回帰テストやリリース調整が重く、「今は止められない」が常態化する。第四に契約・責任分界の問題で、SaaSやパッケージでは利用企業が直す権限を持たないことがある。
KPI再設計とリスクベース運用
「見つけた数」は活動量の指標であり、防御力の指標ではない。情シスのKPIは、露出資産の重大脆弱性MTTR、重大度別の期限内修正率、再発率、例外承認の滞留期間などに置くべきである。これにより、現場の優先順位と経営判断を同じ物差しに揃えられる。重要なのは全件対応の理想論ではなく、上位リスクを確実に減らす現実解である。
優先順位付けはCVSSに加え、悪用可能性の予測（EPSS等）や外部公開有無、認証要否、機密データの有無といった露出面を組み合わせ、対応対象を絞る。修正が間に合わない場合はWAF/IDS、アクセス制御、危険機能の無効化などの緩和策を標準手順化し、例外ではなく監査可能な統制として運用する。
継続的パッチと依存関係・ガバナンス整備
パッチ適用はイベントではなく継続プロセスとして設計する。定期メンテ枠、検証自動化、段階ロールアウト、ロールバック手順を整備し、変更のスループットを上げる。クラウドではイミュータブル更新（新イメージへ置換）を前提にすると回しやすい。加えてSBOM等で依存関係を可視化し、影響範囲特定を迅速化することで、同一脆弱性の横展開を抑えられる。
最後に、重大度別の修正SLA、未達時のエスカレーション、例外承認の責任者と期限、委託先を含む責任分界を明文化し、セキュリティを「お願い」から「約束」に変える必要がある。修正率1%未満という現実は、発見強化だけでは限界があることの警告である。情シスは資産管理、トリアージ、緩和策、継続パッチ、依存関係管理、ガバナンスを一体で設計し、解消を成果とする体制へ移行すべきだ。