バグを見つけるのは簡単ですが、真の課題はそれを修正することです――セキュリティの一掃作業に予算をつけるよう取締役会を説得する方法をご紹介します。
セキュリティリーダーたちは可視化の面で大きく前進してきました。今日、多くの組織はアプリケーションや依存関係、開発パイプライン全体にわたる脆弱性を、以前よりもはるかに一貫した形で特定できるようになっています。しかし、根本的な不均衡は依然として残っています。脆弱性は修正できるペースよりも速く発見され続けているのです。
この不均衡は拡大しています。現在、組織の82%がセキュリティ負債を抱えているとされています。セキュリティ負債とは、1年以上未解決のまま蓄積された脆弱性のことを指します。同時に、「深刻」かつ「悪用される可能性が高い」と分類される脆弱性の割合も増加を続けています。
この組み合わせは現実的な結果をもたらします。脆弱性は単に蓄積しているだけでなく、発見され悪用されるまでの間、本番環境に長期間残り続けているのです。
同業のCISOたちとの会話では、議論の焦点が変わってきています。今の課題は、この現実を経営層の共感を得られるビジネスケースに落とし込み、修正体制への投資を促すことです。ここでは、そのための6つの方法をご紹介します。
セキュリティ負債を金融債務と同様に扱う
セキュリティ負債は、金融債務と非常によく似た振る舞いをします。時間とともに蓄積し、放置すれば複利のように膨らみ、事業に継続的なコストをもたらします。そのコストは、リリースの遅延、緊急対応での修正作業、監査での指摘事項、インシデント対応といった形で表面化します。
これを効果的に管理するには、金融リスクに適用するのと同じ規律が求められます。つまり、負債の総量と重大度の高い部分を測定し、削減目標を設定し、時間の経過とともに進捗を追跡することです。また、すべての脆弱性を同列に扱うのではなく、許容できるリスクの水準とそうでない水準を区別することも重要です。
セキュリティ負債は経営層のレベルで可視化されるべきだと、私は考えています。経営陣は日常的に財務パフォーマンスや業務レジリエンス、サービスの信頼性を追跡しています。セキュリティ負債も同じカテゴリーに属するべきものです。それは組織が抱えるリスクエクスポージャーと、それを時間をかけて管理する能力を映し出しているからです。
多くの組織は脆弱性そのものへの認識は十分に持っています。制約となっているのは、それに対応する能力です。
修正体制の能力こそが、セキュリティ負債が増えるか減るかを左右します。新たに発見される脆弱性の量が組織の修正能力を上回れば、未対応分は積み上がり、リスクエクスポージャーは増大します。この力学は、検知ツールの精度がどれほど優れていても変わりません。
私の経験上、この制約を数値で示すことが重要です。具体的には、発見件数と修正件数のギャップを示すこと、リスクの高い脆弱性が未対応のまま残っている箇所を特定すること、それらがどれだけの期間残り続けているかを明らかにすることです。こうしたデータがあれば、小手先の効率改善だけではこのギャップを埋められないことが明確になります。
修正体制の能力を業務指標の言葉で提示することで、議論を経営層の優先事項と噛み合わせやすくなります。経営層はエンジニアリングのスループットやクラウド支出、サービス可用性といった制約については理解しています。修正体制の能力も、同じように扱うべきです。
重要システムにおける悪用可能なリスクに焦点を当てる
セキュリティ負債は、事業への影響と結びついて初めて意味を持ちます。
すべての脆弱性が同じレベルのリスクを持つわけではありません。最も重要なのは、悪用される可能性が高く、かつ事業にとって重要なアプリケーションに存在する脆弱性です。
従来の重大度スコアリングでは、この点を十分に捉えきれません。共通脆弱性評価システム(CVSS)は依然として有用ですが、その脆弱性に到達可能かどうか、重要なシステム内に存在するかどうか、悪用手法が容易に入手できるかどうかまでは反映していません。
実践的なアプローチとしては、既存のスコアリングモデルに悪用可能性と事業コンテキストという層を重ねる方法があります。これにより、直ちに対応が必要な高リスクの脆弱性群を絞り込むことができます。多くの環境において、これは発見された脆弱性全体のうち比較的小さな割合にとどまりますが、潜在的な影響の大部分を占めています。
この対象群にリソースを集中させることで、組織は最も効果の大きい部分にリソースを振り向けられます。このアプローチは、リスクをビジネスの言葉で伝えやすくするという利点もあります。
「クラウンジュエル」アプリケーションを優先する
リスクはアプリケーション間で均等に分布しているわけではありません。
どの組織にも、他よりも重要度の高いシステムが存在します。顧客向けプラットフォームや収益を生むサービス、機密データを扱うアプリケーションなどがこれに該当します。こうした領域が侵害された場合、事業への影響は不釣り合いに大きくなります。
こうした「クラウンジュエル」アプリケーションに修正作業を集中させることで、成果を早く得られます。私たちの調査では、脆弱性のうち11.3%が重大度・悪用可能性ともに高いという結果が出ています。最も重要なシステムに最高レベルの保護を確保することで、影響の大きいインシデントの発生可能性を下げられます。
明確な目標を設定することで、この焦点をさらに強化できます。定められた期間内に、組織は重大なセキュリティ負債を削減し、高リスク脆弱性が残存する期間を短縮し、主要システムにおけるリスクエクスポージャーに厳格な閾値を維持することができます。こうした目標があれば、セキュリティ活動を経営層が理解し支持できる事業成果へと変換できます。
リスクを反映した指標を確立する
指標は行動を形作るうえで中心的な役割を果たします。
多くの組織は依然として、発見または解決した脆弱性の件数に頼っています。こうした指標は一定の文脈を提供するものの、リスクが増加しているのか減少しているのかまでは示しません。
より効果的な指標は、リスクエクスポージャーそのものに焦点を当てたものです。具体的には、重要システムにおける重大または悪用可能な脆弱性の件数、それらの脆弱性の平均残存期間、そして時間の経過に伴う傾向などです。これらを組み合わせることで、リスクがどのように推移しているかをより明確に把握できます。
こうした指標を組織の目標に結びつけることで、説明責任を強化できます。セキュリティ負債の削減はOKRに組み込むことができ、重大な負債の削減、脆弱性の残存期間の短縮、高リスクアプリケーションにおける許容閾値の維持について、具体的な目標を設定できます。
リスク受容を正式なプロセスとして位置づけることも重要です。未対応のまま残る高リスクの脆弱性については、事業側の承認と明確な期限を必須とすべきです。これにより、リスクが意図的に認識され、管理されることが担保されます。
セキュリティの成果を改善するには、対応能力への継続的な投資が欠かせません。
修正体制の能力を拡大する方法はいくつかあります。セキュリティ関連の作業に専任のエンジニアリング時間を割り当てる、修正作業を開発ワークフローに組み込む、手作業の負担を減らすために自動化を導入するといった方法です。AI支援による修正や自動化されたガイダンスは、開発速度を損なうことなく、チームがより効率的に脆弱性へ対応する助けとなります。
新たなセキュリティ負債の発生を防ぐことも同様に重要です。リリース前に高リスクの脆弱性を解消することを義務づけるといったポリシーは、新たなリスクエクスポージャーの発生を抑えるのに役立ちます。これにより、時間の経過とともに修正チームにかかる全体的な負荷が軽減されます。
こうした変更はイノベーションを妨げるものではありません。むしろ、安全かつ一貫してソフトウェアを提供するための条件を整えるものです。
リスク削減に向けて事業全体の足並みを揃える
セキュリティ負債はセキュリティ部門だけの問題にとどまりません。組織のレジリエンス、規制対応の姿勢、そして自信を持ってソフトウェアを提供できる能力にも影響を及ぼします。
CISOは、この課題をめぐって関係者の足並みを揃えるうえで中心的な役割を担います。セキュリティ負債を事業への影響、対応能力の制約、測定可能な成果という観点から捉え直すことで、議論を技術的なバックログ管理から企業全体のリスク削減へと転換できます。
この足並みを揃えることは、投資を確保するうえで極めて重要です。経営層が修正体制の能力と事業リスクの関係性を理解すれば、予算配分や優先順位づけ、トレードオフに関する意思決定はより明確になります。
セキュリティ負債は今後もなくなることはありません。重要なのは、それをいかに効果的に管理し、測定するかです。例えば、良い目標の一例は、人員増だけに頼るのではなく、ツールへの投資によって修正能力を倍増させることです。
セキュリティ負債を測定・統制し、その削減に積極的に投資している組織は、大規模な環境でもリスクをコントロールしやすい立場にあります。そうでない組織は、可視性が向上したとしても、リスクエクスポージャーが拡大し続けることになるでしょう。
本記事はFoundry Expert Contributor Networkの一環として掲載されています。
参加をご希望の方はこちら
