脆弱性診断とは？中小企業のサイトで頼む前に決める対象・範囲と、診断から直すまでの流れ

脆弱性診断は、自社のサイトやサーバーに攻撃に使われる弱点がないかを調べることです。 頼む前に「対象・範囲・期間・検査の許可」を具体的に決め、修正を担当する人も確保します。 診断は「依頼→診断→報告書→修正→再診断」で1周とし、日常は脆弱性情報を見て更新します。

脆弱性診断とは

脆弱性診断とは、Webサイトやサーバーのプログラム、設定などに、攻撃に悪用される弱点がないかを調べる検査です。情報漏えい、不正操作、改ざんなどにつながる問題を探し、修正するための根拠を整理します。合意した対象と項目について行うため、対象外の機能や、その後に判明する問題まで確認できるわけではありません。

ECサイトでは、商品が正常に表示されることと、顧客情報が適切に守られていることは別の確認事項です。会員情報の閲覧権限や注文処理など、画面の見た目では分からない問題も診断の対象になります。

経営者は「診断を受けたか」に加え、何を調べ、誰が直し、どう確認したかまで把握することが大切です。Web担当者は、診断会社と開発・保守の担当者をつなぎ、修正に進める状態を整えます。

脆弱性診断の種類

脆弱性診断は、調べる対象と検査の目的を分けて考え、自社の確認したい問題に合う種類を選びます。

上の表には、検査する対象による分類と、検査の目的・手法による分類が含まれています。Webアプリ診断にも自動と手動があり、プラットフォーム診断を頼めば購入処理まで調べてもらえる、という関係ではありません。

ペネトレーションテストと脆弱性診断は、攻撃目的への到達を確かめるか、弱点を洗い出すかという主眼が違います。網羅性を期待する検査と目的を取り違えず、依頼時には確認したいことを言葉にします。

脆弱性診断ツールと人による診断の違い

脆弱性診断ツールは検査を効率化できますが、業務仕様に起因する問題は、人の判断による補強が必要です。会員ごとの閲覧権限や処理順序など、手動で確認する項目と、誤検出を精査する範囲を確かめます。無料で使える公的な道具には、IPAのチェックリストや、ログから攻撃の兆候を調べるiLogScannerがあります。チェックリストは技術的な検査の代替ではなく、iLogScannerも弱点を網羅的に探す道具ではありません。無料という利用条件だけで、各ツールや資料で確認できる範囲を同一視しないことが大切です。

情報セキュリティサービス基準と適合サービスリスト

経済産業省の「情報セキュリティサービス基準」は、技術要件と品質管理要件を確認するための基準です。専門性のある要員に加え、サービス仕様、報告書のレビュー、顧客情報の保護なども確認事項になります。

IPAの適合サービスリストには、審査登録機関が基準への適合を認めたサービスが掲載されています。掲載はIPAによる保証を意味しないため、契約するサービス名称、登録有効期限、対応する診断を確認します。同リストでは、ペネトレーションテストを脆弱性診断のオプションとして位置付けています。IPA「情報セキュリティサービス基準適合サービスリスト」

頼む前に決めること

脆弱性診断を頼む前には、対象の一覧と実施条件を文書にし、診断会社と運用担当者の認識をそろえます。

脆弱性診断を依頼する前のチェックリスト

• [ ] 対象のURLと機能を整理し、ログイン後の画面やAPIも含め、漏れがないよう一覧にします。
• [ ] 対象・対象外の範囲と、検査する利用者権限、自動・手動それぞれで確認する範囲を決めます。
• [ ] 実施期間、検査可能な時間帯、報告書の納品日、修正と再診断まで含めた予定を決めます。
• [ ] 本番環境か検証環境かを選び、本番との構成や設定、外部連携の違いを具体的に整理します。
• [ ] 検査を許可できる責任者を確認し、実施中の異常時に使う連絡先と、検査の中止条件を決めます。
• [ ] サーバー会社や外部サービスへの事前の連絡・申請が必要か、契約と実施規約で確認します。

「自社サイト一式」という指定では、同じドメインの管理画面や別の購入システムが含まれるか分かりません。機能一覧には、業務名だけでなく、対象URL、利用者の権限、担当する委託先も対応付けます。

外部決済やSaaS型ECでは、サイトを運営していても、提供元の基盤まで自由に検査できるとは限りません。許可の対象を明確にし、診断会社が必要とする接続条件や通知事項も併せて確認します。

本番環境と検証環境の違いを残す

検証環境を選ぶ場合は、本番との違いを診断会社へ伝え、確認できない項目を残す必要があります。ソフトウェア、権限、ネットワーク設定が異なると、本番だけに存在する問題は検査できないためです。

テスト用アカウントやデータの準備に加え、通知メールや外部連携の扱いも実施計画に含めます。本番で実施する場合は、監視担当への周知、バックアップ、異常時の停止と復旧の役割を決めておきます。

依頼から直すまでの流れ

Webサイトの脆弱性診断のやり方は、依頼時の合意から修正後の再診断までを、一続きの工程として組み立てます。

1. 目的と対象を整理して依頼します

公開前の確認、既存サイトの点検、改修後の確認など、自社で今回行う診断の目的を伝えます。対象のURL、機能一覧、構成、画面遷移、API仕様などを、必要な範囲で共有します。

1. 範囲・手法・期間を合意します

対象外、手動診断の項目、実施環境、検査の許可、情報の管理方法を双方で合意して書面に残します。開発や保守を担う修正担当者にも参加してもらい、報告書を受け取った後の作業を見通します。

1. 実施準備を整えて診断します

テスト用アカウント、接続設定、連絡網を確認し、合意した実施計画に沿って進めます。重大な問題を発見した場合の速報の方法や、異常時に中止・再開を判断する責任者も決めます。

1. 報告書を受け取り内容を確認します

危険度だけでなく、実際に検査した範囲、問題の影響、修正方法、未検査の項目を読みます。不明点は診断担当者へ確認し、開発・保守担当者が具体的な修正に着手できる内容に整理します。

1. 優先順位を付けて修正します

悪用の有無と自社への影響を踏まえ、担当者、実施予定、暫定対策、復旧方法を決めます。更新や改修を対象環境へ適用した後は、対策が反映されたことと業務機能の動作を確かめます。

1. 再診断して対応を記録します

指摘された問題が解消したかを確認し、未解決の項目には担当者と次の対応期限を設定します。修正内容、再診断の結果、残る制約を記録し、運用担当者が行う日常の更新・点検へ引き継ぎます。

診断期間は、通信を伴う検査の日数と、準備や報告書作成を含む日数を分けて確認します。修正担当者の作業予定も含めないと、再診断を受けられる契約期間内に修正が間に合わなくなります。

デジタル庁のガイドラインは、実施計画書、報告書、修正後の確認などを調達時の要件として整理しています。政府向けの資料ですが、民間企業が診断の依頼内容や必要な成果物を具体化する際にも参考になります。デジタル庁「政府情報システムにおける脆弱性診断導入ガイドライン」

報告書の見方と直す順番

脆弱性診断の報告書は、検査範囲と評価の根拠を確かめ、危険度、悪用の有無、自社への影響から修正順位を決めます。

脆弱性診断の報告書で確認する項目

診断の報告書には機密情報が含まれ得るため、社内外の共有先と保管場所を決めて管理します。社内向けの対応一覧には、詳細な検査内容を広く転載せず、担当業務に必要な情報を整理して載せます。

CVEとCVSSの意味

CVEは、個々の脆弱性を識別する共通の番号で、日本語の注意喚起と開発元の告知を照合する際に使います。危険度を表す点数ではないため、対象製品、影響する条件、公式情報と組み合わせて記録します。

CVSSは、脆弱性の技術的な深刻度を共通の方法で評価する仕組みで、対応順位を考える材料になります。IPAが説明するCVSS v3では、技術的な深刻度とスコアを次の表のように区分しています。

この点数だけでは、現在悪用されているか、自社の顧客情報へどれほど影響するかまでは決まりません。点数とともに、評価バージョン、評価組織、評価条件を表す文字列、確認日を残します。IPA「共通脆弱性評価システムCVSS v3概説」

JVNでは2025年4月21日からCVSS v4の評価を開始し、v3と併記しています。異なる方式の点数をそのまま比較せず、報告書や注意喚起に記された評価方式を先に確かめます。JVN「CVSS v4による評価採用のお知らせ」

危険度と悪用の有無から対応を決める

次の表は、公的情報の考え方を自社の判断へ当てはめた整理例で、一律の法定期限を示すものではありません。

悪用の情報は、国内の注意喚起に加え、米国CISAのKEVカタログでも確認できます。掲載がないことは安全の証明ではなく、米国機関向けの期限を日本の民間企業の法定期限とは扱いません。CISA「KEVカタログ」

IPAのEC向けガイドラインは、危険度「高」は迅速に、「中」は3か月程度を目途に対策するとしています。この危険度は実害に至る攻撃難易度などを考慮した分類で、CVSSの区分と機械的には対応しません。この目安を、悪用が確認された問題への対応を、次の定例作業まで待つ理由にしないことが大切です。

費用の考え方

脆弱性診断の費用は、診断の範囲・手法・再診断の有無で変わるため、見積もりの条件をそろえて比べます。

一般的なWebサイトの単発診断で、条件を統一した公的な費用相場は、今回参照した公的資料の公開情報では確認できません。一方、IPAは自社構築ECサイト向け資料で、脆弱性診断の費用感を「最低年額100万円以上」と示しています。

これは2023年公開のガイドラインにある年間の費用目安で、すべてのサイトに共通する単発診断の最低料金ではありません。現在の見積額や税込・税抜を保証する数字でもないため、対象と実施内容を示して個別に確認します。IPA「ECサイト構築・運用セキュリティガイドライン」本文40ページ

診断費を確保するときは、更新や改修に使う予算と、担当者の作業時間も併せて見込みます。診断のみの見積もりと修正込みの見積もりは、総額だけでは比べられないため、契約範囲を確認します。

修正後の再診断で確認すること

再診断では、指摘された問題に対する修正が有効かを確かめ、業務機能の動作確認と併せて完了を判断します。

契約前には、どの指摘を再検査するか、関連箇所も含むか、利用できる期間と回数を確認します。大きな仕様変更を行った場合の扱いや、期限を超えたときの追加費用も明確にしておきます。

デジタル庁は政府向けの要件で、修正した脆弱性について、納品後に再診断できるようにすることを求めています。再診断は報告書の納品後一定期間内に1回以上行えるようにする要件があり、受付期限は契約で確認します。これは政府向けの要件であり、民間の診断契約で一律に無料となる条件を示すものではありません。

1. 修正版の適用や改修が、診断の対象環境へ反映されたか、担当者が作業記録と照合して確認します。
2. あらかじめ合意した範囲の再診断を行い、報告書で指摘された問題が実際に解消したかを確認します。
3. カート、注文、決済連携、会員機能、通知など、修正後のECサイトの主要な業務動作も確認します。
4. 残る問題、暫定対策、担当者と次の確認日を記録し、その内容を確かめた責任者が完了を判断します。

更新によってアプリケーションが正常に動かなくなる場合があるため、事前検証と復旧方法の準備も必要です。また、修正で弱点が解消しても、修正前の侵入や情報流出まで否定できるわけではありません。

日常の点検

日常の点検では、利用製品の一覧を公的な脆弱性情報と照合し、更新担当者と確認記録を継続して管理します。

JVN・IPA・JPCERT/CCの情報の見方

JVNの対策欄では、弱点自体を解消する「解決策」と、影響を緩和する「回避策」を分けて読みます。回避策を入れた場合も、修正版への更新が必要かを確認し、未完了の作業として管理します。JVN「脆弱性レポートの読み方」

IPAの一覧にある「緊急」という表示と、CVSSの深刻度区分は、同じ意味ではありません。見出しや点数だけで判断せず、悪用状況、対象となる製品・バージョン、利用条件を読み合わせます。

更新の体制と点検頻度を決める

製品や拡張機能の一覧には、稼働環境、導入済みの版、更新担当、委託先、通知の受信先を記録します。情報を受け取る人、該当を調べる人、適用する人、停止を判断する人を決め、担当者不在時の連絡先も用意します。

JVNやJPCERT/CCのRSSなどを使い、情報収集を個人の記憶だけに頼らない運用にします。制作を委託している場合も、契約に更新と監視が含まれるか、実施状況をどう確認するかを明確にします。

IPAのEC向けガイドラインには、診断やバックアップについて、次の頻度が示されています。自社構築サイトを中心とする運用の目安で、すべてのサイトに一律の法定頻度を定めたものではありません。

脆弱性診断とバックアップは目的が異なるため、実施した作業と対象をそれぞれ分けて記録します。緊急の注意喚起が出た場合は、この定例頻度を待たずに自社への影響と対応を確認します。IPA「ECサイト構築・運用セキュリティガイドライン」本文34〜35ページ

製品ごとの確認方法は、関連記事「WordPressの脆弱性の確かめ方」「PHPのバージョンの確かめ方」でも扱っています。まず本番で使っている製品と版を把握し、公式の影響範囲に該当するかを照合することが出発点です。

当社では読み取りだけの点検を同じ順番で回す

当社では、外から情報が見える可能性を意識した点検手順を決め、AIのコーディングエージェントに同じ順で回させています。本番を壊さないために読み取りだけを対象とし、更新や設定変更は点検の実行に含めません。

1. 拡張機能をまとめて更新した後、サーバー設定を変えた後、四半期ごとに点検します。
2. 保存した前回の記録と比較し、追加・変更された点や確認できなかった点を整理します。
3. 普段の画面では見えにくい、名前が「.」で始まるフォルダーなども対象に含めます。
4. 対応が必要な事項は業務への影響を踏まえて直す順番を決め、修正作業の担当者へ引き継ぎます。
5. 直した後に同じ手順の点検をもう一度回し、修正対象として記録した状態が解消したかを確認します。

これは当社の点検手順であり、専門家による脆弱性診断と同じ検査範囲を保証するものではありません。読み取りだけの確認でも、外部への通信や負荷の条件を決め、許可した対象から範囲を広げない運用にします。

AIで点検するときに任せてよい範囲

AIには情報整理や合意済みの読み取り点検を補助させ、本番に影響する操作、検査の許可、公開の判断は人が担います。

総務省・経済産業省のAI事業者ガイドラインは、出力の精度とリスクを理解した利用を求めています。AIが出した判定をそのまま採用せず、公式情報の原文と、本番環境の事実を照合する運用が必要です。

特に、検査してよい対象を増やす判断や、本番のデータ・設定を書き換える操作は、責任者が事前に確認します。公開する情報の範囲や時期も、AIの提案だけで決めず、関係者と影響を確かめて判断します。

AIへ渡す情報は先に選別し、顧客情報、認証情報、秘密鍵、未公開の脆弱性情報などを不用意に入力しないようにします。利用サービスの保存・利用条件と自社のルールを確認し、点検に必要な権限だけを与える運用にします。

デジタル庁の生成AIガイドラインも、誤った出力や情報流出のリスクを扱っています。政府向けのルールを民間企業の義務と同一視せず、権限管理や人による確認の参考にできます。デジタル庁「生成AIの調達・利活用に係るガイドライン」第2.0版

よくある質問（FAQ）

脆弱性診断の判断に迷ったら、費用や頻度の条件と、検査の許可、問題が見つかった後の対応を分けて確認します。

自分で無料で診断できますか

IPAのチェックリストなどを使い、更新状況や運用体制を無料で点検することはできます。iLogScannerによるログの確認も可能ですが、無料の自己点検だけでサイト全体の安全を証明することはできません。

脆弱性診断はどのくらいの頻度で行いますか

自社サイトの構成と変更内容に応じて、定期診断と改修時の診断を組み合わせて決めます。IPAの自社構築EC向け資料では、基盤は四半期に1回、Webアプリは新機能追加・改修などの際の実施を示しています。

ツールによる診断だけで足りますか

業務仕様や権限の違いに関する問題は、自動診断だけでは検出が難しい場合があります。ツールが確認する対象と項目を明確にし、手動で補強する必要がある機能を診断会社と整理します。

脆弱性診断で本番が止まることはありますか

診断の通信により、サービス停止、データへの影響、通知の大量送信などが起こる可能性があります。実施環境と時間帯、通信量、監視担当への通知、異常時の中止・連絡方法を事前に合意します。

脆弱性が見つかったら公表が必要ですか

脆弱性の発見と、実際の侵害や情報漏えいは別に確認し、公開の必要性や時期を個別に判断します。報告書の詳細を先に公開せず、責任者と保守担当者が事実と影響を整理し、個人情報が漏れた、またはそのおそれがある場合の報告は、関連記事「個人情報が漏れたときの報告」で扱っています。