初めてのWebアプリケーション脆弱性診断にむけて
はじめに
診断は「事前準備」でよりスムーズになります 。
Webアプリの脆弱性診断は、事前に「分かる範囲で」整理しておくだけで進み方が大きく変わります。
- 見積、日程が早く固まり、計画が立てやすくなる
- 「どこまで見るか／何を避けるか」が事前に揃うので、手戻りやスケジュール遅延のリスクが減る
- 対象が明確になるほど、重要箇所を優先して深く確認でき、診断結果の納得感が上がる
- 予算や期限に合わせて「対象を絞る／簡易版を組み合わせる」などの相談がしやすくなる
また、TIS（以下、弊社）では原則として、開発環境・ステージング環境での診断をおすすめしています。
理由は次の3点となります。
- 影響を最小限にできる（万が一のリスクを下げられる）
- 制限が減る（本番だと「触れない機能」が発生しやすい）
- 修正→再確認が回しやすい（改善のサイクルが回りやすい）
もちろん事情により本番環境での実施を希望される場合もあるかと思います。
その場合も、安全に進められる形を一緒に検討できますのでご安心ください。
事前に整理すると安心な10個のポイント
ここでは、診断前に「だいたい把握できていると助かること」を10個にまとめました。
全部が完璧に決まっていなくても大丈夫です。
さらに詳しい内容は、診断実施前にご記入いただく 「ヒアリングシート」 で一緒に整理していきますので、最初の時点ではわかる範囲で問題ありません。
01 システム名（社内での呼び方でOK）
まずは「何のシステムの診断か」が分かればOKです。
報告書に載せる正式名称は、後から整えられます。
02 対象URL（分かる範囲でざっくり）
PC向け、スマホ向け、管理画面など、思いつく範囲でURLを書き出してみてください。
「まだURLが固まっていない」「画面ごとのURLが分からない」でも大丈夫です。
※対象が整理できるほど、確認漏れが減り、重要箇所を優先して深く見られます。
03 どの環境で診断できそうか（開発/ステージングなど）
弊社では、原則として開発環境・ステージング環境を推奨しています。
この時点では「どの環境なら触れそうか」だけ分かれば十分です。
※制約が少ない環境ほど、確認できる範囲が広がり、結果の精度も上がりやすくなります。
04 本番との差分（ざっくりでOK）
ステージングと本番で、違いがある部分だけメモ程度でOKです。
（例：認証方式が違う／決済は本番のみ／メール送信先が違う…など）
※差分が分かると、結果の解釈（本番リスクの見立て）が明確になります。
05 ログインが必要か（必要なら“権限の種類”だけ）
ログインがある場合は「一般ユーザ」「管理者」など、権限の種類だけでOKです。
ID/パスワードやアカウント数は、ヒアリングシートで整理します。
※権限が違うアカウントがあると、認可（権限チェック）の抜けなどを見つけやすくなります。
06 テストしやすいデータがあるか（触っていい範囲のイメージ）
「テストデータがある」「ダミーで操作できる」くらいの粒度で大丈夫です。
もし「実データは触れないでほしい」などがあれば、その一言があるだけでも助かります。
07 触ってはいけない操作があるか（ざっくり列挙）
影響が出やすい操作がある場合は、ざっくりで良いので書いておくと安心です。
（例：退会・削除・請求・メール一斉送信・外部連携の実行…など）
※「触ってはいけない操作」を先に共有すると、安全を確保しつつ、必要な確認に集中できます。
08 外部サービス連携があるか（種類だけでOK）
決済、メール、ID連携、他システム連携など、「ある/ない＋種類」くらいでOKです。
細かい接続先や条件は、ヒアリングシートで確認します。
09 希望の実施時期（だいたいでOK）
「〇月上旬」「来月中」などの粒度で大丈夫です。
触れない日時（リリース、バッチ、棚卸し作業など）がある場合は、それもメモ程度でOKです。
ご予算や期限が決まっている場合は、その前提も共有いただけると、対象の絞り込みや簡易版のご提案がしやすくなります。
新サービスのリリース日が決まっている場合は、脆弱性改修の期間も考慮して実施時期を決めると安心です。
10 当日の連絡窓口（1名いると安心）
当日は確認事項が出ることがあるので、窓口になれる方が1名いると進みやすいです。
連絡手段や緊急時の連絡先なども、ヒアリングシートで整理します。
対象（Web画面／API）の考え方
ヒアリングシートでは、対象を整理するシートが 「Web画面」 と 「API」 に分かれています。
Web画面
Web画面の一覧は、URL単位で確定していなくても大丈夫です。
「ログイン」「会員登録」「パスワード再設定」など、機能名（リクエスト名）で書いてください。
もちろんURL単位（リクエスト単位）で確定している場合にはそちらを記載いただければ対象が明確になるので、診断も進めやすくなります。
もし遷移が複雑な場合、備考に「どこからどう辿るか」「条件（会員種別など）」を記載いただくだけでも、追加確認が減り、診断が止まりにくくなるので、全体の進行も安定します。
API
APIの一覧は、できれば「実際に送って成功する情報」があると診断が進めやすくなります。
（※「XXX」など仮の値が多いと、追加確認が多くなる場合があります。）
ただし、最初から完璧に揃っていなくても大丈夫です。
「APIはまだ整理できていない」「仕様書がある」でも進め方はありますので、その旨を伝えてください。
詳細は「ヒアリングシート」で一緒に整理します。
ヒアリングシートについて
弊社では、診断範囲・進め方・当日の安全対策を明確にするため、診断実施前に 「ヒアリングシート」 のご記入をお願いしています。
この記事で挙げたポイントは、ヒアリングシートをスムーズに埋めるための導入となります。
分かる範囲で整理しておくと、ヒアリングシート記入も、その後の見積・日程調整も進めやすくなります。
ヒアリングシートで確認する主な内容（例）
- システム情報（対象URL、環境、概要、制限事項 など）
- 診断情報（希望期間、実施形態、触れない日時 など）
- 対象一覧（Web画面／API）
- 連絡先（当日の窓口、緊急時連絡 など）
- 決済機能がある場合の情報（該当時のみ）
ヒアリングシート記入のメリット
- 診断対象（スコープ）が明確になる
- 制限事項や連絡体制が整理でき、当日の手戻りが減る
- 影響が出やすい機能（決済/メール等）も含めて配慮点が整理でき、安心して進めやすい
スムーズに進めるための注意点（よくある詰まりどころ）
- IP制限やVPNの準備が当日に間に合わない
- ログイン後の権限が足りず、診断対象を網羅できない
- 開発環境と本番の差分が大きく、結果の解釈が難しくなる
どれも、事前に分かる範囲で共有いただければ、よりスムーズに進めやすくなります。
まとめ
最初の脆弱性診断は、どうしても「何を用意すればいいの？」となりがちですが、今回挙げたポイントをざっくり埋められれば、診断の進め方は十分組み立てられます。
そのうえで、詳細はヒアリングシートで一緒に整理させていただきます。
なお、脆弱性診断は「全部やる／やらない」だけではありません。
ヒアリングシートで対象機能やリスクを整理したうえで、重要度の高い処理に絞る、あるいはまず簡易版で現状把握してから段階的に広げるといった進め方も可能です。
ご予算・ご希望時期に合わせて、無理のないプランをご案内します。
お気軽にお問い合わせください。