脆弱性診断とは？目的や種類、実施頻度をUS・UK公的機関の推奨から解説|セキュリティ対策 Lab

投稿日時: 2026年08月02日更新日時: 2026年08月02日

脆弱性診断とは、Webアプリケーション、ネットワーク、クラウド環境、社内システムなどに存在するセキュリティ上の弱点を洗い出し、悪用される前に修正や緩和策につなげる取り組みです。情報システム部門にとっては、単に診断レポートを受け取る作業ではなく、資産管理、パッチ管理、設定管理、委託先管理を現実的に回すための確認プロセスといえます。

私自身、ネットワークやサーバーサイドの運用・開発に関わってきた中で、脆弱性診断の結果がそのまま実務で使える組織と、レポートだけが残って対応が止まる組織の差を何度も見てきました。脆弱性診断は一度実施すれば終わりではなく、診断対象、実施頻度、修正確認、例外管理まで含めて設計する必要があります。

脆弱性診断とは何かのサマリー

脆弱性診断は、システムやアプリケーションに存在する既知の脆弱性、設定不備、古いソフトウェア、認証やアクセス制御の弱点などを発見し、修正につなげるための取り組みです。
Webアプリケーション診断、プラットフォーム診断、ネットワーク診断、クラウド診断、ソースコード診断、ペネトレーションテストなどがあり、目的や対象によって使い分けが必要です。
英国NCSCはインフラの脆弱性スキャンを少なくとも月1回、重要な修正後は直ちに実施することを推奨し、アプリケーションスキャンは変更時やソースコード変更時に実施する考え方を示しています。
米国CISAはCyber Hygiene Servicesで週次レポートや緊急アラートを提供し、2026年6月に公表したBOD 26-04では、連邦機関向けに悪用状況や公開範囲などを踏まえたリスクベースの修正優先度を示しています。
SEOの観点では、本記事では脆弱性診断の全体像と必要性を説明し、別記事で「脆弱性診断の頻度」「脆弱性診断の費用」「Webアプリケーション診断とペネトレーションテストの違い」などに展開する構成が有効です。

脆弱性診断の整理表

項目	内容
対象	Webアプリケーション、ネットワーク機器、サーバー、クラウド、API、モバイルアプリ、ソースコード、SaaS設定など
主な目的	攻撃に悪用される前に脆弱性や設定不備を発見し、修正や緩和策につなげること
主な検出内容	古いソフトウェア、既知CVE、不要な公開ポート、弱い暗号設定、認証不備、アクセス制御不備、インジェクション、XSS、設定ミスなど
実施頻度の考え方	月次、四半期、年次などの定期診断に加え、システム変更時、リリース前、重大脆弱性公表時、インシデント後に実施する
自動診断の強み	継続的に広範囲を確認しやすく、既知の脆弱性や設定不備の検出に向いている
手動診断の強み	業務ロジック、認可制御、複雑な画面遷移、攻撃シナリオに沿った確認に向いている
ペネトレーションテストとの違い	脆弱性診断は弱点の発見と是正が中心で、ペネトレーションテストは攻撃者視点で侵入可能性や影響を検証する
情報システム部門の役割	対象資産の棚卸し、診断範囲の定義、検出結果の優先度付け、修正管理、再診断、例外リスクの承認を行う

脆弱性診断の概要

脆弱性診断は、企業が保有するIT資産に対して、攻撃者に悪用される可能性のある弱点を調査する取り組みです。ここでいう弱点には、OSやミドルウェアの既知脆弱性だけでなく、Webアプリケーションの実装不備、認証や認可の設計ミス、ネットワーク機器の設定不備、クラウドの公開設定ミス、使われなくなったサーバーやサブドメインの放置なども含まれます。

似た言葉として、脆弱性とは？で解説しているような脆弱性そのものの理解、ASM(アタックサーフェスマネジメント)とは専門家が解説で扱う外部公開資産の継続的な把握、ペネトレーションテスト、セキュリティチェックシートによる委託先確認などがあります。

脆弱性診断は、これらの取り組みと重なりながらも、実際のシステムに存在する技術的な弱点を確認し、修正につなげる点に特徴があります。

脆弱性診断の実務では、診断対象を決めるところから始まります。Webサイトだけを診断するのか、社内ネットワークも含めるのか、認証後の会員画面まで確認するのか、APIや管理画面を含めるのかで、診断の意味は大きく変わります。

ネットワークエンジニアとしての経験から見ても、外から見える公開ポートだけを調べた結果と、認証情報を使って内部構成まで確認した結果では、見つかる問題の種類がかなり異なります。

診断の価値は、脆弱性を見つけることだけではありません。

どの資産に、どのレベルの問題があり、誰が、いつまでに、どのように直すのかを決める材料になることが重要です。

レポート上は重大に見える脆弱性でも、対象が検証環境で外部公開されていない場合と、インターネット公開された本番システムの場合では、対応優先度は変わります。逆に、CVSSスコアだけでは中程度に見える問題でも、認証情報の窃取や個人情報へのアクセスにつながる場合は、早急な対応が必要になります。

脆弱性診断はなぜ必要なのか

脆弱性診断が必要な理由は、企業のシステムが一度作って終わりではないためです。OS、ミドルウェア、ライブラリ、クラウドサービス、SaaS、ネットワーク機器は日々更新され、後から脆弱性が公表されます。昨日まで安全と判断していた構成でも、今日になって重大なCVEが公開されることは珍しくありません。

もう一つの理由は、構成変更や開発変更によって、新しい弱点が入り込むことです。

Webアプリケーションでは、ログイン機能、権限管理、ファイルアップロード、検索機能、外部API連携などの実装で問題が生じます。サーバーやネットワークでは、検証用に一時的に開けたポート、古いTLS設定、管理画面の公開、初期パスワードの残存などが事故につながります。クラウド環境では、ストレージの公開設定、IAM権限の過大付与、セキュリティグループの開放、監査ログの未有効化が典型的な確認ポイントです。

近年は、取引先からセキュリティチェックシートの提出を求められる場面も増えています。

セキュリティチェックシートとは？目的や構成、評価項目の考え方を解説でも触れている通り、委託先やSaaS事業者のセキュリティ体制を確認する際、脆弱性診断の実施状況、診断範囲、検出事項への対応状況は重要な確認項目になります。診断を実施していると回答しても、対象がコーポレートサイトだけで、実際に顧客情報を扱う管理画面やAPIが範囲外であれば、実務上の安心材料としては弱くなります。

攻撃者側の視点でも、脆弱性診断は重要です。インターネット公開資産は常に探索されており、既知脆弱性や設定不備が残っている環境は、標的型攻撃でなくても機械的なスキャンやボットによって攻撃対象になります。情報セキュリティの脅威とは？リスクとの違いも解説で整理したように、脅威そのものをなくすことはできませんが、自社の弱点を把握して修正することで、発生可能性と影響度を下げることはできます。

脆弱性診断は、経営や監査の観点でも意味があります。重大な脆弱性が見つかった場合、対応に必要な予算、人員、停止時間、リリース調整を説明するには、客観的な診断結果がある方が話を進めやすくなります。特にレガシーシステムや外部委託システムでは、情報システム部門だけで修正を完結できないことも多いため、診断結果をリスク登録し、優先度を付けて継続的に追う運用が欠かせません。

脆弱性診断の種類

以下の表をそのまま記事内の「脆弱性診断の種類」セクションに入れられます。

種類	主な診断対象	確認する内容	実施タイミングの目安	補足
Webアプリケーション診断	コーポレートサイト、会員サイト、申込フォーム、管理画面、ECサイトなど	認証・認可不備、SQLインジェクション、クロスサイトスクリプティング、CSRF、セッション管理不備、ファイルアップロード機能の不備など	新規公開前、大規模改修後、年1回以上	外部公開サービスでは優先度が高い診断です。個人情報や決済情報を扱う場合は特に重要です。
プラットフォーム診断	サーバー、ネットワーク機器、ミドルウェア、OS、VPN機器、ファイアウォールなど	不要なポート開放、古いソフトウェア、設定不備、既知脆弱性、暗号化設定、管理画面の露出など	新規構築時、構成変更後、定期的に月次または四半期ごと	インターネット公開資産の棚卸しと組み合わせると効果が高くなります。
ネットワーク診断	社内LAN、拠点間ネットワーク、DMZ、無線LAN、リモートアクセス環境など	セグメント分離、不要な通信経路、内部からの横展開リスク、無線LAN設定、認証方式など	ネットワーク変更時、拠点追加時、年1回程度	侵害後の被害拡大を抑える観点で重要です。
API診断	REST API、GraphQL API、外部連携API、モバイルアプリ用APIなど	認証・認可不備、過剰なデータ返却、レート制限不備、IDOR、入力値検証不備など	API公開前、仕様変更後、年1回以上	Web画面から見えない処理が多いため、仕様書やAPIドキュメントを使った診断が有効です。
スマートフォンアプリ診断	iOSアプリ、Androidアプリ、業務用モバイルアプリなど	アプリ内の秘密情報、通信の暗号化、証明書検証、端末内保存データ、改ざん耐性、API連携部分など	新規リリース前、大幅アップデート時	アプリ本体だけでなく、連携するバックエンドAPIの診断も必要です。
クラウド設定診断	AWS、Azure、Google Cloud、SaaS、クラウドストレージなど	公開設定、IAM権限、ログ設定、暗号化、ネットワーク制御、管理者権限の過剰付与など	クラウド環境構築時、権限変更時、継続的に	設定変更が頻繁に発生するため、単発診断だけでなく継続的な監視が向いています。
ソースコード診断	自社開発アプリケーション、業務システム、API、バッチ処理など	安全でない実装、入力値検証不備、認証・認可の実装ミス、秘密情報の埋め込み、脆弱なライブラリ利用など	開発中、リリース前、CI/CDへの組み込み	実行中のシステムを外部から診断するだけでは見つけにくい問題を発見できます。
ペネトレーションテスト	企業ネットワーク、重要システム、公開サービス、Active Directory環境など	実際の攻撃シナリオに基づく侵入可能性、権限昇格、内部展開、重要情報への到達可能性など	重要システム導入後、年1回程度、監査前	脆弱性の有無だけでなく、実際にどこまで侵害され得るかを確認する目的で実施します。
Active Directory診断	AD、Entra ID、ID管理基盤、特権アカウント管理など	特権アカウントの管理不備、古い認証方式、過剰権限、パスワードポリシー、横展開リスクなど	AD構成変更時、M&A後、年1回程度	ランサムウェア被害では認証基盤の侵害が被害拡大につながるため、優先度が高い領域です。
設定レビュー・構成レビュー	システム設計書、クラウド設定、ネットワーク構成、セキュリティ製品設定など	設計上の抜け漏れ、アクセス制御、ログ取得、監視設計、バックアップ設計、運用ルールとの整合性など	設計段階、リリース前、構成変更時	実機診断の前段階として実施すると、設計起因の問題を早期に潰しやすくなります。

脆弱性診断には複数の種類があり、対象と目的によって使い分ける必要があります。代表的なものは、Webアプリケーション診断、プラットフォーム診断、ネットワーク診断、クラウド診断、ソースコード診断、モバイルアプリ診断、ペネトレーションテストです。

Webアプリケーション診断は、ログイン画面、会員機能、管理画面、フォーム、検索、ファイルアップロード、APIなどを対象に、入力値処理や認証、認可、セッション管理、個人情報の取り扱いなどを確認します。SQLインジェクション、クロスサイトスクリプティング、認可不備、CSRF、SSRF、ファイルアップロード不備、情報露出などが主な確認項目です。自動スキャナーで検出できる問題もありますが、業務ロジックや権限の抜け道は手動確認が重要になります。

プラットフォーム診断やネットワーク診断は、サーバー、ネットワーク機器、OS、ミドルウェア、公開ポート、暗号設定、不要サービス、既知CVE、サポート切れ製品などを確認します。インターネット側から確認する外部診断と、社内ネットワーク側から確認する内部診断があります。外部診断では攻撃者から見える攻撃面を把握し、内部診断では侵入後の横展開や社内システムの弱点を把握しやすくなります。

クラウド診断は、AWS、Microsoft Azure、Google Cloudなどの設定を対象に、公開ストレージ、IAM権限、ネットワーク設定、ログ設定、暗号化、管理者アカウント、鍵管理、コンテナやサーバーレス構成の問題を確認します。クラウドでは、ソフトウェアの脆弱性だけでなく、設定ミスが重大事故につながります。オンプレミスの発想のままでは見落としやすいため、クラウドサービスごとの責任共有モデルを踏まえた診断が必要です。

ソースコード診断は、アプリケーションのコードを確認し、実装段階で混入した脆弱性を洗い出す方法です。SAST、SCA、シークレットスキャンなどのツールを使うこともあります。開発初期から取り入れれば、リリース直前に大きな修正が必要になるリスクを下げられます。OSSやサードパーティライブラリの利用が増えている現在では、依存関係に含まれる既知脆弱性の確認も重要です。

モバイルアプリ診断では、AndroidやiOSアプリを対象に、通信の安全性、認証情報の保存、API連携、改ざん耐性、端末側に保存される機密情報、証明書検証などを確認します。モバイルアプリはサーバー側APIと一体で動くため、アプリ単体ではなく、バックエンドAPIも含めて確認する設計が望ましいです。

ペネトレーションテストは、脆弱性診断で見つけた弱点や想定シナリオをもとに、攻撃者視点で侵入可能性や被害の広がりを検証する取り組みです。英国NCSCは、ペネトレーションテストを主要な脆弱性発見手段としてではなく、組織の脆弱性評価・管理プロセスに対する保証手段として位置づけています。年1回だけペネトレーションテストを行い、その間の脆弱性管理を行わない運用では、長期間にわたって弱点を見逃す恐れがあります。

米国・英国の公的機関が示す脆弱性診断の頻度と内容

米国と英国の公的機関の資料を見ると、脆弱性診断や脆弱性スキャンは、年1回のイベントではなく、継続的な脆弱性管理プロセスの一部として扱われています。特に近年は、単純にCVSSスコアだけで判断するのではなく、インターネット公開有無、実際の悪用状況、業務影響、修正可能性、代替策の有無を踏まえて優先度を決める流れが強まっています。

米国CISAは、Cyber Hygiene Servicesでインターネットに面したシステムの脆弱性スキャンを提供しており、週次レポートと緊急性の高い検出事項に関するアドホックなアラートを案内しています。これは米国の重要インフラ組織などを対象にした支援サービスですが、民間企業にとっても、外部公開資産を継続的に見続ける運用の参考になります。

2026年6月10日にCISAが公表したBOD 26-04は、米国連邦民間行政機関向けの拘束力ある運用指令です。旧BOD 19-02や旧BOD 22-01の考え方を整理し、脆弱性対応をリスクベースで優先付ける内容に改めています。対象が外部公開されているか、既に悪用が確認されているか、攻撃が自動化可能か、悪用時に得られる権限や影響がどの程度かを踏まえ、最も危険なものは3日以内の修正または緩和とフォレンジックトリアージを求める考え方が示されています。

NISTの管理策では、脆弱性監視とスキャンは、組織が定めた頻度で実施し、新たに影響する脆弱性が確認された場合にも実施するものとして位置づけられています。NIST SP 800-53のRA-5やNIST SP 800-171の脆弱性監視・スキャンの考え方は、頻度を固定値で一律に決めるのではなく、システムの重要度、リスク、継続的監視の方針に応じて決める設計です。

英国NCSCは、脆弱性スキャンツールとサービスに関するガイダンスで、インフラの脆弱性スキャンを少なくとも月1回、または重要な問題を修正した直後に実施することを目安として示しています。アプリケーションスキャンについては、新しいバージョンを導入した時、対象アプリケーションに変更を加えた時、カスタムアプリケーションのソースコードがコミットされた時に実施する考え方を示しています。

同じくNCSCは、ペネトレーションテストについて、特定時点の確認にすぎない点を明確にしています。ペネトレーションテストは有効な手段ですが、年1回だけ実施して通常の脆弱性管理を止めると、その間に存在する脆弱性を長く見逃す可能性があります。これは日本企業にもそのまま当てはまります。年次診断は必要ですが、月次スキャン、変更時の診断、重大脆弱性公表時の緊急確認を組み合わせる方が現実的です。

英国政府は、公共部門向けにVulnerability Monitoring Serviceも進めています。政府公開情報では、公共部門のインターネット公開資産に対する継続的な監視により、ドメイン関連の深刻な脆弱性の修正時間を大きく短縮したと説明されています。英国政府セキュリティのポリシーでは、中央政府機関と関連機関がインターネット公開ドメインや資産をVMSの監視対象として承認する方針も示されています。

これらを踏まえると、日本企業が実務で参考にしやすい頻度は次のように整理できます。外部公開インフラは少なくとも月1回、WebアプリケーションやAPIはリリース前と変更時、重大脆弱性が公表された製品を使っている場合は都度、重要システムや個人情報を扱うシステムは年1回以上の手動診断やペネトレーションテストを組み合わせる形です。サプライチェーンや委託先の確認では、診断実施の有無だけでなく、診断範囲、最終実施日、重大指摘への対応状況、再診断の有無を確認する必要があります。

脆弱性診断結果を実務で活かすポイント

脆弱性診断でよくある失敗は、診断の実施そのものが目的になってしまうことです。診断会社からレポートを受け取り、重大度の高いものだけを修正し、残りは共有フォルダに保管したままになるケースは少なくありません。診断結果は、修正期限、担当者、暫定対応、恒久対応、再診断、例外承認まで紐づけて管理して初めて価値が出ます。

対応優先度は、CVSSスコアだけで決めるべきではありません。インターネットから到達可能か、認証なしで悪用できるか、既に攻撃に使われているか、個人情報や認証情報に影響するか、業務停止につながるかを合わせて判断します。CISAがBOD 26-04で示した方向性も、静的なスコアだけでなく、公開範囲や悪用状況を踏まえて判断する考え方です。

診断範囲の管理も重要です。資産台帳にないサーバー、使われていないサブドメイン、退職者が管理していたクラウドアカウント、検証用に作ったままの環境は、診断対象から漏れがちです。ASMや外部公開資産の棚卸しと脆弱性診断を連携させることで、診断対象の抜け漏れを減らせます。

委託先管理でも、脆弱性診断の扱いは重要です。SaaSや業務委託先に対して、診断を実施していますかと聞くだけでは不十分です。対象範囲は本番環境か、管理画面やAPIを含むか、第三者による診断か、自社診断か、重大指摘は修正済みか、再診断は済んでいるかまで確認しなければ、実際のリスクは見えません。

脆弱性診断の結果を開発や運用に戻すことも欠かせません。同じ種類の指摘が毎回出る場合、個別の修正だけでなく、設計レビュー、コーディング規約、CI/CDでの自動スキャン、クラウド設定テンプレート、パッチ適用プロセスそのものを見直す必要があります。毎回同じ脆弱性を直す組織より、同じ脆弱性が入りにくい仕組みに変えられる組織の方が、長期的なコストは下がります。

情報システム部門への示唆

情報システム部門は、脆弱性診断を年次イベントとしてだけ扱わず、日常運用の中に組み込む必要があります。最低限、インターネット公開資産の棚卸し、外部公開インフラの月次スキャン、Webアプリケーションのリリース前診断、重大脆弱性公表時の緊急確認、診断後の再確認を運用に入れるべきです。

診断対象を決める際は、コーポレートサイトだけでなく、顧客情報を扱う管理画面、API、VPN、リモートアクセス機器、クラウドストレージ、SaaS連携、開発・検証環境も確認対象に含める必要があります。攻撃者は、会社が重要だと思っているシステムだけを狙うわけではありません。放置された小さな入口が、認証情報の窃取や社内侵入につながることがあります。

修正管理では、診断結果をチケット化し、重大度、到達可能性、悪用状況、業務影響、修正期限、担当部署を明確にします。すぐに修正できない場合は、WAF、アクセス制限、ネットワーク分離、機能停止、監視強化などの暫定策を設定し、例外としてリスク登録します。例外は現場判断だけで放置せず、システムオーナーやリスク責任者が期限付きで承認する運用にすることが重要です。

経営層や監査部門には、診断件数や検出件数だけでなく、重大脆弱性の残存件数、平均修正日数、再発している指摘、診断対象外の資産、例外承認中のリスクを報告すると実態が伝わりやすくなります。脆弱性診断は、実施したかどうかではなく、見つかった問題をどれだけ早く、確実に減らせているかで評価すべきです。