脆弱性が本当に修正されたかを再テストで検証する方法

• 対象読者: 検出事項を修正済みにしたあと、それを証明する必要があるセキュリティエンジニア、IT マネージャー、CISO
• 適用範囲: app.aliengate.io — Actions & Intel → FixTrail / Issue Tracker、および Infrastructure Security → Vulnerability Scanner
• 所要時間: 設定に約 10 分。再テスト自体の所要時間は元のスキャンと同じです
• 前提記事: 記事 02 — スキャン完了後：結果を確認して修正を始める方法

この記事について デモ用ワークスペースで、意図的に脆弱に作られたアプリケーション 0-day.jp に対して行った 1 回の再テストサイクルを記録したものです。スクリーンショットは AlienGate の表示言語を英語に設定して撮影しています（記事 02 は日本語表示で撮影しており、日英対訳表を掲載しています）。表示言語はアプリ上部バーの言語切り替えで変更できます。クイックリファレンスの表は記事末尾にあります。

再テストが必要な理由

Issue Tracker で検出事項を Fixed（修正済み） にする操作は「主張」を記録します。担当者が修復チェックリストを完了し、修正が反映されたと判断したという記録です。この主張は誤っていることがあります。デプロイがひとつの環境を取りこぼした、WAF のルールが脆弱性のクラスではなくサンプルペイロードにしか一致しない、後のマージでパッチが差し戻された、といった場合です。

このため AlienGate は 2 つの状態を区別します。

証拠となるのは 2 つ目の状態だけです。この記事では、検出事項を 1 つ目の状態から 2 つ目の状態へ移す手順と、誤った検証を生む 3 つの設定ミスを避ける方法を説明します。

ステップ 1 — FixTrail でバックログを確認する

Actions & Intel → FixTrail（app.aliengate.io/dashboard/fixtrail）を開きます。

FixTrail は修復タイムラインです。各脆弱性が検出されてから Issue Tracker と修復手順を経て、修正を確認する再スキャンに至るまでの経路を、Web サイト・サーバーごとに表示します。「まだ何を証明しなければならないか」に答えるページです。

上部には 6 つのカウンターが並びます。

Avg. time to fix は「修正済みにした時点」ではなく「確認された時点」までを測ります。最初の再テストが完了するまでは空のままです。

ヘッダーの操作:

• 30 / 90 / 180 / 365 days で期間を設定します（既定は 90）。
• All states で状態を絞り込みます。再テスト対象の一覧を作るには Fixed · awaiting re-test を選びます。
• Refresh でスキャン完了後にデータを再読み込みします。
• Run re-test でスキャン設定画面を直接開きます。

カウンターの下のアタックサーフェスマップには資産ごとにカードが 1 枚あり、バーで解消済みの割合を示します。

0-day.jp                                    Top open: Critical
46 findings · last scan Sep 29, 2026
▓▓▓▓▓░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░
✓ 0 verified (0%)        8 awaiting re-test · 38 open

last scan の日付を確認してください。修正を含むデプロイより古ければ、その資産はまだ再テストされていません。

マップ下の凡例がすべての状態を定義しています。

Reopened はリグレッションを示す唯一の状態です。記事の最後で扱います。

ステップ 2 — イベント履歴を読み、エンジンと対象を控える

Remediation timeline までスクロールします。検出事項は新しい修正から順に、資産ごとにまとめて表示されます。グループ見出しには資産と Last verified re-scan の日付が表示されます（再テストで確認された項目がなければダッシュ）。

各行は 5 段階のパイプラインです。

Critical  OS Command Injection   web_app_scan                    ● Fixed · awaiting re-test

✓ Detected      ✓ Tracked       ✓ Fix steps 5/5   ✓ Marked fixed    ○ Verified by re-scan
  Sep 28, 2026    Sep 29, 2026     Sep 29, 2026      Sep 29, 2026

5 つ目のチップが空であれば、再テスト待ちです。行の右端のシェブロンをクリックすると履歴全体が展開されます。

● Detected by scan                                             Sep 28, 2026 15:58
● Added to the Issue Tracker                                   Sep 29, 2026 20:39
● Acknowledged                                                 Sep 29, 2026 20:39
● Work started                                                 Sep 29, 2026 20:40
● Remediation step completed — Verify OS command injection is prevented   20:46
● Remediation step completed — Reduce application process privileges      20:46
● Remediation step completed — Apply strict input validation and escaping 20:46
● Remediation step completed — Replace direct calls with safe APIs        20:46
● Marked as Fixed                                              Sep 29, 2026 20:46
● Remediation step completed — Locate OS command execution points         20:46

  ⚠ Marked fixed, but no re-scan has confirmed it yet. Run the same scan type on
    this asset again — when the finding is no longer reported, it becomes
    Fixed · Verified automatically.

この注記は検証の 3 つのルールを示しています。

1. Verified を手動で設定することはできません。 ボタンはなく、再スキャンが状態を変えます。
2. 同じ資産に同じスキャン種別を実行する必要があります。 別のエンジンや別のホストへの実行では何も検証されません。
3. 検証とは「結果」ではなく「不在」です。 検出されなくなったことで確認済みになります。元のスキャンより弱い再テストは検出数が減り、検出されなかったものはすべて確認済みの修正として記録されます。

このビューの 2 つの項目が再テストの設定を決めます。両方を控えてください。

タイムスタンプも確認してください。例では 5 つの修復手順と Marked as Fixed がすべて同じ 1 分以内に記録されています。これは、作業と並行してではなく、ボードを片付けるためにチェックリストを完了させたことを示す典型的なパターンです。いずれにせよ再テストが決着をつけます。実際に修正されていない検出事項は再び検出されます。

ステップ 3 — 有効な再テストの条件を定める

再テストが有効なのは、脆弱性を発見したスキャンの条件を再現した場合だけです。元の実行に対して 5 つの設定を確認します。

元より弱い設定は検出数を減らし、検出されなかったものはすべて確認済みの修正として記録されます。元の設定を再現できない場合は、再テストの前に設定を修正してください。

元のセッションの範囲（網羅性）まで一致させる必要はありません。web_app_scan 由来の検出事項は、web_app_scan のみの再テスト（約 30 分）で検証できます。Full Web Application Audit（約 90 分）でも検証でき、バックログが複数エンジンにまたがる場合はこちらが適切です。

例での再テスト計画: 0-day.jp · Web Application Scan · 認証あり（ログインフォーム） · Deep · 同一ドメイン内リダイレクト。

ステップ 4 — スキャンを設定する: 1 エンジン、1 対象

Scanner Console は、FixTrail ヘッダーの Run re-test か、Infrastructure Security → Vulnerability Scanner → Scan History → Scan Vulnerability から開きます。後者は元の実行を通るため、設定の確認に便利です。

スキャン種別は 3 つあります。

Custom を選択します。検出事項を報告したエンジンだけを実行できる唯一の選択肢です。

Custom ではエンジンがグループ別に表示され、Web・ネットワーク系が初期選択されています。

Web Application Scan 以外のチェックをすべて外します。見積もりは約 90 分から約 30 分に下がります。

Scan Targets では 0-day.jp だけを選択します。タブ行（All (4) / Domains (4) / IPs (0)）とフッターのカウンター（1 of 4 selected）で確認できます。

これで対象とエンジンが元の実行と一致しました。

ステップ 5 — 認証を設定し、確認する

元のスキャンは認証付きだったため、Authenticated scan を有効にします。3 つの方式は記事 04 で説明しています。このアプリケーションではログインフォームです。

実行前に Check authentication をクリックします。対象に対して実際にサインインし、成功するとコンソールのフッターに Authenticated のピルが表示されます。これなしで実行しないでください。ログインの失敗や期限切れがあると、スキャナーは実行時間をログインページで費やし、その先にある検出事項をすべて修正済みとして記録してしまいます。

コンソールには次の注意が表示されます: 「専用のテストアカウントを使用してください。認証情報はこのスキャンのために一度だけスキャンエンジンに渡され、キュー待機中は暗号化された状態でのみ保存され、二度と表示されません。」 再テストを含むすべてのスキャンは毎回ゼロから設定します。元のスキャンと同じ権限レベルの、専用スキャナーアカウントを使用してください。

ステップ 6 — スキャンの深さを一致させる

Scan options を開きます。Web Application Scan を選択していると 4 つの設定が表示されます。

フッターに設定の要約が表示されます。

1 Targets Selected    1 Scan Types Active    Avg: ~20 min / asset    ● Authenticated
                                              Est. Total Time: ~30 min    [Launch Scan]

実行前に 1 Targets Selected · 1 Scan Types Active · Authenticated、Deep、同一ドメイン内リダイレクトを確認します。これでステップ 3 の 5 項目すべてが一致しました。

ステップ 7 — 実行し、認証付きで動いていることを確認する

Launch Scan をクリックします。コンソールがライブビューに切り替わります。

左パネルには実行中の設定が表示されます。

Active Scan                                              in progress
Running selected scan engines

Web Application Scan   [Authenticated · Login form]            1%
Deep · Same-domain only redirects · 100 rps

右パネルにはスキャンエンジンからのテレメトリがストリーミングされます。

aliengate — security terminal                    ● LIVE        Scanning 1%

[i] 1 job(s) active.
[Web Application Scan] 0-day.jp — Trying to authenticate.
11:28:43  [+]  Engines online — 1 job(s) dispatched.
11:28:43  [i]  Streaming live telemetry from the scan engine.
11:28:43  [i]  0-day.jp · authenticated scan (Login form, a***)
11:28:43  [*]  0-day.jp · Fingerprinting web server and frameworks · 0%
11:28:44  [*]  0-day.jp · Crawling site map and discovering links · 0%
11:28:46  [*]  0-day.jp · Resolving target and following redirects · 0%
11:28:48  [*]  0-day.jp · Mapping cookies and session handling · 1%
11:28:50  [*]  0-day.jp · Enumerating forms, inputs and query parameters · 1%

authenticated scan (Login form, a***) の行を確認してください。再テストが認証付きで実行されていることを示します。この行がなければ Stop Scan で停止し、認証を修正します。未認証の実行は、検査していない検出事項を「確認済み」にしてしまいます。

Pause View はログの表示を止めて読みやすくするもので、スキャンは継続します。コンソールは閉じて構いません。スキャンはサーバー側で続行し、完了すると Scan History に表示されます。

ステップ 8 — Scan History で結果を読む

スキャンが完了したら Infrastructure Security → Vulnerability Scanner → Scan History を開きます。

2 つの Web Application Scan の行を比較します。同じ対象、同じエンジン、元の実行では 37 件、再テストでは Clean、所要時間は同程度（37 分 40 秒と 43 分 48 秒）です。所要時間が同程度であることが、再テストが同等の作業を行ったことの証拠になります。両方の行を修復チケットに添付してください。

結果を受け入れる前の 2 つの確認:

元より大幅に短い所要時間は、再テストの作業量が少なかったことを意味し、アプリケーションが安全になったことを意味しません。 元が 40 分かかった Web Application Scan が 2 分で終わった場合、アプリケーションをクロールしていません。ログインの失敗、ログイン URL の変更、WAF によるブロックのいずれかです。

Clean は深刻度を持つ検出事項がないことを意味し、出力がないことではありません。 この再テストは Info レベルの行を 4 件追加しました（Interesting files found、Unsafe security header: Content-Security-Policy、Cross-Site Request Forgery、Administration consoles found）が、それでも Clean と表示されます。バッジだけでなく、必ず Global Vulnerabilities の一覧で確認してください。

ステップ 9 — Global Vulnerabilities と Issue Tracker で状態変化を確認する

Vulnerability Scanner → Global Vulnerabilities を開きます。ページ上部のバナーが結果を示します。

27 vulnerabilities are fixed. A re-scan of the same target marks each one Verified when it is no longer detected. — View fixed

例では再テスト待ちが 8 件、確認済みになったのは 27 件です。修正済みにした 8 件に加え、同じ修正で解消されたものの誰も追跡していなかった 19 件が含まれます。ステータスを手動で設定した人はいません。検出されなくなったことをプラットフォームが記録しました。

結果を読むためのフィルター:

確認済みになった Critical の検出事項を 1 つ開きます（バナーから、または Actions & Intel → Issue Tracker から）。

Remote File Inclusion                        A1 - Injection   Web Application Scan
10.0  CVSS v3.1                                                      Critical

STATUS                                       ASSIGNED TO
[Fixed]  [✓ VERIFIED BY RETEST]              Ishan Nim · COMPANY
Verified by retest on Oct 1, 2026

CATEGORY            A1 - Injection           SOURCE       Web Application Scan
TARGET              0-day.jp                 DISCOVERED   Sep 29, 2026

VERIFIED BY RETEST バッジには日付、CVSS スコア、検出元エンジンが含まれ、イシューがボードを離れた後も記録に残ります。ステップ 8 の 2 つの Scan History の行と合わせて、修正の監査証拠として完結します。

ステップ 10 — FixTrail で指標を確認する

Actions & Intel → FixTrail に戻り、Refresh をクリックします。

資産カードにも変化が反映されます。

0-day.jp                                        Top open: High      ← 以前: Top open: Critical
48 findings · last scan Oct 1, 2026
▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓░░░░░░░
✓ 27 verified (56%)        1 awaiting re-test · 20 open

修復報告で押さえるべき 3 点:

• Avg. time to fix に値が入りました（3 日）。検出から確認済み修正までを測る指標で、手動のステータスではなくスキャナーの証拠に基づく唯一の修復指標です。
• 検出事項が 46 件から 48 件に増加。 再テストが 3 日前にはなかった 2 件を報告しました。再テストは確認だけでなく発見も行います。差分は新規として扱います。
• Top open が Critical から High に下がりました。 資産の最上位リスクが変わりました。

Awaiting re-test は 0 ではなく 1 です。1 件は状態が変わりませんでした。最も多い理由は、この再テストで実行しなかったエンジン由来の検出事項であることです。トラブルシューティングを参照してください。

確認済みの検出事項を展開します。5 つ目のチップにチェックが入り、履歴の最後に緑のイベントが追加されています。

Critical  SQL Injection  web_app_scan           ● Fixed · verified   ⏱ Fixed in 3 d

✓ Detected    ✓ Tracked    ✓ Fix steps 5/5   ✓ Marked fixed   ✓ Verified by re-scan
  Sep 28        Sep 29        Sep 29            Sep 29            Oct 1, 2026

● Detected by scan                                        Sep 28, 2026 15:58
● Added to the Issue Tracker                              Sep 29, 2026 16:22
● Acknowledged                                            Sep 29, 2026 20:39
● Work started                                            Sep 29, 2026 20:40
● Remediation step completed — Identify Vulnerable SQL Queries           20:41
● Remediation step completed — Refactor Queries with Prepared Statements 20:43
● Remediation step completed — Apply Input Validation                    20:43
● Remediation step completed — Review Database User Privileges           20:43
● Remediation step completed — Verify SQL Injection Remediation          20:43
● Marked as Fixed                                         Sep 29, 2026 20:43
● Re-scan confirmed the fix                               Oct 1, 2026 12:12   🟢

黄色の注記は Re-scan confirmed the fix イベントと Fixed in 3 d バッジに置き換わります。検出から確認済み修正までの、日付付きで完結した検出事項ごとの修復記録です。

ステップ 11 — ダッシュボードを確認する

Overview → Dashboard を開きます。再テスト前のダッシュボードは、未対応 46 件、上位に Critical 3 件、Recently Fixed セクションなしでした。

再テスト後:

Critical はゼロになり、残る上位の検出事項はトランスポート層と設定の問題です。この 3 件はいずれも ssl_tls_analysis または wordpress_scan 由来で、今回の再テストでは実行していないエンジンです。再確認されたのではなく、対象外だったという点に注意してください。

再テストの範囲

再テストが検証するのは、再実行したエンジン由来で、再実行した対象上の検出事項だけです。それ以外は変化しません。

0-day.jp に対する web_app_scan 1 回で 27 件が確認済みになり、20 件が未対応のまま残りました。残ったのは実行していない SSL/TLS Analysis と WordPress Scan 由来の検出事項です。残った Awaiting re-test 1 件もほぼ確実にこの中にあります。バックログの形に合わせて実行内容を選びます。

再テストのたびに FixTrail の Awaiting re-test カウンターを確認してください。ゼロでなければ、まだ再実行していないエンジン由来の検出事項が残っています。

リグレッション: Reopened 状態

確認済みの検出事項が後のスキャンで再び報告された場合、Open には戻らず Reopened になります。

Reopened は修正が持続しなかったことを示します。差し戻し、設定のドリフト、デプロイが届かなかった環境、プール内の 1 ホストにだけ適用された修正などが原因です。同じ深刻度の新規検出事項より優先してトリアージしてください。リグレッションはアプリケーションだけでなく、デリバリーパイプラインに関する情報です。

同じ理由で、Avg. time to fix は一度きりの確認件数より有用な指標です。平均が低く Reopened がなければ修復プロセスが機能しています。Reopened が繰り返し発生する場合は、デプロイに問題があります。

推奨する再テストの頻度

FixTrail の期間は報告期間に合わせて設定します。四半期報告なら 90 days にすると、カウンターと報告書の数値が一致します。

トラブルシューティング

リファレンス

状態の用語集

エンジン → 検証できる対象

Website Recon（約 20 分）と Subdomain Finder（約 15 分）は偵察エンジンです。脆弱性ではなく観測情報を生成するため、何も検証しません。

再テストのチェックリスト

Launch Scan をクリックする前に、6 項目すべてを確認します。

• 対象が検出事項の資産と、サブドメインまで含めて完全に一致している
• エンジンが検出事項のエンジンタグと一致し、それ以外は選択されていない
• 元が認証付きなら Authenticated scan が有効で、Check authentication が成功している
• Scan type（Light / Deep / Custom）が元の実行と一致している
• Follow redirects が元の実行と一致している
• フッターに 1 Targets Selected · 1 Scan Types Active（または意図した範囲）と Authenticated ピルが表示されている

完了後に、4 項目すべてを確認します。

• 所要時間が元の実行と同程度である
• Scan History が Completed で、Failed や Stopped ではない
• Global Vulnerabilities のバナーに確認済みになった件数が表示されている
• FixTrail の Awaiting re-test がその件数分減っている

次に読む記事

• 記事 01 — 脆弱性診断の実行方法 — 再テストのたびに再現する Scanner Console の設定全体
• 記事 02 — スキャン完了後：結果を確認して修正を始める方法 — 証拠に基づくトリアージ、Issue Tracker、この記事が検証する修復チェックリスト
• Actions & Intel → Report Center — 再テスト後に英語または日本語の PDF をダウンロードし、確認済みの日付をレポートに反映する
• Settings — アラート設定。Reopened をダッシュボードを開かずに受け取る

この記事のスクリーンショットは、表示言語を英語に設定した AlienGate で、デモ用の意図的に脆弱なアプリケーション 0-day.jp に対して撮影したものです。ワークスペース名、スコア、検出事項、時刻、氏名はすべてデモ環境のものです。