「全てを守るのはムリ」 2026年版、脆弱性サービス選定の“現実解”
脆弱性対応は、重要でも後回しになりやすい。中堅・中小企業が限られた人員の中で何を優先し、どんなサービスを選び、どう運用を続けるべきか。セキュリティベンダーや専門家の知見を基に整理する。
MFA（Multi-Factor Authentication）やEDR（Endpoint Detection and Response）、XDR（Extended Detection and Response）など、優先度の高いセキュリティ対策が先行する一方で、脆弱（ぜいじゃく）性対応は「何から手を付けるべきか」「どう優先順位を付けるべきか」が見えにくく、後回しになりやすい。特に、中堅・中小企業や専任の情報システム担当者がいない「兼務情シス」の現場では、見つかった脆弱性の全てに対処するのは現実的ではない。
ここで重要なのは脆弱性対策サービスの位置付けだ。単に脆弱性を見つけるためのものではなく、限られた体制の企業が見落としを減らし、本当に対処すべき対象を絞り込み、継続的に運用を回すための仕組みとして捉える必要がある。
今回は、脆弱性対策サービスを「どう選び、どう回すか」を整理するため、複数の立場から見解を聞いた。Tenable Network Security Japan（以下、Tenable）には全体整理と優先順位付けを、トレンドマイクロには既存対策との関係を、トライコーダの上野宣氏（以下、上野氏）には第三者や攻撃者の視点を、ラックには現場の具体例と運用実務を聞いた。
脆弱性対応は、なぜ「重要だけど後回し」になるのか
脆弱性対応が進まない理由を「セキュリティ意識が低いから」で片付けるのはやや早計だ。背景には、専任人材や予算の不足、日常業務や事業優先の判断、そして「見つかった脆弱性を直す人がいない」という現実がある。各社からの回答を総合すると、対応が遅れる主因は、技術的な難しさそのものよりも、体制や優先順位、経営認識に問題がある。
例えば、一定規模の企業では機動力が生きる場合もある一方、より小規模な企業では、企画を練る時間すらなく、日々の業務に追われて後手に回りやすい。現場では、新しいシステムや業務を回すことが優先され、「作ることが最優先で、そこまで見ていられない」という状況も起きる。つまり、脆弱性対応が遅れるのは、途中で止まる以前に、そもそも着手の優先順位が上がらないことがある。
加えて、兼務体制では脅威情報を追い切れず、資産や優先順位を把握し切れないこともある。経営層がセキュリティを単なるITコストと見ている限り、必要な予算や体制も確保されにくい。脆弱性対策サービスの価値は、こうした状況の中で「何を先に見るべきか」を判断しやすくする点にもあると言える。
MFAやEDR／XDRがあっても、なぜ脆弱性対策が別に必要なのか
「MFAやEDR／XDRを既に導入しているから、脆弱性対策は後回しでもよい」と考える企業もあるかもしれない。だが、トレンドマイクロは、EDR／XDRを侵入後の検知や復旧、脆弱性対策を“侵害前の予防”と位置付ける。ラックも、MFAは認証を強化し、EDR／XDRは侵入後の検知や対応を支えるもの、脆弱性対策は攻撃に使われる隙を減らすものとして整理しており、両者は代替関係ではなく補完関係にあるという見方で一致している。
上野氏も、MFAやEDR／XDRは侵入を「検知、対応」する役割であり、脆弱性対策は「攻撃面を減らす」ためのものだと説明する。多要素認証やEDRが入っていても、既知脆弱性を起点に侵入される事案は現実に起きており、MFA疲労攻撃やトークン窃取のように、認証の強化だけでは防ぎ切れないケースもあるからだ。
Tenableも「攻撃者はEDRなどのエージェントが導入された端末だけを狙うわけではなく、ネットワーク機器や管理者が把握していないサーバなど、監視の死角を突くことがある」と指摘する。つまり、侵入後の検知や復旧を強化するだけでは不十分で、そもそも攻撃ルートになり得る資産や設定上の隙を把握し、先にふさいでおく必要がある。脆弱性対策は、既存対策の代わりではなく、既存対策が前提としている環境そのものを整える意味を持つ。
「全部守る」は無理。では、何を先に守るのか
脆弱性対応を考えるとき、まず捨てるべき前提がある。全てを同じ優先度で守ろうとしないことだ。
Tenableは、「見えないものを守ることはできない」とした上で、まずIT資産の可視化が必要だと説明する。資産が見えて初めて脆弱性を洗い出せるし、その後でリスク管理スコアなどを使って絞り込める。公開されている脆弱性の全てが同じ危険度を持つわけではなく、攻撃に使われないものの危険性まで高く見えてしまう以上、何を先に見るべきかを決める仕組みが必要だという考え方だ。
上野氏は、優先順位付けではCVSS単独ではなく、KEV（実際に悪用されているか）、EPSS（悪用される確率）、インターネットから到達可能か、重要データや特権に直結するかといった条件を重ねて見るべきだとする。トレンドマイクロも、守るべき資産、利用者、データ、攻撃経路を含めて考える必要があるとしており、各社の見解は「技術的な深刻度だけで決めない」という点で重なる。
優先順位を決める際には、まず「止まると困るものか」と「外から触られやすいものか」を見ると整理しやすい。さらに、何が重要か自体が曖昧（あいまい）なら、個人情報や顧客情報、取引情報など、自社の事業継続に直結する情報は何かを洗い出すところから始める必要がある。ラックは「守るべきものが複数ある場合は、まず自社が何を扱っているのかを把握し、その上で優先順位を付けるべきだ」と補足している。
脆弱性対策サービスは、何を助けるのか
脆弱性対策サービスを「脆弱性を見つける道具」とだけ捉えると、その価値を見誤る。
Tenableはサービスの役割を2つに分けている。同社によると、経営層には「わが社は今、安全なのか」という問いへの回答を、現場には「なぜこれを直さなければならないのか」という根拠を提供することがその役割だという。特に重要なのは「優先順位付け」であり、可視化だけでは修正対象が増えるだけで現場は疲弊してしまうということだ。
上野氏も、脆弱性対策サービスの価値は、“情報の洪水”を自社環境に必要な数件へ絞り込むことにあるとみる。さらに、パッチを当てない判断をする場合でも、なぜ今は当てなくてよいのかを説明する材料になり、経営層への説明や予算判断にもつながるとしている。
ラックからは「何が大事で、何をすべきか」を明確にするための手掛かりになるのが脆弱性対策サービスだ、という話が出た。脆弱性の確認サイクルを回すことで、自社の環境に即した判断軸が見え、次に似た状況が生じたときにも、どこから考えればよいかが分かりやすくなる。
つまり、脆弱性対策サービスの価値は、見つけることそのものより、見つけた後にどう動くべきかを判断しやすくすることにある。
見えていない資産が一番危ない
脆弱性対策で厄介なのは、把握している資産の数ではない。むしろ危ないのは、見えていない資産だ。即時導入できるクラウドサービスの普及やサプライチェーンの複雑化、テレワークの導入によって、IT部門が把握していない資産やシャドーITが生まれやすくなっている。これは、多くの現場で共通する課題になっている。現場は「知らないものは守れないが、知るための手段がない」という状況に置かれがちだ。
トレンドマイクロも「見えないものは守れない」という考え方を重視し、新サービス立ち上げ時の設定不備や一時環境、検証環境の残存などが攻撃の入り口になり得るとみる。上野氏も、「自分が把握している境界」と「攻撃者から見える境界」がずれていることが根本問題だと指摘する。
ラックへの取材では、見落としがちな資産の具体例として、内部で使っているツールや古いライブラリ、更新できない端末、昔公開したサイトの残存フォームやサーバなどが挙がった。例えば、管理台帳に載っていない端末や、長く更新されていないシステムが残っていると、管理者が把握しているつもりの範囲の外から侵入される可能性がある。Webサイトのトップページを閉じたつもりでも、サーバ自体が生きていれば別ルートで攻撃され得る。攻撃者は管理台帳を見ない。だからこそ、「見えていないものは守れない」という前提で、外からどう見えているかを点検する必要がある。
サービス選定で見るべきなのは「件数」より「判断の質」
サービス選定では、「どれだけ多くの脆弱性を見つけられるか」「価格が安いか」に目が向きがちだ。だが、現場の運用を考えると、それだけでは足りない。
Tenableは、選定で重視すべきなのは「情報の量」よりも「判断の質」だとする。どれだけ多く見つけられるかより、膨大な脆弱性の中から、今日修正すべき数件を絞り込めるかが重要だという。また、PCやサーバだけでなく、クラウド設定や外部公開資産、IDの不備まで含めて、どこまで横断的に見られるかも差になると指摘している。
上野氏は、PoC（概念実証）で見栄えが良いかどうかよりも、半年後や一年後に運用が続いているかを見るべきだとし、非専門家にも通じる粒度のレポートかどうかを重視する。トレンドマイクロも、脆弱性情報の件数の多さではなく、優先順位付け、対応支援、資産全体を横断管理できるかを見るべきだとする。
ラックは、解決方法が書かれた報告書があること自体は前提になりつつあり、その上で差が出るのは、単発で終わらず継続的に相談できるか、自社の環境に合わせた現実的な提案があるかどうかだと指摘している。穴を見つけることが目的なのか、危険な穴をふさぐことが目的なのかで、必要なサービスの質は変わる。
各社の話を統合すると、サービス選定では「高機能かどうか」だけでなく、「限られた体制でも使い続けられるかどうか」を重視する方が実務には合っている。
単発診断で終わらせず、小さくても回す
最後に重要なのが、導入後にどう運用を回すかだ。
ラックは、全社一斉に大きく回そうとすると、担当が分散している企業では現実的でないことがあるため、まずは小さい単位でも回すべきだと話す。重要なのは、継続して見直し続けることだ。単発診断で終わらせず、少なくとも「何を見るのか」「誰が判断するのか」「どこまで直すのか」という最低限の運用ルールを置くことが、脆弱性対策を止めないための第一歩になる。
Tenableは、「見つけた脆弱性を全部修正する」という運用は“必ず破綻する”としており、本当に危ない上位数％に集中することが継続のコツだと説明する。全てを同じ優先度で扱わず、最大のリスクを減らす運用にすることで、現場の負荷を抑えながらPDCAを回しやすくなるという。
上野氏は、継続運用には、タスクではなく役割として責務を置くこと、既存のIT運用プロセスに組み込むこと、段階的なSLA（Service Level Agreement）を決めることが重要だとする。トレンドマイクロも、チケットやケース管理と連携しながら、共通の優先度で進捗を追えることが重要だとしている。
まずは「見える化して、絞って、回す」
脆弱性対策サービスの価値は、脆弱性を見つけることではない。リソースが限られた体制の企業にとって本当に重要なのは、見えていない資産を減らし、優先順位を絞り込み、何をどう直すかを判断しやすくすることだ。
全部を一度に完璧に守ろうとしても、現実には続かない。まずは、自社にとって止まると困るもの、外から触られやすいものを見える化し、本当に危ない対象から手を付ける。そして、単発で終わらせず、小さくても継続して回る仕組みを作る。脆弱性対策サービスは、そのための判断と運用を支える仕組みとして捉えるべきだ。
Copyright © ITmedia, Inc. All Rights Reserved.