脆弱性診断はリリース前にいつ行う？修正と再確認の余白から逆算する

リリース前の脆弱性診断は、完成直前に予定を入れると修正や再確認の余白が残らないことがあります。実施日だけを決めても、対象を確定する時点、変更を避ける期間、報告を受ける時点が決まっていなければ、発注条件が揃いません。

結論から言うと、リリース前の診断は、実施日ではなく対象確定・修正・再確認の余白から逆算します。所要日数を一般化せず、自社のリリース計画、対象の安定度、関係者の確認体制に合わせて節目を置くことが重要です。

発注前に、対象確定、実施期間、修正と再確認、リリース判断の関係を一枚の予定表にします。変更が起きる場合の連絡方法と、誰が対象を承認するかを決めれば、診断結果をリリース判断へつなげやすくなります。

本記事で分かること

• リリース前に逆算する節目
• 対象確定と変更凍結の考え方
• 修正・再確認の条件
• 開発・運用・診断会社の役割分担

結論：修正と再確認の余白を先に確保する（早見表）

リリース前の診断は、実施日だけを決めず、対象確定、実施、修正、再確認、リリース判断の順番で予定を置きます。各節目で誰が判断し、変更があった場合にどの表を更新するかを明確にします。

逆算する四つの節目

診断日だけを決めず、前後の準備と対応を予定に入れます。対象の確認、実施条件の合意、報告後の修正、再確認の判断を分けると、どこで予定が変わったかを追いやすくなります。

対象確定

対象確定では、公開する画面、認証後の機能、API、外部連携、対象外にする範囲を整理します。対象が変わる予定がある場合は、どの版を確認するか、変更があれば誰へ連絡するかを記録します。対象表は、発注時の見積条件と報告書の対象を照合するための基準になります。

セキュリティ診断の発注ガイドを参照し、目的、対象、期限、担当をそろえます。対象を確定する前に実施日を固定すると、後から追加・除外が発生した際に条件差を説明しにくくなります。対象外にした理由と見直す条件も残します。

実施期間

実施期間には、対象となる環境、確認可能な時間帯、テスト用情報、通常時の連絡先をそろえます。いつでも実施できる前提にせず、通常利用や保守予定、連携先の制約を関係者で確認します。予定外の影響が疑われる場合に、誰が判断するかも決めます。

実施中に変更が予定されている場合は、変更を避ける期間や、変更が必要になった場合の連絡方法を条件表に記載します。対象の版が変わると、報告書がどの時点の確認かを判断しにくくなるためです。実施条件を先に合意すれば、診断会社からの質問にも同じ前提で答えられます。

修正と再確認

報告を受けた後は、どの機能・連携・設定を誰が修正するかを対応表にします。修正担当と完了を確認する担当を分け、変更予定がリリースにどう関係するかを整理します。修正内容を一律に次のリリースへ入れるのではなく、対象と影響を確認して判断します。

再確認では、どの指摘に関係する範囲を確認するか、どの版を対象にするか、結果をどのように受け取るかを決めます。Webアプリ診断の対象範囲も参照し、公開画面だけでなく、認証後や連携先への影響を確認します。再確認の対象を発注時の条件に含めると、修正後の調整を進めやすくなります。

変更が起きる場合の扱い

対象変更は発注条件と報告対象の両方へ反映します。変更が起きた事実、影響する対象、判断者、見直す予定を分けて記録し、元の条件を見失わないようにします。

変更凍結前の確認

変更凍結前には、対象となる画面、機能、API、連携先に予定された変更があるかを確認します。変更予定をすべて止めることが難しい場合も、どの変更を共有するか、誰が診断範囲への影響を判断するかを決めます。対象表に変更予定と担当を記載します。

変更を避ける期間は、実施条件の一つです。期間の長さを一般論で決めるのではなく、自社のリリース計画と対象の安定度を踏まえて関係者で合意します。予定が変わった場合は、見積条件、実施時点、報告書の対象に影響するかを確認します。

変更後の再評価

実施中や報告後に変更があった場合は、当初の対象との違いを確認します。変更した機能、関係する利用者、連携先、対象外だった範囲を整理し、追加の確認が必要かを判断します。変更を見つけた担当だけで結論を出さず、資産管理者と発注担当へ共有します。

再評価では、診断を行うかどうかだけでなく、対象表、報告書、再確認条件のどこを更新するかを決めます。変更の理由と判断の根拠を記録し、次のリリース計画でも参照できるようにします。対象変更とスケジュール変更を別の欄に残すと、影響を追いやすくなります。

リリース判断者への共有

リリース判断者には、診断の対象、確認時点、修正の状況、再確認の対象、未確認の事項を整理して共有します。技術的な説明だけを渡すのではなく、どの業務機能・利用者・連携に関係するかを対応付けます。判断に必要な資料と、参考情報を分けます。

共有の場では、誰が最終判断をするか、追加確認が必要な場合にどの予定を見直すかを決めます。結論が出ていない項目は、完了のように扱わず確認先と期限を残します。リリース判断と診断の実施担当を分けることで、役割と責任を明確にできます。

関係者の役割を決める

開発、運用、診断会社の連絡窓口を一つに決めます。対象の承認者、修正の担当者、緊急時の連絡先を事前に整理し、実施中に判断が止まらない体制を作ります。

対象の承認者

対象の承認者は、資産の所有・管理の関係と、診断に含める範囲を確認します。画面、機能、API、外部連携などに複数の管理者がいる場合は、対象表の行ごとに承認を確認します。自社が利用しているだけの領域を、承諾なしに対象へ入れません。

承認の確認では、対象外にした範囲も残します。後から追加の確認が必要になった場合に、なぜ当初の対象外だったかを説明できるようにするためです。対象を確定した日と、変更時に見直す担当を記録します。

修正の担当者

修正の担当者は、報告書で確認した対象と、自社の変更管理の単位を対応付けます。開発、運用、外部連携の担当が分かれる場合は、作業の窓口と完了を確認する担当を決めます。修正予定がリリースの判断に影響する場合は、判断者へ共有します。

修正内容を次の作業へ移す際は、対象、版、関連する機能、確認する範囲を記録します。脆弱性診断の費用構造を参照し、対象・成果物・再確認などの条件を比較表にも反映します。修正の完了と再確認の完了を同じ扱いにしないことが重要です。

緊急連絡先

緊急連絡先は、実施中に判断が必要になった場合の相談先です。通常の質問を受ける担当と、事業上・運用上の判断をする担当を分け、連絡できる方法を条件表に記載します。連絡先が不在の場合の引継ぎ先も確認します。

連絡体制は、実施日が近づいてから決めるのではなく、対象と実施条件を確定するときに整えます。予定外の状況が起きたときは、事前に合意した窓口で対象と進め方を確認します。連絡の経過は、実施条件に影響する事実として記録します。

まとめ

リリース前の脆弱性診断は、実施日ではなく、対象確定から修正・再確認までの余白を基に計画します。変更が起きた場合に対象表と条件表を更新し、対象の承認者、修正担当、連絡窓口を明確にすると、結果をリリース判断へつなげやすくなります。

リリース前の発注準備は、セキュリティ診断の発注ガイドと、進め方の記事一覧から確認できます。