脆弱性診断ツールとは？種類・自動診断と手動診断の違い・企業での選び方

脆弱性診断ツールは、サーバー、ネットワーク機器、Webアプリケーション、クラウド環境、ソースコードなどを自動的に調べ、既知の脆弱性や設定不備を検出するための製品・サービスです。

英国NCSCは、脆弱性スキャンを脆弱性管理プログラムの一部と位置付け、インフラ向けスキャナーとWebアプリケーション向けスキャナーでは対象と得意分野が異なると説明しています。米国CISAもCyber Hygiene Servicesで、インターネット公開資産の継続的な脆弱性スキャンとWebアプリケーションスキャンを別サービスとして提供しています。

ツールを導入する際に注意したいのは、「脆弱性診断ツール」という名称だけで製品を比較しないことです。ネットワーク機器の既知CVEを検出するツールと、Webアプリケーションの認証・入力処理を調べるツール、ソースコードやOSS依存関係を検査するツールでは、確認できる範囲が異なります。

従業員600人以上の企業では、外部公開資産、社内サーバー、クラウド、Webアプリケーション、開発環境が複数部門・グループ会社に分散しやすくなります。ツールの検出精度だけでなく、資産管理、担当者への割り当て、修正期限、再診断、例外管理まで一連の運用として設計する必要があります。

脆弱性診断そのものの目的や種類、実施頻度については、脆弱性診断とは？目的や種類、実施頻度をUS・UK公的機関の推奨から解説で整理しています。ここでは、診断ツールの種類と選び方に絞ります。

脆弱性診断ツールとは

脆弱性診断ツールは、対象システムへ自動的にアクセスし、ソフトウェアのバージョン、公開ポート、設定、HTTPレスポンス、ソースコード、依存ライブラリなどを確認して、既知の脆弱性やセキュリティ上の弱点を検出します。

NIST SP 800-115では、vulnerability scanningを技術的なセキュリティテストの一つとして扱い、組織がシステムやネットワークの脆弱性を発見し、対策を検討するための手段として整理しています。

英国NCSCは、脆弱性スキャンの主な利点として次を挙げています。

• 定期実行やシステム変更を契機に自動実行できる
• 人手より高速に多数のチェックを実行できる
• 多数の資産へ展開しやすい
• 共通的な脆弱性や設定不備を継続的に検出できる
• 修正後の再スキャンに利用できる

一方、自動ツールだけで全ての問題を発見できるわけではありません。NCSCは、自動スキャンはペネトレーションテストのような手動検査と比べて、テストの幅と深さに限界があると説明しています。

脆弱性診断ツールの主な種類

企業で利用する診断ツールは、対象によって分けて考えると選びやすくなります。

1製品ですべてを高精度にカバーできるとは限りません。

英国NCSCは、まず一般的なインフラのスキャンで基礎的なカバレッジを確保し、必要に応じてWebアプリケーションなど専門的なスキャナーを追加する階層型の考え方を示しています。

ネットワーク脆弱性スキャナーで確認できること

ネットワーク・インフラ向けのスキャナーは、ホスト探索やポートスキャンを行い、外部または内部からアクセスできるサービスを調べます。

NCSCによると、代表的な確認対象は次の通りです。

• OS・ソフトウェアの未適用パッチ
• サポートが終了した製品
• 公開ポートやネットワークサービス
• 弱い暗号方式
• 平文通信
• 不要に公開された管理サービス
• セキュリティハードニング不足
• 過度に広いアクセス制御

大規模な社内環境では、全資産を同じ条件で診断するより、インターネット公開、サーバー、クライアント、ネットワーク機器などに分けてスキャン範囲を管理します。

特にVPN、ファイアウォール、リモートアクセス製品などの境界機器は、外部から悪用される脆弱性が繰り返し確認されているため、外部公開資産として優先的に確認します。

Webアプリケーション診断ツールで確認できること

Webアプリケーションスキャナーは、ブラウザに近い形でHTTP/HTTPS通信を行い、Webアプリケーションの応答から脆弱性を検出します。

代表的な対象は次の通りです。

• SQLインジェクション
• クロスサイトスクリプティング（XSS）
• 一部の認証不備
• アクセス制御不備
• 暗号化設定
• 情報露出
• 脆弱なコンポーネント
• Webサーバーの設定不備

ただし、ログイン後の複雑な画面遷移、複数の権限をまたぐ認可、決済や承認などの業務ロジックは、自動スキャナーだけでは十分に確認できない場合があります。

NCSCも、複雑なWebアプリケーションではログイン情報や対象ページを適切に設定しないと十分なカバレッジを得られないとしています。

会員サイトや管理画面を診断する場合は、「トップページをスキャンできるか」ではなく、認証後の機能やAPIまで診断対象に入れられるかを確認します。

自動診断と手動診断の違い

脆弱性診断ツールを導入しても、手動診断が不要になるわけではありません。

NCSCは、自動スキャンで一般的な問題を継続的に処理し、手動のペネトレーションテストは複雑な問題や、自動ツールが見逃す可能性がある部分の検証へ使う考え方を示しています。

「自動か手動か」の二者択一ではなく、日常運用を自動スキャンで回し、重要システムや大規模変更時に手動診断を追加する構成が現実的です。

認証なしスキャンと認証付きスキャンの違い

インフラ診断では、認証情報を使わず外部から見える状態を確認するスキャンと、対象OSへ認証して内部状態まで確認するスキャンがあります。

認証なしスキャンでは、攻撃者に近い外部視点から公開サービスや推定バージョンを確認できます。

一方、認証付きスキャンでは、端末やサーバーにログインして次の情報を確認できます。

• 実際にインストールされているパッケージ
• OSの更新状態
• レジストリや設定
• ローカルソフトウェア
• パッチ適用状況
• ハードニング設定

イスラエル国家サイバー局（INCD）の「Cyber Defense Methodology for an Organization」は、組織内外の全情報システムに対する継続的な脆弱性評価に加え、Credentialed Scanの実施を挙げています。また、自動システムが検出した重大な脆弱性を組織内プロセスで検証することも示しています。

認証付きスキャンを導入する場合は、スキャナー用アカウントの権限を必要範囲に限定し、資格情報の保管・ローテーション・利用ログも管理します。

脆弱性診断ツールの選び方

製品比較では、検出CVE数やダッシュボードの見た目だけで判断せず、自社の資産と運用に合うかを確認します。

1. 診断したい資産を先に決める

最初に確認するのは製品一覧ではなく、診断対象です。

• インターネット公開サーバー
• 社内サーバー
• VPN・ファイアウォール
• Webアプリケーション
• API
• AWS・Azure・Google Cloud
• コンテナ
• Gitリポジトリ
• OSS依存関係
• グループ会社の資産

NCSCは、脆弱性スキャンの前提として資産を特定し、可能であれば資産台帳へ記録するよう示しています。

ツールで見つけられない資産は、脆弱性管理の対象にも入りません。

2. 認証付きスキャンに対応しているか

サーバーや端末のパッチ状況を正確に確認したい場合は、認証付きスキャンが有効です。

製品選定時には、Windows、Linux、ネットワーク機器などの認証方式に対応するか、スキャン用アカウントのロックアウトを防ぐ仕組みがあるかを確認します。

3. 新しい脆弱性への対応速度を確認する

脆弱性データベースが更新されても、診断ツール側に検出ロジックが実装されなければ確認できません。

NCSCは、重大な脆弱性について公表から数日以内に検出できるかを、診断サービス選定時の確認事項として挙げています。

特にインターネット公開製品では、修正版公開直後から攻撃が始まる場合があります。

セキュリティ対策Labが2026年9月24日に報じたWordPress CoreのCVE-2026-87902では、修正版が公開された2026年9月22日と同日に悪用試行が観測され、翌日には攻撃トラフィックが初日の10倍超へ増加しました。

月次スキャンだけでは、次回の定期診断まで攻撃可能な状態が残る可能性があります。重大脆弱性の公表時に臨時スキャンを実行できる運用が必要です。

4. 誤検知・見逃しをどう扱うか

脆弱性診断ツールには、誤検知と見逃しがあります。

NCSCも、脆弱性評価ソフトウェアは完全ではなく、誤検知が疑われる場合は調査したうえで判断するよう示しています。

確認したい機能は次の通りです。

• 検出根拠を確認できるか
• CVEと対象バージョンの対応を確認できるか
• 誤検知として扱った理由を記録できるか
• 例外に期限を設定できるか
• 修正後の再診断ができるか
• 同じ問題の再発を追跡できるか

「False Positive」として非表示にするだけでは、後から判断根拠を確認できません。

5. CVSSだけでなく実悪用情報を扱えるか

検出件数が多い組織では、CVSSが高い順に修正するだけでは対応しきれません。

CISAはKnown Exploited Vulnerabilities（KEV）Catalogを、実際の攻撃で悪用された脆弱性の権威ある情報源として公開し、組織の脆弱性対応優先度へ利用するよう案内しています。

英国NCSCも、対応優先度を単一のCVSSスコアだけで決めず、CISA KEVや脅威インテリジェンス、外部公開状況、事業影響を組み合わせるよう示しています。

セキュリティ対策Labが2026年9月に取り上げたFortiOSのCVE-2025-25249では、Fortinet CNAのCVSSは7.4でしたが、実際の攻撃での悪用が確認され、CISA KEVへ追加されました。

このような脆弱性を「Criticalではないから後回し」としないため、KEVや実悪用情報を取り込めるか、別の脅威インテリジェンスと連携できるかを確認します。

6. オンプレミス型かSaaS型か

NCSCは、診断ツールの提供方式としてオンプレミス型とベンダーホスト型を整理しています。

オンプレミス型は、外部から到達できない社内ネットワークや機密性の高い環境をスキャンしやすく、診断結果を自社内に保持できます。一方で、スキャナー本体や脆弱性データベースの更新を自社で管理する必要があります。

SaaS型は運用負荷を抑えやすく、規模に応じて拡張しやすい一方、内部ネットワークを診断するにはエージェントやスキャナー用ゲートウェイ等が必要になる場合があります。また、自社の脆弱性情報がベンダー環境へ保存されるため、保管場所、アクセス権、契約終了後の削除条件も確認します。

7. 修正管理システムと連携できるか

診断ツールの価値は、脆弱性を見つけた件数ではなく、修正まで追跡できるかで決まります。

従業員600人以上の企業では、サーバー管理、ネットワーク、クラウド、開発、グループ会社など担当が分かれます。

そのため、次の連携を確認します。

• ITSM・チケット管理
• CMDB・資産台帳
• SIEM・SOAR
• EDR
• GitHub・GitLab等
• クラウド管理
• パッチ管理
• レポートAPI

検出事項をExcelへ出力して終わる運用では、再診断や期限管理が属人化しやすくなります。

診断頻度は「年1回」では足りない

英国NCSCは、組織全体の脆弱性評価を少なくとも月1回実施し、成熟した組織では外部公開サービスをさらに高頻度で評価することを案内しています。

また、インフラの脆弱性スキャンは少なくとも月1回、重大な問題を修正した直後にも実行する考え方を示しています。Webアプリケーション向けスキャナーは、新バージョンやソースコード変更時に実行し、可能であれば開発・デプロイパイプラインへ組み込むよう推奨しています。

イスラエル国家サイバー局の方法論でも、全情報システムを対象に継続的な脆弱性評価を行い、環境ごとに数週間・数か月など実施タイミングを定義する考え方が示されています。

頻度は一律ではなく、次の条件で分けます。

年1回の診断だけでは、その翌日に公開された脆弱性を次回診断まで把握できない可能性があります。

ツールで検出できても攻撃を防げないケース

診断ツールが導入されていても、検出結果が修正につながらなければリスクは残ります。

Microsoft SharePoint ServerのCVE-2026-55040は、2026年8月18日にCISA KEVへ追加され、実悪用が確認されています。

診断ツールが対象CVEを検出できても、

• 対象サーバーが資産台帳から漏れている
• スキャン対象外になっている
• 担当部署へ通知されない
• 修正期限が設定されない
• 互換性を理由に放置される
• 修正後に再診断されない

という状態では、脆弱性管理としては完了していません。

NCSCも、脆弱性管理を「発見」だけではなく、資産特定、検出、優先順位付け、修正、修正確認まで含むプロセスとして整理しています。

脆弱性診断ツールとASM・ペネトレーションテストの違い

混同しやすいのがASMとペネトレーションテストです。

診断ツールが高精度でも、そもそも存在を把握していない公開サーバーはスキャン対象になりません。

一方、ASMで資産を見つけても、認証後のWeb機能や社内サーバーの詳細な脆弱性までは確認できない場合があります。

従業員600人以上の企業では、資産発見、脆弱性検出、修正管理、手動検証を一つの製品へ無理に集約するより、それぞれの役割を決めて連携させる方が管理しやすくなります。

無料ツールと有料ツールはどう使い分けるか

無料またはオープンソースの診断ツールでも、特定用途のスキャンや検証は可能です。

ただし、企業利用では検出能力だけでなく、次を確認します。

• 脆弱性データベースの更新頻度
• 商用サポートの有無
• 複数担当者での権限管理
• 大量資産へのスケーラビリティ
• 誤検知管理
• チケット連携
• API
• 監査ログ
• レポート
• SLA
• スキャン結果の保管
• グループ会社の分離管理

少数のシステムを技術者が個別に確認する用途と、数千台の端末・サーバーを複数部門で管理する用途では必要な機能が異なります。

無料か有料かではなく、検知後の運用をどこまでツールへ載せるかで判断します。

導入時に注意したいこと

脆弱性スキャンは通常、安全性を考慮して設計されていますが、本番システムへ大量のリクエストを送るため、対象によっては負荷や副作用が発生する可能性があります。

NCSCは、特に業務上重要で壊れやすいシステムでは、先に非本番環境でテストすることや、危険性の高いチェックを除外できるか確認するよう案内しています。

導入前には次を決めます。

• 本番スキャンを実施できる時間帯
• 負荷試験を避ける対象
• OT・医療機器等のスキャン可否
• アカウントロックを起こさない設定
• スキャナーの送信元IP
• SOCへの事前連絡
• スキャン通信を攻撃と誤認しない方法
• 障害発生時の中止手順
• 診断結果へのアクセス権
• SaaS型の場合のデータ保管場所

診断ツール自体も高い権限や詳細な脆弱性情報を保持するため、管理コンソールへのMFA、管理者権限の制限、監査ログも確認します。

従業員600人以上の企業が確認したい選定チェックリスト

脆弱性診断ツールの導入・見直しでは、次を確認すると比較しやすくなります。

• 自社のインターネット公開資産をすべて対象にできるか
• 社内サーバーやネットワーク機器まで診断できるか
• Webアプリ・APIは専用スキャナーが必要か
• Windows・Linux等の認証付きスキャンに対応するか
• AWS・Azure・Google Cloudの資産を自動検出できるか
• コンテナやOSS依存関係も対象にする必要があるか
• 新しい重大脆弱性を数日以内に検出できるか
• CISA KEVや実悪用情報を優先順位へ反映できるか
• CVSSだけでなく外部公開状況や資産重要度を加味できるか
• 誤検知の根拠確認と例外期限を管理できるか
• 修正後の再スキャンを自動化できるか
• ITSM・CMDB・SIEM等と連携できるか
• 部門・グループ会社別に担当者と権限を分けられるか
• SaaS型の場合、診断結果の保存場所と削除条件を確認したか
• スキャンによるサービス影響を制御できるか
• ツールで見つからない業務ロジック等を手動診断で補完しているか

脆弱性診断ツールの導入目的は、検出件数を増やすことではありません。

「どの資産に問題があるか」「実際に悪用されているか」「誰がいつまでに直すか」「修正できたか」を継続的に管理できる状態を作ることが目的です。ツール選定時には、診断精度だけでなく、資産管理と修正プロセスへ接続できるかまで確認します。

出典

• Technical Guide to Information Security Testing and Assessment – NIST SP 800-115
• Cyber Hygiene Services – CISA
• Known Exploited Vulnerabilities Catalog – CISA
• Vulnerability scanning tools and services – UK National Cyber Security Centre
• Vulnerability management guidance – UK National Cyber Security Centre
• Carry out assessments by triaging and prioritising – UK National Cyber Security Centre
• Cyber Defense Methodology for an Organization – Israel National Cyber Directorate
• 脆弱性診断とは？目的や種類、実施頻度をUS・UK公的機関の推奨から解説 – セキュリティ対策Lab
• WordPress重大な脆弱性 CVE-2026-87902のサイバー攻撃 悪用を確認 – セキュリティ対策Lab
• FortiOSのCVE-2025-25249がサイバー攻撃に悪用、CISA KEVに追加 – セキュリティ対策Lab
• Microsoft SharePointの脆弱性を狙う活動 – セキュリティ対策Lab