# 脆弱性診断とは システムに疑似的な攻撃の通信を送るなどして、決めた範囲から攻撃のきっかけになる弱点を洗い出す作業です。対象と時期と方法の決め方、費用、本番環境への影響を解説します。 ## 脆弱性診断とは 脆弱性診断は、専門家やツールがWebアプリケーションやサーバーに疑似的な攻撃の通信を送ったり、アプリ本体を解析したりして、脆弱性の有無を調べる作業です。脆弱性はソフトウェアや設定に含まれるセキュリティ上の弱点を指します。診断すると決めた範囲を[網羅的に調べ、攻撃のきっかけになり得る脆弱性を発見することが目的](https://www.soumu.go.jp/main_sosiki/cybersecurity/kokumin/security/business/admin/07/)です。 たとえば会員向けのWebサイトでは、ログインした利用者が画面のURLの番号を書き換えるだけで他の会員の注文履歴を閲覧できないかを確認します。この種類の脆弱性はIDOR（Insecure Direct Object Reference）と呼ばれます。問合せフォームに細工した文字列を入力してデータベースの中身を取り出す攻撃、SQLインジェクションが成立しないかも確認します。結果は、検出した脆弱性ごとの深刻度、再現の手順、改修の方法を報告書にまとめます。 症状が出る前に全身を調べる健康診断に近い作業です。隣の用語のペネトレーションテストは、顧客情報のサーバーへの到達のような目標を決めて、実際に侵入できるかを試験する作業です。結果として、脆弱性診断は弱点の一覧を、ペネトレーションテストは目標までどこまで侵入できたかとその手順を返します。脆弱性診断の作業は改修の方法を示して報告するまでで、改修の作業そのものは含みません。 ![左右2枠の比較図。左の脆弱性診断の枠には調べた画面や機器のマスが並び、そのうち2つに弱点の印が付く。右のペネトレーションテストの枠は、起点から弱点を2つ経て目標へ進む矢印。強調は脆弱性診断の側](https://media.marketing.kdotdev-tunnel.org/glossary-vulnerability-assessment-1d266edd18c51880687aa5119ad9482074c9903565ffea76a48b99b214f3d8f5.png) ## 診断の種類と方法 診断は対象の部位で分かれ、次の3種類を[部位に応じて組み合わせる必要がある](https://www.digital.go.jp/assets/contents/node/basic_page/field_ref_resources/e2a06143-ed29-4f1d-9c31-0f06fca67afc/3bc45d3c/20220630_resources_standard_guidelines_guidelines_08.pdf)とされています。出典はデジタル庁の政府情報システムにおける脆弱性診断導入ガイドラインで、政府機関向けの参考文書です。民間のサービスの区分でも、[脆弱性診断は同じ3種類で定義されています](https://www.ipa.go.jp/security/ug65p90000019fc0-att/20261009_2.pdf)。この定義は経済産業省の情報セキュリティサービス基準によるものです。 - プラットフォーム診断: サーバー、ネットワーク機器、VPN（Virtual Private Network）機器。不要な通信の受付口の開放、既知の脆弱性がある版のソフトウェア、初期パスワードのままの設定などを検出 - Webアプリケーション診断: 画面とAPI（Application Programming Interface）。他人のデータの閲覧、認証の回避、SQLインジェクションなどを検出 - スマートフォンアプリケーション診断: アプリストアに公開するアプリ本体と、その通信先。通信の暗号化の不備や、アプリに埋め込まれた認証情報などを検出 クラウドの管理画面で設定する公開範囲や権限の誤りは、IPアドレスを対象にする診断では検出できないことがあります。クラウドの設定は脆弱性診断とは別の作業として、管理画面の設定の点検で確認します。 方法にはツールによる自動診断と、専門家による手動診断があります。ツールは効率がよい一方で、[他人のデータを読み書きできるといった仕様に起因する脆弱性の検出が難しく、専門家の人手による診断で補強する必要がある](https://www.digital.go.jp/assets/contents/node/basic_page/field_ref_resources/e2a06143-ed29-4f1d-9c31-0f06fca67afc/3bc45d3c/20220630_resources_standard_guidelines_guidelines_08.pdf)とされています。ツールの結果には[誤検出や、実際には攻撃が困難な指摘も含まれ得る](https://www.digital.go.jp/assets/contents/node/basic_page/field_ref_resources/e2a06143-ed29-4f1d-9c31-0f06fca67afc/3bc45d3c/20220630_resources_standard_guidelines_guidelines_08.pdf)ため、対応の要否は担当者が個別に精査します。 ![スマホアプリ、画面とAPI、サーバーとVPN機器を矢印でつないだ構成の図。それぞれの部位の下に、スマホアプリ診断、Webアプリ診断、プラットフォーム診断が対応している](https://media.marketing.kdotdev-tunnel.org/glossary-vulnerability-assessment-640bda6fdfd89f442880423249d492ab4da8bbbe3bec40bb0a178eb4b55848c3.png) ## 診断で判明すること・判明しないこと 脆弱性診断は、すでに作り込まれた脆弱性を検出する作業です。[将来の脆弱性の発生を防ぐものではない](https://www.digital.go.jp/assets/contents/node/basic_page/field_ref_resources/e2a06143-ed29-4f1d-9c31-0f06fca67afc/3bc45d3c/20220630_resources_standard_guidelines_guidelines_08.pdf)ため、検出した脆弱性は開発の要件や手順に反映して再発を防ぎます。 判明するのは、診断した時点で、診断した範囲に、既知の種類の脆弱性があるかどうかです。診断後に公開された脆弱性、診断の範囲外の画面や機器、診断の手法が想定していない攻撃は対象外です。指摘がなかったことは安全の証明になりません。 ![判明することと判明しないことを3行2列で示す表の図。時点の行は診断した時点と診断後の公開、範囲の行は診断した範囲と範囲外の画面や機器、種類の行は既知の種類と想定外の攻撃。強調は判明する側](https://media.marketing.kdotdev-tunnel.org/glossary-vulnerability-assessment-035e934ee6b5a27a44376d9be63013e6ae0e02440160b4e554c08934b204082a.png) ## 診断の対象・時期・方法をどう決めるか 社外に公開するシステムがある組織では、インターネットから到達できる箇所を、公開前と大きな変更の時点で、ツールと手動を併用して診断します。加えて、運用中のシステムを定期的に診断します。社内専用のシステムや軽微な変更の扱いは、以下の条件で分かれます。 ### 対象はインターネットから到達できる箇所から [外部から攻撃を受ける可能性のある箇所のすべてを診断の対象とする](https://www.digital.go.jp/assets/contents/node/basic_page/field_ref_resources/e2a06143-ed29-4f1d-9c31-0f06fca67afc/3bc45d3c/20220630_resources_standard_guidelines_guidelines_08.pdf)のが基本です。具体的には次の箇所です。 - インターネットに公開しているWebサイトの画面とAPI - 公開しているサーバーのIPアドレス - VPN機器や、インターネットに接続した複合機 - 他のシステムと連携する接続点 過去に診断を実施していない場合は、[社内のネットワークの内側を調べる内部診断より、外部診断を優先する](https://www.digital.go.jp/assets/contents/node/basic_page/field_ref_resources/e2a06143-ed29-4f1d-9c31-0f06fca67afc/3bc45d3c/20220630_resources_standard_guidelines_guidelines_08.pdf)と整理されています。ただし、業務用のネットワークとインターネットに接続するネットワークを分離していない場合は、外部公開のサーバーに加えて、社内の根幹となるサーバーも対象にします。外部公開のサーバーが1台侵入されると、同じネットワークにある社内のサーバーへ直接通信できるためです。金融機関では、この構成の場合の[Active Directoryサーバーやファイルサーバーの診断が基本的な対応事項](https://www.fsa.go.jp/common/law/cybersecurity_guideline.pdf)とされています。出典は金融庁のサイバーセキュリティに関するガイドラインです。 反対に、同じシステムの中でも外部との接続点を持たない箇所の診断は、[脅威の状況に応じて任意](https://www.digital.go.jp/assets/contents/node/basic_page/field_ref_resources/e2a06143-ed29-4f1d-9c31-0f06fca67afc/3bc45d3c/20220630_resources_standard_guidelines_guidelines_08.pdf)とされています。自社で公開するシステムを持たず、SaaS（Software as a Service）だけを利用する組織では、自社で診断する対象はほとんどありません。サービスの本体の診断は、提供者が規約で禁止していることが多くあります。たとえば[AWSも、AWSのサービス自体への診断を禁止しています](https://aws.amazon.com/security/penetration-testing/)。各サービスの公開範囲、共有の設定、管理者の権限の点検が代わりの作業です。 ![診断の対象の分かれ方を2段で示す図。インターネットなど外部から届くかを問い、はいなら公開前、変更時、定期に診断する。いいえなら公開側と分離済みかを問い、はいなら診断が初めてのときは外部の診断を優先し、いいえなら社内の根幹サーバーも診断する。強調はインターネットから届く箇所の診断](https://media.marketing.kdotdev-tunnel.org/glossary-vulnerability-assessment-31db281fe8ebfcd06bcfcc373b47d73cf52c72bda7c87b9663809a3e961895b2.png) ### 時期は公開前と変更時 新規構築のシステムは、公開前に診断します。改修では、次の変更が[診断の目安](https://www.digital.go.jp/assets/contents/node/basic_page/field_ref_resources/e2a06143-ed29-4f1d-9c31-0f06fca67afc/3bc45d3c/20220630_resources_standard_guidelines_guidelines_08.pdf)とされています。 - 外部から入力されたデータの処理の追加や変更。フォームやAPIなど - 画面を動的に生成する処理の追加や変更 - 認証、暗号化、ファイルのアップロードなど、実装に注意を要する処理の追加や変更 文言の修正や画像の差し替えのような軽微な変更では、Webアプリケーション診断の実施は任意です。 定期診断の頻度は、システムの重要度と変更の頻度で決定します。目安としては年1回程度を起点にし、変更の多いシステムや、個人情報や決済を扱うシステムは間隔を短くします。変更が多いほど診断の後に新しい脆弱性が混入する機会が増え、扱う情報が重要なほど漏えいしたときの被害が大きくなるためです。年1回は公的な基準が定める数字ではなく、実務で広く使われる目安です。金融機関では、[対象範囲、実施頻度、リリース前を含む実施時期を手続として定めること](https://www.fsa.go.jp/common/law/cybersecurity_guideline.pdf)が求められています。 ### 方法はツールと手動の併用 権限の確認や画面の遷移のように、そのシステム固有の仕様に依存する脆弱性は、ツールでは検出が困難です。誰がどのデータを閲覧してよいかは仕様書にしか書かれておらず、ツールは閲覧できた結果が正しいかを判定できないためです。開発の途中で開発者がツールを定期的に実行し、公開前と大きな変更時に専門家の手動診断を受ける組み合わせなら、費用と網羅性の釣り合いを取りやすくなります。 政府機関が定期診断を調達するときの[上限の目安](https://www.digital.go.jp/assets/contents/node/basic_page/field_ref_resources/e2a06143-ed29-4f1d-9c31-0f06fca67afc/3bc45d3c/20220630_resources_standard_guidelines_guidelines_08.pdf)は、プラットフォーム診断で10〜30のIPアドレス、Webアプリケーション診断で50〜100のリクエスト、スマートフォンアプリケーション診断で10〜20の画面とされています。リクエストは、画面の表示、フォームの送信、APIの呼び出しといった、サーバーへの1回の送信の単位です。同じ作りの画面が多い場合は代表の1画面に絞り、次回は前回と別の画面を選ぶ方法も示されています。公開前の診断では、外部公開のすべての画面とAPIが対象になるため、規模は上の目安より大きくなることがあります。 ## 診断の費用と運用の負担 ### 診断の費用の決まり方 専門の事業者に依頼する場合、費用は対象の規模で変動します。プラットフォーム診断では[IPアドレスの数に応じて費用が変動する](https://www.digital.go.jp/assets/contents/node/basic_page/field_ref_resources/e2a06143-ed29-4f1d-9c31-0f06fca67afc/3bc45d3c/20220630_resources_standard_guidelines_guidelines_08.pdf)とされ、Webアプリケーション診断は画面やリクエストの数が単位になることが多くあります。現地での作業には追加の費用がかかることがあります。 公開されている料金の例は次のとおりです。いずれも2026年11月1日時点の各社の公開価格で、税別です。 - [サイバーセキュリティクラウド](https://www.cscloud.co.jp/vulnerability-audit/price/): Webアプリケーション診断は40ページ分を含めて135万円から、プラットフォーム診断は5つのIPアドレス分を含めて35万円から - [セキュアスカイ・テクノロジー](https://www.securesky-tech.com/2025/09/02/8553/): Webアプリケーション診断は10リクエストで40万円、10リクエストの追加ごとに30万円。2026年1月以降の価格 事業者と範囲によって大きく異なるため、複数の事業者から同じ対象の一覧で見積もりを取って比較します。 日程は、事業者の予約、診断の作業、報告書の作成を合わせて数週間になることがあり、規模や事業者の空きで変わります。公開日から逆算して、改修と再診断の期間も含めて予約します。 診断の費用のほかに、次の費用と工数を見込みます。 - 診断前の準備: 対象の一覧の作成、関係者への周知、診断用のアカウントとデータの用意。会員Aでログインして会員Bのデータが見えるかを試すには、同じ権限のアカウントが2つ以上要る。管理者の画面があれば管理者用のアカウントも用意する - 改修: 検出された脆弱性の改修。指摘の件数と内容で大きく変わる - 再診断: 改修した箇所の確認。見積もりに再診断の回数と期限が含まれるかを確認する。政府機関の調達の要件は、[報告から少なくとも1か月の間、1回以上の再診断に応じられること](https://www.digital.go.jp/assets/contents/node/basic_page/field_ref_resources/e2a06143-ed29-4f1d-9c31-0f06fca67afc/3bc45d3c/20220630_resources_standard_guidelines_guidelines_08.pdf) - 社内の担当: 報告書を読み、改修の優先順位を決定する担当 改修の予算と担当がないまま診断だけを受けても、脆弱性は残ります。診断の計画は、改修と再診断までを1つの単位として策定します。 ![準備、診断、改修、再診断の4段階を点線の枠で囲み、予算と担当を確保する1つの計画であることを示す図。改修を強調し、抜けると脆弱性が残ると添えている](https://media.marketing.kdotdev-tunnel.org/glossary-vulnerability-assessment-f1f626e8e4b1489c28fb838422b4bb532e8cdc9ab1df7deda580bc90528df797.png) ### 公開を延期する指摘の基準 公開前の診断でどの指摘が出たら公開を延期するかは、診断の前に決定します。対応の基準は[深刻度に基づいて策定することが望ましく、その脆弱性を悪用する攻撃がすでに観測されている場合は基準に関わらず迅速に対応する](https://www.digital.go.jp/assets/contents/node/basic_page/field_ref_resources/e2a06143-ed29-4f1d-9c31-0f06fca67afc/3bc45d3c/20220630_resources_standard_guidelines_guidelines_08.pdf)とされています。たとえば、インターネットから到達でき、他人の情報の閲覧や認証の回避につながる指摘は公開前に改修し、内部の画面の軽微な設定は次の改修に回す、という区分です。 ### 診断の作業が本番環境に与える影響 疑似的な攻撃の通信を送るため、[診断の作業自体にリスクがあります](https://www.digital.go.jp/assets/contents/node/basic_page/field_ref_resources/e2a06143-ed29-4f1d-9c31-0f06fca67afc/3bc45d3c/20220630_resources_standard_guidelines_guidelines_08.pdf)。 - 通信の帯域の圧迫や、システムの異常終了によるサービスの停止 - 攻撃用の文字列を含むダミーのデータがデータベースに残る - 問合せフォームの診断で大量のメールが送信される - データの破損や損失 - 個人情報や機密情報を意図せず閲覧する - 監視の警報が大量に発生する 政府情報システムの診断は、実際の脅威への耐性を確認する目的から、[本番環境での実施が前提](https://www.digital.go.jp/assets/contents/node/basic_page/field_ref_resources/e2a06143-ed29-4f1d-9c31-0f06fca67afc/3bc45d3c/20220630_resources_standard_guidelines_guidelines_08.pdf)とされています。影響を許容できない場合は、本番と同等の構成の検証環境で行います。WAF（Web Application Firewall）のように攻撃を遮断する製品は、[脆弱性の存在を隠すおそれがあるため、診断の間は無効にすることが推奨](https://www.digital.go.jp/assets/contents/node/basic_page/field_ref_resources/e2a06143-ed29-4f1d-9c31-0f06fca67afc/3bc45d3c/20220630_resources_standard_guidelines_guidelines_08.pdf)されています。本番で行う場合は事前にデータをバックアップし、利用の少ない時間帯を選びます。夜間に利用が集中するサービスでは、夜間は避けます。 監視の担当、運用の担当、クラウドの提供者など影響を受ける関係者には事前に周知します。 クラウドでは、提供者の規約が診断できる範囲を定めます。たとえば[AWSは事前の承認なしに診断できるサービスを一覧で定めています](https://aws.amazon.com/security/penetration-testing/)。対象のサービスが一覧にあるか、診断の項目に承認が必要なものがないかを、実施の前に規約の最新版で確認します。 報告書は攻撃の手順書にもなるため、閲覧できる人を限定して保管します。 ### 診断サービスの選び方 経済産業省の情報セキュリティサービス基準への適合が1つの目安になります。基準に適合したサービスは、[IPA（独立行政法人情報処理推進機構）が一覧として公開しています](https://www.ipa.go.jp/security/service_list.html)。一覧への掲載は基準の審査を通過したことを示すもので、IPAによる保証ではありません。手動診断の担当者の経験と、報告書の見本も確認します。 ## よくある誤解 ### 診断で指摘がなければ、そのシステムはその後も安全 診断の翌月に利用中のソフトウェアの脆弱性が公開されれば、状況は変わります。定期診断の間は、利用製品の脆弱性情報を確認し、製品を更新する運用で補います。 ### WAFを導入していれば診断は不要 WAFは既知の攻撃の通信を遮断できますが、脆弱性そのものは残ります。WAFは[脆弱性の存在を隠すおそれがある](https://www.digital.go.jp/assets/contents/node/basic_page/field_ref_resources/e2a06143-ed29-4f1d-9c31-0f06fca67afc/3bc45d3c/20220630_resources_standard_guidelines_guidelines_08.pdf)とされ、診断の間に無効にするのは、残っている脆弱性を確認するためです。遮断の規則を回避する攻撃や、正常な操作に見える権限の不備は、WAFを通過することがあります。 ### 指摘はすべてすぐに改修する 指摘には誤検出や、実際には攻撃が困難なものも含まれます。深刻度の点数だけで決めず、インターネットから到達できるか、扱う情報の重要度、悪用が確認されているかで優先順位を付けます。 最初に診断する対象は、個人情報や決済を扱う公開中のWebサイトです。次の改修の予定に合わせて手動診断の予算と改修の工数を確保すれば、公開前の診断を開発の手順に組み込めます。