スキャン完了後：結果を確認して修正を始める方法

• 対象読者: スキャンを完了し、その結果を脆弱性の修正につなげたいセキュリティエンジニア、IT マネージャー、CISO
• 適用範囲: app.aliengate.io — インフラセキュリティ → Websites & IPs / 脆弱性スキャナー、およびアクションとインテル → Issue Tracker / Report Center
• 所要時間: 初回スキャンのトリアージに約 20 分。修正にかかる時間は検出内容によって異なります
• 前の記事: 記事 01 — 脆弱性診断の実施方法

スクリーンショットについて　この記事のスクリーンショットは、AlienGate の画面を日本語に設定して撮影したものです。画面上のラベルは日本語を先に、英語をかっこ内に記載しています（例: すべての脆弱性（All Vulnerabilities））。英語表示でも同じ手順で操作できます。表示言語は上部バーの言語切り替えで変更できます。ラベルの対訳表は記事の末尾にあります。

この記事で得られるもの

このガイドを最後まで進めると、次の状態になります。

• 件数を数えるだけでなく、内容を実際に読み込んだスキャン結果
• タイトルではなく証跡（スキャナーが実際に取得したリクエストとレスポンス）に基づいて判断された、個々の検出事項
• 重要な検出事項が Issue Tracker に移され、担当者が割り当てられ、修正チェックリストが紐づいた状態
• 少なくとも 1 件の脆弱性が 修正済み まで進み、再スキャンで修正が確認された状態
• 経営層や監査人に提出できる、日英 2 言語の PDF レポート
• 開始時より低くなった Attack Surface Score

この記事で扱う一連の流れ

スキャン完了
   ↓
資産の全体像を確認         Websites & IPs → Attack Surface Score、資産ごとのドロワー
   ↓
新しい資産をトリアージ     パッシブ偵察で見つかった資産を承認または無視
   ↓
検出事項を読み込む         脆弱性スキャナー → すべての脆弱性 → 検出事項ごとの証跡
   ↓
Issue Tracker へ移す       アクションとインテル → Issue Tracker
   ↓
割り当て · 修正 · 検証     AI 生成の修復チェックリストを進め、各ステップを確認
   ↓
修正済みにする
   ↓
再スキャンで確認           元のスキャンと同じ設定で実行
   ↓
レポートをダウンロード     Report Center → 英語または日本語の PDF

この流れで重要なのは、最後の 2 つのステップです。修正済みにしても再スキャンしていない検出事項は、「直ったと思っている」だけの状態にすぎません。AlienGate は、その裏付けを取るように作られています。Issue Tracker では、すべての修復ステップを確認するまで、検出事項を 修正済み に変更できません。

ステップ 1 — スキャンの完了を確認し、対象を選ぶ

インフラセキュリティ → 脆弱性スキャナー（app.aliengate.io/dashboard/vulnerability-assessment）を開きます。

スキャン履歴（Scan History）タブには、すべてのスキャンがステータスとともに表示されます。完了した実行は 完了（Complete）と表示されます。完了を確認したら すべての脆弱性（All Vulnerabilities）タブに切り替え、左上のスキャンセレクターから対象の実行を選択します。

選択した実行は、解除可能なチップ（Scan: SSL/TLS Analysis · 0-day.jp · Sep 28, 12:23）として表示されるため、どの結果セットを見ているかがいつでもわかります。チップを解除すると、すべてのスキャンをまたいだ検出事項が表示されます。

表を読む前に、スキャンセレクターを確認してください。　このページで最も多い誤読は、特定のエンジンの出力だけをトリアージして「この資産は問題なし」と結論づけてしまうことです。SSL/TLS Analysis の実行結果は、本来ほとんどが Info になります。Critical の検出事項があるのは、同じホストに対する Web Application Scan の側です。

ステップ 2 — 検出事項一覧ではなく、資産から始める

個々の検出事項を開く前に、問題の全体像をつかみます。インフラセキュリティ → Websites & IPs（app.aliengate.io/dashboard/manage-targets）を開きます。

その下の資産テーブルには、資産ごとに次の情報が表示されます。ドメイン名と最終スキャン日時、資産の種類、検出されたテクノロジー、重大度別の内訳バッジ（3 Critical · 5 High · 7 Medium · 16 Low）、SSL/DNS の状態、そして 詳細を表示（View details）アクションです。

この重大度バッジが、最初のトリアージ判断の材料になります。1 つの資産の重大度分布を 1 行で把握できるのは、ここだけです。

ステップ 3 — 資産ドロワーを開く

資産の 詳細を表示（View details）をクリックします。右側にドロワーが開き、概要（Overview）、脆弱性（Vulnerabilities）、テクノロジー（Technology）の 3 つのタブが表示されます。

概要 — 資産の素性

ネットワーク層の検出事項に時間を割く前に、ホスティング（Hosting）を確認してください。資産の名前解決先が CDN の場合、一部の結果はオリジンではなくエッジの状態を示しています。

脆弱性 — 資産ごとの対応残件

検出事項は重大度別にグループ化され、上部に重大度ごとのカウンターと合計（46 vulnerabilities / 脆弱性 46 件）が表示されます。すべて展開（Expand all）とすべて折りたたむ（Collapse all）を使うと、素早く確認できます。

各行には、タイトルより先に確認したい 4 種類のメタデータがあります。

その日の作業順は、確度で決めてください。　Confirmed の Critical は、スキャナーが実際に動作するリクエストで再現したものです。推定にとどまる検出事項は、チケットを起票する前に人が検証する必要があります。

検出事項を展開すると、その根拠が表示されます。

証跡（Evidence）ブロックには、スキャナーがやり取りした生の Request と Response が表示され、その後ろに次の表が続きます。

チケットに添付するのは、この情報です。「リモートファイルインクルージョン、Critical」とだけ伝えられた開発者は反論しますが、リクエスト、レスポンス、脆弱なパラメーターを渡された開発者は修正してくれます。

テクノロジー — 資産を構成しているもの

ソフトウェア/バージョン（Software / Version）とカテゴリ（Category）のインベントリです。例として、jQuery 1.7.2（JavaScript ライブラリ）、Nginx 1.14.2（Web サーバー、リバースプロキシ）、PHP 8.2（プログラミング言語）があります。

このタブは、検出事項と並べて確認してください。nginx 1.14.2 に対する CVE ベースの検出事項は、ここでそのバージョンを確認できた時点で裏付けが取れます。また、この一覧にサポート終了（EOL）のライブラリがあれば、それはスキャナーが検出していない可能性のある問題です。

ステップ 4 — 偵察で見つかった資産をトリアージする

パッシブ偵察で、検証済みインベントリにないホストが見つかった場合、Websites & IPs の上部にバナーが表示されます。「未承認または未管理のサブドメインが 3 件検出されました」。資産を確認して承認（Review and approve assets）をクリックします。

インフラ資産のトリアージ（Infrastructure Asset Triage）モーダルには、検出された各ホストが最終検出日とともに一覧表示され、All / Subdomains / IPs のタブに分かれています。ホストごとに、次のいずれかを選択します。

これは次回のスキャンの後ではなく、前に行ってください。未管理のサブドメインは、環境への典型的な侵入経路です。ここで承認することで、そのサブドメインがパッシブな観測にとどまらず、アクティブな脆弱性モニタリングの対象になります。

資産を承認すると、検出された攻撃対象領域は意図的に増えます。サブドメイン数が 0 から 3 に増え、資産テーブルも大きくなります。これはツールが正しく機能している証拠です。自分のものだと認めていないホストは、守れません。

ステップ 5 — 検出事項の全件リストを読み込む

脆弱性スキャナー → すべての脆弱性（All Vulnerabilities）に戻ると、資産横断のトリアージ表が表示されます。

表の上部には 3 つのコントロールがあります。ステータスフィルター（既定は Active / 対応中）、重大度フィルター（すべてのリスク（All risks））、並べ替え（Sort）です。行のチェックボックスで一括選択もできます。

実践的なトリアージの順序

1. 確実（Confirmed）な Critical を最優先にします。資産をまたいで確認してください。これらは実証済みで、悪用可能です。
2. 次に、エンジンを問わず CVSS 9.0 以上を対象にします。
3. 残りは重大度別ではなく、担当チーム別にまとめます。検出事項ごとにチケットを切るより、チームごとに 1 回話をするほうが効率的です。
4. CVE が付いているものはパッチ管理へ、付いていないものはコードまたは設定の変更として扱います。
5. リスクを受容する検出事項は、無視（Ignore）に理由を添えて移します。そうすることで、次回スキャンとの差分が意味を持ち続けます。

ステップ 6 — 1 件の検出事項をしっかり読む

検出事項の 詳細を表示（View details）をクリックします。ドロワーには、チケットを書くため、あるいはその検出事項が誤りだと主張するために必要な情報がすべて揃っています。

ドロワーには、上から順に次の内容が含まれます。

• 重大度チップと経過時間 — Critical · 1 day ago
• タイトルとエンドポイント — 例: 0-day.jp:443 のリモートファイルインクルージョン
• 説明 — その脆弱性クラスの概要
• 証跡（Evidence） — 取得したリクエストとレスポンス
• ステップ 3 で説明した脆弱なパラメーターの表
• 再現手順 — スキャナーが実行した手順
• リスクの説明 — 攻撃者が何を得られるかを、ビジネス上の影響として記述
• フッターのアクション: Issue Tracker に移動（Move to Issue Tracker）、無視（Ignore）、削除

Replay Attack — 強力ですが、本当に危険です

攻撃をリプレイ（Replay attack）は、スキャナーが取得したリクエストを、お使いのブラウザーから本番のターゲットへ再送します。AlienGate は実行前に確認を求めます。表示される警告は、全文を読む価値があります。

スキャナーが取得したリクエストを、ブラウザーから本番のターゲットへ直接再送します。ペイロードが悪用可能な場合、実際に実行されます。テストの権限を持つサイトに対してのみ実行してください。

これは定型文ではありません。リモートファイルインクルージョンや OS コマンドインジェクションの検出事項でリクエストをリプレイすると、そのペイロードが本番環境で再び実行されます。

Copy as curl を優先してください。　開発者は再現可能なワンライナーを入手でき、本番環境にも影響しません。

ステップ 7 — 検出事項を Issue Tracker に移す

検出事項が事実であり、修正する方針が決まったら、Issue Tracker に移動（Move to Issue Tracker）をクリックします。トーストに 「インシデントが正常に作成されました」（Incident created successfully）と表示され、ボタンは Issue Tracker に登録済み（In Issue Tracker）に変わるため、重複して作成されることはありません。

もう一方の結果には 無視（Ignore）を使います。誤検知やリスクを受容する場合が該当します。どちらの判断も記録され、検出事項が曖昧な状態のまま残ることはありません。

対応を確約した検出事項ごとに、この操作を繰り返します。Issue Tracker に移すのは慎重に行ってください。Issue Tracker はチームが責任を負うリストであり、46 枚のカードが並んだボードは、誰も手を付けないボードになります。

ステップ 8 — Issue Tracker のボードを運用する

アクションとインテル → Issue Tracker（app.aliengate.io/dashboard/issue-tracker）を開きます。

ボードは 5 列のカンバンで、この列がそのまま修正ワークフローになっています。

カードには、検出事項のタイトル、説明の抜粋、種別チップ（脆弱性（Vulnerability））、優先度チップ（緊急（Urgent）、高（High））、OWASP カテゴリ（A1 - Injection、A7 - Cross-Site Scripting (XSS)）、担当者のアバターまたは 未割り当て（Unassigned）が表示されます。

ボードの上部には、検索ボックス、優先度（Priority）フィルター、担当者（Assignee）フィルター、そして検出事項を一括で取り込む タスクを取り込む（Import tasks）があります。

カードは、列間にドラッグして移動します。すべての移動は、日時と操作者名とともに検出事項の履歴に記録されます。

ステップ 9 — 課題を開いて設定する

カードをクリックすると、課題のドロワーが開きます。

ヘッダーには、OWASP カテゴリと検出元エンジンがチップで表示され、その下にスコア（CVSS 10.0 · Critical）がスコアリングのバージョン（CVSS v3.1）付きで表示されます。その下の項目は次のとおりです。

続いて、3 つの記述セクションがあります。脆弱性の説明（Vulnerability description）、リスクの説明（Risk description）、推奨対応（Recommended remediation）です。

ほかの作業より先に、課題の担当者を割り当ててください。すべてのカードに担当者名が付いていることが、このボードの価値です。

ステップ 10 — 修復チェックリストを進める

ここが、AlienGate で修正を「宣言」ではなく「検証可能なもの」にする部分です。

各課題には、修復ステップ（Remediation Steps）が用意されています。これは検出事項ごとのチェックリストで、AI と表示され、完了カウンター（0 of 5 complete）と進捗バーが付いています。その上に書かれた次の文が、このルールです。

対象システム上で各ステップを実施し、ここで確認してください。すべてのステップが確認されるまで、この検出事項を 修正済み に設定することはできません。

このスクリーンショットのリモートファイルインクルージョンでは、次の 5 つのステップが生成されました。

1. 脆弱な入力パラメーターとファイルインクルード関数を特定する — インクルード関数（include、require、include_once、require_once、または使用言語の同等の関数）に到達する、ユーザーが制御可能な入力（クエリパラメーター、POST データ）を、コードベース全体で洗い出します。
2. ファイルインクルードに厳格なホワイトリストを実装する — 脆弱な各コードパスで、許可するファイルまたはファイル識別子のホワイトリストを保持するようアプリケーションを変更し、インクルードの前にユーザー入力をそれと照合します。一致しないものはすべて拒否します。
3. ユーザー入力がファイルパスに入らないようコードをリファクタリングする — 可能な限り、ユーザーが送信した入力をインクルード関数に渡すこと自体をやめ、代わりに内部のハードコードされたファイル名やリソースに対応付けます。
4. サーバー設定でリモート URL のインクルードを無効にする — PHP アプリケーションでは、php.ini の allow_url_include を Off に設定します。これにより PHP がリモート URL からファイルをインクルードできなくなり、RFI のリスクを直接低減できます。
5. 修正が有効であることをテストする — 以前に特定した RFI に対し、既知の悪意あるリモート URL と想定外のファイルパスの両方で攻撃を試み、アプリケーションが両方を拒否し、外部ファイルのインクルードも実行も行わないことを確認します。

各ステップは、実際に完了した時点でチェックします。チェックしたステップには 確認済み（Confirmed）と表示されます。最後のステップをチェックすると、チェックリストに 「すべてのステップが確認されました — ステータスを修正済みに変更できます」 と表示されます。

先回りしてチェックしないでください。　カウンターは、修正が実際にどこまで進んだかを示す唯一の正直な記録です。誰も手を付けていない検出事項のチェックリストを 5/5 にしてしまうと、統制が単なる書類作業に変わってしまいます。

ステップ 11 — エスカレーション、議論、監査証跡の保持

チェックリストの下には、さらに 3 つのブロックがあります。

サポートチケット（Support ticket） — この検出事項について、CyberCrew サポートデスクにサービスリクエストを送ります。チケットの優先度（Ticket priority）を設定し（Emergency 以下）、チケットを作成（Create ticket）をクリックします。修正の支援が必要なときに使います。作業の割り当ての代わりにはなりません。

コメント（Comments） — 検出事項に紐づくスレッド形式の議論です。チームメンバーへの @ メンションやファイル添付が使えます。修正方針はここで詰めます。チャットではなく検出事項上に残しておけば、次にそのカードを開いた人が、その判断に至った理由を確認できます。

履歴（History） — すべてのステータス変更を、操作者と日時とともに記録する改ざん不能の監査証跡です。

Ishan Nim  Sep 29, 2026 · 03:22   Status changed to Open
Ishan Nim  Sep 29, 2026 · 03:23   Status changed to Verified
Ishan Nim  Sep 29, 2026 · 03:23   Status changed to In Progress
Ishan Nim  Sep 29, 2026 · 03:24   Status changed to Fixed

監査人が求めるのはこの証跡であり、ボードを正しく運用すれば自動的に記録されます。カードを最後の列へ直接ドラッグせず、確認済み → 対応中 → 修正済みの順に移動させる理由もここにあります。タイムスタンプが、そのまま修正にかかった時間の指標になるからです。

ステップ 12 — 修正済みにし、再スキャンで裏付ける

すべての修復ステップを確認したら、課題を 修正済み（Fixed）に設定します。カードをその列にドラッグしても構いません。

そのうえで、再スキャンします。　修正済みにするのはラベルを変えることにすぎませんが、再スキャンは事実を変えます。

1. インフラセキュリティ → 脆弱性スキャナーに戻り、その検出事項を見つけた実行と同じスキャン設定（同じエンジン、同じ認証、同じ深度）で実行します。設定が異なる場合は再テストになりません。（設定については、記事 01 のステップ 3〜8 を参照してください。）
2. 完了したら、新しいスキャンで絞り込んだすべての脆弱性を開き、検出事項を名前で検索します。
3. 表示されなければ、修正は有効です。まだ表示される場合は、課題を対応中に戻してください。修復ステップは確認済みでも、変更が反映されていません。

ステップ 13 — レポートをダウンロードする

アクションとインテル → Report Center（app.aliengate.io/dashboard/report-center）を開きます。

レポートはスキャンごとに生成され、Report（名称とファイルサイズ）、スキャン種別（Scan type）、期間（Period）、生成日時（Generated）、ステータス（Status）、操作（Actions）とともに一覧表示されます。タブ（All reports / Security scans / OSINT / Weekly summary）で絞り込み、ターゲットやスキャン種別で検索し、新しい順（Newest）で並べ替えられます。

目的の行の ダウンロード（Download）をクリックし、言語を選択します。

内容は同じレポートです。日本のクライアントと海外の親会社の双方に提出する場合は、両方をダウンロードしてください。同じスキャンデータから生成されているため、数値は一致します。

レポートの内容

この規模の Web Application Scan のレポートは約 74 ページで、単なるデータの羅列ではなく、正式な診断成果物として構成されています。

• 免責事項（Disclaimer） — 機密性、診断が特定時点のものであること、法的助言ではないことの明記
• 文書管理（Document control） — レポート名、対象、スキャン種別、診断期間、発行日、レポートバージョン、手法（自動スキャン（Automated scan））、総合リスク評価、分類（社外秘（Confidential））
• 改訂履歴（Revision history） — バージョン、日付、変更内容、作成者
• 検出事項ごとのセクション。それぞれ (E) リスク分析（Risk analysis）と (F) 関連情報（Related information）までの項目に分かれています

レポートを送付する前に確認しておきたいのが、この最後のセクションです。各検出事項は CWE（例: CWE-98）と、OWASP Top 10 の 3 つの版（2017、2021、2025）に対応付けられ、該当する OWASP Testing Guide の章へのリンクも付いています。コンプライアンスの枠組みで特定の OWASP 版を参照している場合でも、対応付けはすでに用意されています。

また、スキャナーが推定ではなく悪用可能性を実証した検出事項には、到達可能性のコールアウトが付きます。「影響は緊急であり、到達可能性は想定ではなく実際に確認されています。」 要約を書く際は、これらを先頭に置いてください。

ステップ 14 — スコアの推移を確認する

再スキャンの後、Websites & IPs に戻ります。

次の 2 点が変化しているはずです。

• Attack Surface Score が下がっています。このスクリーンショットでは 9.4 から 9.1 です。その下の指針も更新され、「3 件の重大な脆弱性を修正すると 14% 下がります」 から 「2 件の重大な脆弱性を修正すると 11% 下がります」 に変わっています。
• ステップ 4 で承認した資産が、親ドメインの下に 公開サービス（Public service）の行として表示され、それぞれ独自の脆弱性件数と SSL の状態が示されます。新しい資産は、最初のアクティブスキャンが完了するまで 0 · Safe（0 安全）と表示されます。これは「クリーン」ではなく「まだ評価されていない」という意味です。

このスコアは、経営層に示す数値として最適です。指し示せる理由があって動く数値だからです。環境の実態を下回るところまで無理に下げようとしないでください。また、資産の監視をやめてスコアを下げることも避けてください。

クイックリファレンス

10 秒でわかる手順

脆弱性スキャナー → すべての脆弱性 → スキャンを選択
  → 確実（Confirmed）+ Critical で並べ替え
  → 検出事項を開く → 証跡を読む → curl としてコピー（リプレイはしない）
  → Issue Tracker に移動
Issue Tracker
  → 担当者を割り当てる
  → 修復ステップを進め、1 つずつ確認する
  → 確認済み → 対応中 → 修正済み
脆弱性スキャナー → 同じ設定で再実行 → 検出事項が消えたことを確認
Report Center → ダウンロード → 英語 / 日本語の PDF

課題のステータスワークフロー

検出事項のメタデータの読み方

よくある間違い

各機能の場所

画面ラベル対訳表（日本語 ↔ English）

次のステップ

• 記事 01 — 脆弱性診断の実施方法 — 再テストのたびに再実行するスキャン設定について説明しています
• 脆弱性スキャナー → 偵察（Recon） — 作業の過程で見つかった攻撃対象領域。次回のターゲット候補になります
• Websites & IPs → ターゲットを追加（Add target） — トリアージで承認した資産を、完全に管理下に置きます
• 設定（Settings） — アラート設定。ダッシュボードを開かなくても、新しい Critical の検出事項が通知されるようにします
• サポート（Support） — 左サイドバーの下部から、または任意の課題からサービスリクエストを送信できます

この記事のスクリーンショットは、AlienGate の画面を日本語に設定し、デモ用に意図的に脆弱に作られたアプリケーション 0-day.jp に対して撮影したものです。表示されているワークスペース名、スコア、検出事項、時間、名前は、すべてそのデモ環境の値です。