脆弱性検出ゼロなら、安全と言えるのか——SAST・DAST・ファジング・診断計画・手動テストを午後の問われ方で読む｜支援士解説2の6

この記事の重要度：Aランク（午後の大問・設問でよく問われる重要な分野）

この記事で分かること：

• SAST・DAST・SCA・ファジング・脆弱性診断・ペネトレーションテストが、それぞれ何を確かめ、何を確かめられないか

• 自動診断ツールの落とし穴、診断の計画と安全な実施、手動でしか確かめにくい認可の不備

• 解答欄に書く「原因」と「対策」の型

シラバスとの対応：小項目2-6「セキュリティテスト」。認証・認可・セッションの設計は支援士解説2の4、プログラムの脆弱性は支援士解説2の5、見つかった脆弱性への対応は支援士解説3の6、開発工程への組込み（CI/CD）は支援士解説2の8で扱います。

午後の問題では、脆弱性診断やテストの場面がよく題材になります。自動の診断ツールがどの画面までたどり着けたか、アカウントのロックや回数制限で検査が止まらないか、インターネットからの攻撃を想定した診断をどこから行うか、ツールで見つけにくい脆弱性は何か。「指摘ゼロ」の報告書を受け取っても、何を確かめ、何が未確認なのかを読めなければ、安全とは言えません。

この記事では、架空の自治体のオンライン申請システムを例に、検査方法の種類、自動診断の落とし穴、診断の計画と安全な実施、手動テスト、結果の読み方、修正後の確認を順に整理します。

1. 守る条件を、検査と判断までつなぐ

テストの出発点は、セキュリティ機能が「あるか」だけではありません。架空の申請システムなら、住民は自分の申請を表示でき、別の住民の申請は表示できない。職員は担当案件を審査でき、権限のない案件を承認できない。こうした許可と拒否の条件を、主体・操作・対象・時点で書き分けます。正常な操作を確かめる機能テストに、拒否すべき操作、記録、失敗時の状態を加えるのがセキュリティの観点です。OWASP「Application Security Verification Standard」

確認先は画面だけではありません。権限のない承認を試して画面にエラーが出ても、DB上の状態が変わっていたら不合格です。ログや通知に個人情報や認証情報が漏れていないか、操作が一部だけ確定していないかも見ます。支援士解説2の4で決めた認証・認可・ログの要件と、支援士解説2の5で扱った入力値の処理を、観察できる期待結果へ変えます。

計画時には、対象の機能、URL・API、ソフトウェアの版、利用権限、実施環境、対象外を明記します。実施後は「試した」「指摘がなかった」を分けて記録し、指摘は原因・影響を確認して修正します。最後に再テストと回帰テストを行い、残る課題と判断者を決めます。運用中に変化したら、同じ問いを必要な範囲で繰り返します。NIST「SP 800-115 Technical Guide to Information Security Testing and Assessment」

報告では、手動検査と自動検査のどちらで確かめたか、未検出なのか未実施なのか、診断済みの範囲と関連箇所はどこかを、事実として分けて書きます。指摘には成立条件を添え、修正の担当と期限を明確にします。

記述の型

• テストの期待結果：「要求は拒否され、データの状態は変わらず、必要な記録が残る」

• 計画で決めること：「対象の機能・API・版、使う権限、実施する環境、対象外とその理由」

2. 検査方法は四つの軸で整理する

「SASTはホワイトボックス、DASTはブラックボックス」と一対一で覚えると、実際の計画を読み違えます。少なくとも四つの軸を分けます。

• 対象を実行するか：静的検査はコードやバイナリ等を動かさずに解析し、動的検査は対象を動かして応答や状態を観察する。

• 内部情報をどれだけ使うか：ブラックボックスは内部情報を原則利用せず、ホワイトボックスは設計やコードを使い、グレーボックスは一部の仕様や権限を使う。

• どう進めるか：自動検査は規則に従って繰り返し、手動テストは担当者が意味と条件を判断する。手動でも通信確認などの道具は利用できる。

• どこから、誰の権限で試すか：外部・内部ネットワーク、未認証・住民・職員・管理者を別々に指定する。

例えば「職員アカウントとAPI仕様を渡し、動作中の申請APIをDASTツールで検査する」なら、動的・一部の内部情報あり・自動・職員権限という組合せです。DASTだから必ず内部情報ゼロ、とはなりません。テストの名称より、実際に与えた情報と到達した範囲を読むことが重要です。OWASP「Web Security Testing Guide」

記述の型

• 検査方法の説明：「対象を動かすか、内部の情報をどれだけ使うか、自動か手動か、どこから誰の権限で試すかを分けて書く」

テストの工程ごとに、確かめるセキュリティ

セキュリティのテストは、完成の直前にまとめて行うものではありません。工程ごとに確かめることがあります。

• 単体テスト：入力の検証、出力のエスケープ、権限の判定など、部品ごとの安全な処理

• 結合テスト：部品をつないだときに、認証の結果や権限の情報が正しく引き継がれるか。外部の連携先との間で、想定外の値を受け取ったときの扱い

• システムテスト：利用者の種類ごとの許可と拒否、ログの記録、エラー時の表示、設定の不備

• 受入れテスト：発注者が、要件どおりに許可と拒否が働くかを、業務の手順に沿って確かめる

テストの環境とデータ

テストの環境が本番と違えば、結果をそのまま本番に当てはめられません。版、設定、外部連携の違いを記録し、何を確かめられて何が残るかを整理します。テストに本番の個人情報をそのまま使うと、テスト環境が漏えいの原因になります。必要な条件を満たすテスト用のデータを作るか、個人を特定できないように加工したデータを使います。テスト環境から本番の外部サービスへ通知やメールが送られないように、連携先も切り替えます。

3. SAST：コードの危険な流れを探す

SAST（Static Application Security Testing）は、アプリケーションを実行せず、ソースコードや解析可能な成果物から問題の候補を探します。例えば外部入力が検証や値の分離を経ずにSQLの組立てへ達する経路、危険な関数の使い方、秘密情報の埋込みを見つけます。対象言語、フレームワーク、ルールに対応しているかで、検出できる範囲は変わります。OWASP「Source Code Analysis Tools」

コード変更の段階から繰り返せるのが利点です。一方、実行時にどの機能が公開され、どの権限で利用されるかを、静的な情報だけで完全に判断することはできません。指摘された経路が実際には到達不能だったり、安全な共通部品をツールが理解できなかったりする場合もあります。反対に警告がなくても、案件の担当者だけが見られるという業務上の認可条件は満たされないかもしれません。

レビュー担当者は、検出した箇所の入力元、使用先、防御処理、実行条件を確認します。誤検知として抑制するなら理由を残し、コードが変わった際にその判断が今も通用するか見直します。SASTの結果は人が確認する候補であり、件数だけで品質を決めるものではありません。

秘密情報の埋込みを見つける

ソースコードや設定ファイルに、パスワード、APIキー、暗号鍵が書き込まれていないかも、静的な検査の対象です。リポジトリの履歴に一度でも登録された秘密は、後で削除しても履歴から取り出せることがあります。見つかった秘密は、削除するだけでなく、無効にして作り直します（アプリの中の秘密の扱いは支援士解説2の4）。

ツールとコードレビューを組み合わせる

SASTのツールは、決まった規則に合う危険な書き方を速く見つけます。一方、業務のルールに照らした認可の判定や、設計の誤りは、人がコードを読むレビューで確かめます。開発を委託している場合は、委託先が行ったレビューの記録（誰が、何を、どの観点で確認し、どう直したか）を提出させ、作業が妥当だったかを確かめられるようにします。

開発の流れの中で、いつ動かすか

SASTのツールは、開発者の端末で動かすことも、ソースコードを登録したときに自動で検査やビルドを行う仕組み（CI/CDパイプライン）に組み込むこともできます。

• 開発者の端末で動かす：コードを書いた直後に、ツールで検知できる問題を早く見つけられる

• CI/CDパイプラインに組み込む：パイプラインの管理機能で、登録のたびに漏れなく自動で実行できる

両方を組み合わせれば、早く見つけることと、検査を漏らさないことを両立できます。ツールによっては、コンパイルエラーのないソースコードしか正しく検査できないなど、実行の条件があります。

午後での問われ方

• 令和7年度春期 午後問1：システム開発企業のサプライチェーンリスク対策が題材で、ソースコードを検査するツールFを、開発者の端末とCI/CDパイプラインの両方で使う構成が示されました。それぞれの利点として、解答例は「ツールFで検知できるエラーをより早く発見することができる」と「CI/CDパイプラインの管理機能を使って自動実行することができる」です。

• 平成30年度春期 午後II問2：Webサイトのセキュリティガイドラインと診断の内製化が題材でした。外部に開発を委託する契約で、検収の条件に追加すべき内容として、解答例は「作業の妥当性を確認できる詳細なレビュー記録を委託先が提出していること」です。ガイドラインは、各工程の最後にレビューを行い、作業の妥当性を確認することを求めていました（実装の工程ではコードレビューに当たります）。

採点講評で指摘されたつまずき

• 令和7年度春期 午後問1では、この設問の正答率が低く、SAST、DAST、IASTといった開発プロセスで活用するセキュリティテストのツールについて、それぞれの特徴を理解してほしいとされています。

記述の型

• SASTの利点：「プログラムを動かさずに、開発の早い段階から繰り返し検査できる」

• SASTの限界：「実行時にその箇所へ到達できるかや、業務上の認可の条件までは判定できない」

4. DAST：到達した機能の振る舞いを調べる

DAST（Dynamic Application Security Testing）は、動作中のアプリへ要求を送り、応答や状態を見て問題を探します。Webアプリなら、入力を変えたときのエラー、意図しないデータの返却、スクリプトの実行などが対象になります。外からの振る舞いを確かめられますが、コード内部の全経路を必ず通るわけではありません。OWASP「Web Security Testing Guide」

まず、その検査が必要な機能に到達したかを確認します。トップページだけなら、ログイン後の申請・審査・承認機能は未確認です。職員アカウントを渡しても、途中でセッションが切れれば後続の要求はログイン画面に戻っているかもしれません。API、一括出力、特定の状態になった案件の画面は、通常の巡回だけでは届かない場合があります。対象の権限、必要なテストデータ、操作手順を準備し、到達できなかった理由も報告します。

受動的な観察は通常の通信から手がかりを探し、能動的な検査は要求を変えて弱点を探します。後者は実際に状態を変更したり、負荷をかけたりする可能性があります。ZAPの公式説明も、能動スキャンを対象への攻撃として扱い、対象への許可と実施範囲を求めています。ZAP「Active Scan」

WAFが検査要求を止めた場合、「WAFがこの要求を遮断した」ことは確認できます。しかし「背後のアプリに欠陥がない」とは言えません。WAFのログとアプリのログを突き合わせ、アプリへ届いた要求と届かなかった要求を分けます。アプリ本体を調べるために検証環境で経路を変える必要があっても、検査担当者の独断では行わず、計画で合意します。

ログイン後の画面とAPIを診断する

公開画面だけを診断しても、ログイン後の全機能は確かめられません。権限別に到達した画面と、画面以外のAPI、送った要求件数を報告で確かめます。ログインが必要な画面を診断するには、診断用のアカウントをツールに設定し、診断の途中でセッションが切れていないかを確かめます。セッションが切れると、以後の要求はログイン画面に戻り、本来の機能は検査されません。APIは画面からたどれないので、APIの定義（仕様書）を読み込ませるか、要求を手動で登録します。権限の異なる複数のアカウントで同じ要求を送り、応答の違いを見ると、認可の不備の手掛かりになります。

自動診断ツールの落とし穴

DASTのツールには、指定したURLからリンクやフォームの送信先を自動でたどり、診断の対象を登録する機能（自動探査）を持つものがあります。便利ですが、次の落とし穴があります。

• 登録されない画面がある：特定の値を入力しないと進めない画面、検索結果が1件以上ないと表示されない画面などは、自動探査ではたどり着けない。設計書で画面の一覧を確認し、漏れた画面は手動で登録する

• 入力と出力の画面が違う：入力した値が、次の画面ではなく二つ先の画面で出力される場合、入力した画面の応答だけを見ても、スクリプトが動くかを判定できない。出力される画面の応答も判定の対象に加える設定が要る

• 業務の制限で止まる：ツールは同じ画面に値を変えた要求を何度も送るので、「パスワードを連続5回間違えるとアカウントがロックされる」「1会員に1回しか申し込めない」といった画面では、途中でエラーになり、その先を検査できない。診断の前に、こうした画面遷移を洗い出し、方法を変える

午後での問われ方

• 令和5年度春期 午後II問1：企業グループのWebサイトの脆弱性診断を、DASTのツールで内製化する場面が題材でした。自動探査で漏れる画面を見つける方法として、解答例は「診断対象のWebサイトの設計書を確認するという方法」です。入力したスクリプトが二つ先の画面で出力される箇所について、ツールの設定は「アンケート入力1からアンケート入力2に遷移するURLの拡張機能に、アンケート確認のURLを登録する」です。診断がうまく進まない画面遷移として、「同じアカウントで連続5回パスワードを間違えるとアカウントがロックされるから」「キャンペーンは1会員に付き1回しか申込みできないから」が示されています。

採点講評で指摘されたつまずき

• 令和5年度春期 午後II問1では、ツールの設定を問う設問の正答率が低く、診断対象のURLそのものを答える誤りが多かったとされています。拡張機能を使うと、診断対象のURLの応答だけでなく、別のURLの応答も判定の対象になります。データを入力する画面と出力される画面のURLが異なることに着目します。

記述の型

• 自動探査で漏れる画面への対応：「設計書で画面の一覧を確認し、手動で診断対象に登録する」

• 自動診断が止まる理由：「連続した誤入力でアカウントがロックされる」「1回しか実行できない処理がある」

• DASTの限界：「ツールが到達できなかった画面は、検査されない」

5. 対象に合わせて、方法とツールを選ぶ

Webアプリの外にも確認先があります。プラットフォーム診断は、OS・ミドルウェア・ネットワーク機器などの版、パッチ、設定、公開ポートを対象にします。Webアプリケーション診断は、入力、認証、権限、セッションなどの動作を対象にします。コードにSQLインジェクションがあればOSのパッチ状況だけでは分からず、管理ポートが公開されていれば画面の診断だけでは分かりません。検査対象と方法を対応させます。総務省「自治体セキュリティポリシーガイドライン（令和8年3月版）」第3編6.6(1)の解説

SCA（Software Composition Analysis）は、アプリに含まれる依存部品とその版を把握し、既知の脆弱性情報と照合する方法です。部品表であるSBOMを管理していれば、新しい脆弱性が公開されたときに関係するシステムを探しやすくなります。ただし、部品が一覧に載っただけで、実際の利用状況や影響が判断できるわけではありません。OWASP「Dependency-Check」、OWASP「Developer Guide: Dependencies」

IAST（Interactive Application Security Testing）は、動作中のアプリ内部を計測し、実行した経路の情報を検査に使います。外部からの動的検査だけでは分からない内部の経路を手がかりにできますが、計測部品を組み込める環境か、テストで必要な経路を実行できるかを確認します。SCAとIASTはここでは補助的な関連知識で、2-6のシラバスが略称を列挙しているわけではありません。OWASP「DevSecOps Verification Standard：IAST」

SAST・DAST・IASTは、次のように使い分けます。

• SAST：コードを書いている段階から、危険な書き方を早く見つける。実行時の到達や業務の条件は分からない

• DAST：動いているアプリの振る舞いを外から確かめる。到達した範囲しか分からず、内部のどの箇所が原因かも分かりにくい

• IAST：テストを実行しながら内部を計測し、どの経路を通ったかと問題の箇所を結び付ける。計測の部品を組み込める環境が必要

ツールを選ぶときは、製品名よりも、対象の言語・構成、必要な権限でのログイン方法、APIへの到達、運用できる検査頻度、報告書に残る証拠を見ます。クラウド利用時は、事業者が管理する基盤と自団体が管理する設定・アプリの範囲を契約に沿って分け、診断が許される対象と方法も確認します。「クラウドだから検査不要」とも「契約しているから他者の領域まで検査してよい」とも考えません。

午後での問われ方

• 平成30年度春期 午後II問2：Webサイトのセキュリティガイドラインと診断の内製化が題材でした。脆弱性の管理のために把握しておく情報として、解答例は「Webサイトで使用しているOS、ミドルウェア及びWFの名称並びにそれぞれのバージョン情報」です。部品と版が分かっていれば、脆弱性が公表されたときに影響を調べられます（SBOMは支援士解説3の10）。

記述の型

• プラットフォーム診断の対象：「OS・ミドルウェア・ネットワーク機器の版、パッチ、設定、公開しているポート」

• SCAで分かること：「含まれる部品と版を、既知の脆弱性の情報と照合した結果。公表前の脆弱性は分からない」

6. ファジング：入力を変えて異常を探す

ファジングは、多様な入力を対象の処理に与え、クラッシュ、タイムアウト、異常な資源消費、不正な状態変化などを探す方法です。単に大量の要求で性能の限界を見る負荷試験とは、主な問いが違います。ファジングでは、どの入力が、どの処理で、どんな異常を起こしたかを保存できることが大切です。

元になる正常・異常の入力群を変異させる方式や、形式に沿って入力を生成する方式があります。内部のコード到達情報を使い、まだ通っていない経路へ向けて入力を変える方式もあるため、必ずブラックボックスとは限りません。LLVMのlibFuzzerは到達情報と入力群を使う実装例です。LLVM「libFuzzer」

異常が出たら再現用の入力を保存し、必要最小限に縮め、原因を調べます。正常に拒否したエラーと、予期しないクラッシュや状態破壊は分けます。クラッシュだけで特定の攻撃が成立すると断定しません。原因を修正した後は同じ入力で再確認し、回帰テストへ残します。ファイル変換や独自のデータ形式など、入力を処理する部品に対して有効な場合がありますが、業務上の認可条件は別に確かめます。

ファジングが向く対象

ファジングは、外部から受け取ったデータを解釈する処理に向いています。ファイルの変換、画像や文書の読込み、独自の通信手順の実装、IoT機器のファームウェアなどです。CやC++のように、メモリの範囲を言語が自動で確かめない言語で書かれた部分では、境界を越えた書込みなどの重大な不具合が見つかることがあります（メモリの安全性は支援士解説2の5）。どの入口に、どんな形式の入力を与えるかを決め、見つかった異常の原因分析までを計画に含めます。

記述の型

• ファジングの目的：「想定外の入力を大量に与えて、異常終了などの不具合が起きないかを調べる」

• 異常が見つかったら：「その入力を保存して再現し、原因を調べ、修正後に同じ入力で再確認する」

7. 脆弱性診断とペネトレーションテストの問いを分ける

脆弱性診断は、決めた範囲で弱点や設定不備を見つけ、修正につなぐ活動です。Webアプリ、プラットフォーム、コードなど、対象に応じて方法が変わります。ペネトレーションテストは、例えば「外部から住民の申請情報へ到達できるか」のような攻撃目標を置き、許可された範囲で経路を組み合わせ、到達可能性や防御・検知の働きを確かめます。実際の作業内容は契約とルールで定義し、名称だけで範囲を決めません。NIST「SP 800-115」

同じ欠陥が両方で見つかることもあります。しかし診断報告の「このAPIに認可不備がある」と、テストの「ある条件で情報へ到達できた」は、答えている問いが異なります。逆に攻撃目標に到達できなかったとしても、時間、許可された手法、持っていた権限、監視や防御の条件の下で到達しなかったという結果です。すべての脆弱性がない証明にはなりません。

計画時は、探索対象、禁止する操作、取得してよい証拠、途中で止める条件を決めます。目標を達成した後にさらに深く試すかも、あらかじめ合意した範囲で判断します。「侵入テスト」という名前を付ければ、通常の診断より強い検査を無制限に行えるわけではありません。

レッドチーム演習との違い

レッドチーム演習は、攻撃者の役を担うチームが、実際の攻撃に近い手順で侵入を試み、組織の検知と対応の力まで含めて確かめる演習です。脆弱性診断が弱点を広く洗い出し、ペネトレーションテストが決めた目標への到達を確かめるのに対し、レッドチーム演習は、攻撃に気付き、止められるかという防御側の働きにも重点を置きます。どの演習でも、許可された範囲と止める条件を、事前に合意します。

午後での問われ方

• 令和6年度秋期 午後問4：個人情報を扱うWebサイトの診断報告書が題材でした。出題趣旨は、脆弱性は一つ一つが軽微でも、複数を組み合わせて悪用されると重大な被害につながることがあり、診断ツールで検出される脆弱性以外にも、想定される攻撃に対して対策が不足していることも報告に含めると、セキュリティが大きく向上することがある、としています。

記述の型

• ペネトレーションテストの目的：「複数の脆弱性を組み合わせて、決めた目標に到達できるかを確かめる」

• 到達できなかった結果の読み方：「与えた時間・権限・手法の範囲で到達しなかったということで、脆弱性がない証明ではない」

8. 診断の安全な実施条件を先に決める

能動的な検査は、入力を送ることで申請を作成し、通知メールを送り、外部サービスへ接続する場合があります。検証環境でも外部のメール、決済、連携先につながっていれば影響が出ます。事前に管理主体から許可を得て、対象のホスト・URL・期間・権限・禁止手法・許容する負荷を定めます。提供事業者や他の利用者が管理する領域は、利用契約があるという理由だけで対象に加えません。ZAP「Active Scan」

実施前に、テスト用アカウントとデータ、外部連携の切替え、バックアップと復旧手順、監視担当、停止条件、連絡先を確認します。実施中はシステムの状態と検査の到達範囲を見て、想定外の影響が出たら停止・連絡します。必要な証拠は保存しますが、実データや認証情報を報告書へ過剰に載せません。実施後は一時的な設定とアカウントを戻し、テストデータを処理し、業務機能の正常性を確認します。

本番でしか再現できない構成を確かめる必要がある場合も、どの操作なら許されるかを個別に判断します。「本番では一切検査しない」と決め打ちすることも、「検証環境なら何をしてもよい」と考えることも、対象と影響の確認にはなりません。

本番環境で診断するとき

検証環境では確かめられない構成を、本番環境で診断することがあります。その場合は、テスト用のアカウントとデータを使い、外部へのメールや連携を止め、事前にバックアップを取ります。監視の担当者やWAF・IPSの運用者に、診断の日時と診断用の端末を知らせ、本物の攻撃と区別できるようにします。異常が起きたときに止める条件と連絡先、復旧方法も決めます。事業者が管理する領域は、許可された範囲内に限ります。

診断の計画：どこから、いつ、何を止めるか

診断の計画では、想定する脅威に合わせて、どこから検査するかを決めます。インターネットからの攻撃を想定する診断なら、インターネット側から本番のWebサーバへ届く経路で検査します。管理用のネットワークから検査しても、外からの攻撃の条件は再現できません。

既存のセキュリティ機器との関係も決めます。ネットワーク型のIPSは、診断の通信を攻撃として遮断することがあります。遮断されたままでは、背後のサーバを検査できません。一方で、遮断を止めれば、その間は本物の攻撃も通ります。診断用の端末のIPアドレスだけを例外として許可する、業務の少ない時間帯に実施する、サーバ側の侵入検知の設定を一時的に変える、といった調整を、期間と元に戻す手順まで含めて決めます。

午後での問われ方

• 令和2年度10月 午後I問3：ECサイトの脆弱性診断の計画が題材でした。プラットフォーム診断でネットワーク型IPSの設定を変える理由として、解答例は「N-IPSで遮断されていたPF診断の通信が通過するから」、対応は「ホワイトリストに診断PCのIPアドレスを登録する」です。業務への影響を避けるために「診断時間を0時〜8時の間にする」こと、本番のDBサーバでは「ホスト型IPSのホワイトリスト設定に、診断PCのIPアドレスを登録し、侵入検知設定を無効にする」ことも示されています。

採点講評で指摘されたつまずき

• 令和2年度10月 午後I問3では、診断用のPCをつなぐ場所を問う設問の正答率が低く、管理LANにある接続箇所を選ぶ誤りが多かったとされています。インターネットから本番Webサーバへの攻撃を想定した診断は、管理LANからでは適切に行えません。診断の計画では、どのような脅威を想定したものかを念頭に置くことが重要です。

記述の型

• 診断PCをつなぐ場所：「想定する攻撃と同じ経路で、対象へ届く場所につなぐ」

• IPSとの調整：「診断PCのIPアドレスだけを例外として許可し、期間と元に戻す手順を決める」

• 業務への影響：「業務の少ない時間帯に実施し、テスト用のアカウントとデータを使う」

• 本番での診断：「監視の担当者に日時と診断用の端末を知らせ、止める条件と復旧方法を決める」

9. 手動テストで、業務の意味を確かめる

自動検査は共通するパターンを繰り返すのに向いています。一方、業務のルールを知らなければ「他課の案件を開けた」「承認前の申請が確定した」が誤りかどうかは判断しにくいものです。業務担当者とともに、役割別の許可・拒否条件、遷移できる状態を決めます。OWASP「Web Security Testing Guide」

架空の申請システムなら、住民Aのアカウントで住民Bの申請番号を指定し、表示・変更・ダウンロードが拒否されるかを試します。一般職員で管理者向け承認APIを呼ぶ試験も必要です。画面のボタンが見えないだけでは足りません。さらに、確認画面を飛ばす、処理済み案件を再承認する、二つの操作を同時に行う、といった状態の制約も調べます。

テストの期待結果を「エラーが出る」とだけ書かず、要求は拒否される、申請の状態は変わらない、必要な記録は残ると具体化します。事前に用意する案件と担当関係、実施後に確かめるDB・ログの状態が決まれば、手動テストの結果も追跡できます。全部を人手で行う必要はありません。重要な業務の判断を人が定義し、再実行できる部分を自動化します。

権限と操作の組合せ表を作る

手動テストの漏れを防ぐには、利用者の種類（未ログイン、住民、担当職員、他課の職員、管理者）と、操作（閲覧、変更、承認、出力）と、対象（自分のもの、他人のもの、処理済みのもの）の組合せを表にし、許可と拒否の期待結果を書き込みます。表があれば、どの組合せを試したか、どれが未確認かを報告で示せます。

業務の流れの不備を試す

画面ごとの入力だけでなく、業務の流れの不備も、手動で確かめます。確認の画面を飛ばして確定の要求を直接送る、使用済みの値をもう一度送る、二つの操作をほぼ同時に送る、他人のファイルを指定してダウンロードする、といった試験です。こうした不備は、ツールの決まった攻撃パターンでは見つけにくいものです（競合状態などは支援士解説2の5）。

午後での問われ方

• 平成30年度春期 午後II問2（5.と同じ問題）：アクセス制御や認可の診断の方法として、解答例は「権限が異なる複数の」アカウントを使い、「許可されている操作の違い」を確かめることです。

• 令和4年度春期 午後II問1：Webサイトのセキュリティと開発プロセスが題材でした。ツールによる診断では見つけにくい脆弱性として、解答例は「一部のセッション管理の脆弱性」と「認可・アクセス制御の脆弱性」です。

採点講評で指摘されたつまずき

• 平成30年度春期 午後II問2では、この設問の正答率が低く、アクセス制御や認可制御の診断方法をよく理解してほしいとされています。

• 令和4年度春期 午後II問1では、ツールで見つけにくい脆弱性を問う設問の正答率が低く、脆弱性の種類によって有効な検出の手段が異なることを理解してほしいとされています。

記述の型

• 認可の診断方法：「権限が異なる複数のアカウントで、許可されている操作の違いを確かめる」

• 自動では見つけにくいもの：「業務のルールに関わる認可の不備や、一部のセッション管理の不備は、手動で確かめる」

10. 指摘と「検出ゼロ」を正しく読む

検査が「問題あり」とした結果が実際の問題なら真陽性、問題がないのに検出したなら偽陽性（誤検知）です。問題があるのに検出しなかったなら偽陰性（見逃し）、問題がなく検出もしなかったなら真陰性です。英語では、誤検知をFalse Positive、見逃しをFalse Negativeと呼びます。ただし、指摘がゼロという報告だけで真陰性か見逃しかは分かりません。そもそも未実施や対象外なら、この四分類の検査結果に入れません。

指摘については再現条件、要求と応答、対象の版、権限、影響を確認します。偽陽性として閉じるなら、判断の根拠を残します。真陽性なら、どの情報にどのような影響があり、同じ原因が他の箇所にもないかを調べます。深刻さと、指摘が正しいという確信度を混同しません。報告書は指摘件数だけでなく、対象機能、到達した画面・API、対象外、使用したアカウント、WAF等による遮断、実施日時、残る課題を読みます。

既知の脆弱性の深刻度を示すCVSSは、対応を考える手がかりです。CVSS v4.0は基本評価、脅威評価、環境評価、補足評価を区別します。基本評価の点数だけを自団体の対応順に置き換えず、公開状態、扱う情報、悪用状況、緩和策、業務への影響を合わせて判断します。補足評価は点数に直接加算される群ではありません。「7点以上なら全案件を必ず公開前に修正」といった一律の義務は、この規格から導けません。FIRST「CVSS v4.0 Specification」

午後での問われ方

• 令和6年度秋期 午後問4（7.と同じ問題）：診断報告書では、Webアプリケーションの診断の結果として、セッションフィクセーション、メールヘッダーインジェクション、HTTPヘッダーの不備が、プラットフォームの診断の結果として、TLS 1.1が利用可能であること、HTTPサーバのバージョンが応答のヘッダーに出力されていることが挙げられていました。設問では、軽微に見える複数の脆弱性を組み合わせた攻撃の流れと、被害を軽くする仕様の改善が問われています。

採点講評で指摘されたつまずき

• 令和6年度秋期 午後問4では、攻撃による被害を軽減するHTTPヘッダーの効果を問う設問と、攻撃の後の流れを問う設問の正答率が低かったとされています。講評は、Webサイト全体の機能を考慮し、脆弱性を組み合わせて悪用する攻撃を考える能力を培ってほしいとしています。

報告書を受け取ったら

診断の報告書を受け取ったら、指摘ごとに、再現の手順、影響、対策の案を確かめ、自組織の環境での影響と合わせて対応の優先度を決めます。同じ原因の問題が、ほかの画面や共通部品にもないかを調べます。指摘を誤検知として閉じるなら、その根拠を残します。検査の対象外とされた範囲と理由も、次の診断の計画に引き継ぎます。

記述の型

• 「検出なし」の解釈：「検査した範囲で検出されなかっただけで、脆弱性がないとは言えない。未実施の範囲を分けて読む」

• 報告書で読む項目：「対象機能、到達した画面・API、対象外、使用したアカウント、WAFなどによる遮断、実施日時」

11. 修正・再テスト・回帰テストで、解消を確かめる

指摘を受けたら、原因を特定して直します。再テストは、同じ条件で元の問題が解消したかを確かめるものです。回帰テストは、修正によって既存の機能や安全条件が壊れていないかを調べます。例えば、申請理由のXSS対策を変更した後は、危険な入力が文字として表示されることに加え、正当な文字や帳票・通知が壊れていないかを見ます。同じ共通部品を使う別画面も確認します。

WAFの遮断やネットワーク制限は、修正までの暫定対策として役立つ場合があります。しかしアプリ内部の欠陥が直ったという意味ではありません。暫定対策の有効範囲、期限、根本修正の担当、再確認方法を別々に管理します。修正済みの連絡だけで完了とせず、再テストの結果と、公開する版への反映を確認します。

運用開始後も、新しい脆弱性情報、依存部品の更新、設定変更、APIの追加で前提が変わります。毎回全ての検査を最初から繰り返すとは限りません。変わった箇所と影響先を追い、部品の照合、設定確認、対象機能の再診断を組み合わせます。運用・保守の全体管理は支援士解説2の7で扱います。

運用中も、変化に合わせて確かめ直す

一度診断したシステムも、機能の追加、部品の更新、設定の変更、新しい攻撃手法の公表で、前提が変わります。重要な変更の後には対象の機能を再診断し、定期的な診断で全体を確かめ直します。インターネットから見える資産を把握する取組み（ASM）や、部品の脆弱性の照合（SCA）と組み合わせると、診断の間の変化にも気付けます（支援士解説3の6）。

記述の型

• 修正後の確認：「再テストで元の問題が直ったかを確かめ、回帰テストでほかの機能への影響を確かめる」

• WAFでの遮断：「修正までの暫定対策であり、アプリの欠陥そのものは残っている」

• 運用中の再診断：「重要な変更の後に対象の機能を再診断し、定期的な診断で全体を確かめ直す」

12. 午前II（科目A-2）で正誤を見分けるポイント

• 「SASTは、動作中のWebアプリに要求を送って脆弱性を探す」→ 誤り。それはDAST。SASTはソースコードなどを実行せずに解析する

• 「DASTは、ツールが到達しなかった画面も含めて検査できる」→ 誤り。到達した範囲しか検査できない

• 「IASTは、動作中のアプリの内部を計測し、実行された経路の情報を検査に使う」→ 正しい

• 「SCAは、使っているOSSの部品と版を、既知の脆弱性と照合する」→ 正しい

• 「ファジングは、大量の正常な要求で性能の限界を調べる負荷試験である」→ 誤り。想定外の入力で異常を探す

• 「ペネトレーションテストで目標に到達できなければ、脆弱性がないと証明できる」→ 誤り

• 「偽陽性とは、脆弱性があるのに検出されないことである」→ 誤り。それは偽陰性。偽陽性は誤検知

• 「回帰テストは、修正によって既存の機能が壊れていないかを確かめる」→ 正しい

• 「ブラックボックステストは、ソースコードや設計を見ながら行う」→ 誤り。それはホワイトボックス

• 「レッドチーム演習は、組織の検知と対応の力も含めて確かめる」→ 正しい

• 「テストに本番の個人情報をそのまま使うのが、最も確実で安全である」→ 誤り。テスト環境が漏えいの原因になる

• 「ログインが必要な画面の自動診断では、途中でセッションが切れても検査は続けられる」→ 誤り。ログイン画面に戻り、本来の機能は検査されない

• 「ソースコードから削除した秘密情報は、リポジトリの履歴からも取り出せない」→ 誤り。履歴に残ることがあるので、無効にして作り直す

理解度チェック

本文の理解を確かめるためのオリジナル問題です。実際の過去問ではありません。

問1　検出ゼロ

診断会社の報告書では指摘がゼロだったが、職員向けの画面にはログインできず、対象外になっていた。最も適切な判断はどれか。

• ア：全ての機能に脆弱性がない

• イ：検査した範囲では指摘がなく、職員向けの画面は未確認である

• ウ：職員向けの画面には脆弱性があると確定した

• エ：指摘がゼロなので、修正の計画は不要である

正解：イ。未実施の範囲は、検査して検出されなかった範囲と分けます。アとエは、未確認の範囲を見落としています。

問2　自動探査の漏れ

DASTのツールの自動探査で、検索結果が1件以上ないと表示されない画面が、診断対象に登録されなかった。最も適切な対応はどれか。

• ア：登録されなかった画面は、脆弱性がないとみなす

• イ：設計書で画面の一覧を確認し、漏れた画面を手動で登録し、表示に必要な値を用意して診断する

• ウ：ツールの診断の回数を増やす

• エ：WAFを導入したので、その画面の診断は省く

正解：イ。自動探査は、条件を満たさないと進めない画面にたどり着けません。設計書と照合して漏れを補います。

問3　診断PCの接続場所

インターネットから本番のWebサーバへの攻撃を想定した診断を行う。診断用のPCをつなぐ場所として、最も適切なものはどれか。

• ア：管理用のネットワーク

• イ：インターネットから本番のWebサーバへ届く経路と同じ条件になる場所

• ウ：開発者の端末と同じネットワーク

• エ：データベースサーバの直前

正解：イ。想定する脅威と同じ経路から検査しなければ、外からの攻撃の条件を確かめられません。

問4　認可の診断

利用者Aが、利用者Bの申請番号を指定してBの申請を表示できてしまう不備を見つけたい。最も有効な方法はどれか。

• ア：DASTのツールで、既知の攻撃パターンを送るだけにする

• イ：権限や所有者の異なる複数のアカウントを用意し、他人の対象への操作が拒否されるかを確かめる

• ウ：SASTで、危険な関数の使用だけを調べる

• エ：負荷試験で応答時間を測る

正解：イ。誰が何を見てよいかという業務のルールに関わる不備は、ツールでは判定しにくく、手動で確かめます。

問5　修正後の確認

XSSの指摘を受けて、申請理由の出力処理を修正した。最も適切な確認はどれか。

• ア：修正済みの連絡を受けたので、完了とする

• イ：同じ条件で元の問題が直ったかを再テストし、正当な文字や帳票・通知が壊れていないか、同じ部品を使う別の画面も含めて回帰テストを行う

• ウ：WAFで同じ攻撃が止まることだけを確かめる

• エ：指摘された画面だけを、目視で一度確認する

正解：イ。再テストと回帰テストは目的が違います。ウは暫定対策の確認で、アプリの修正の確認にはなりません。

実務と国・自治体では

実務では、仕様書に「脆弱性診断を実施する」とだけ書いても、ログイン後の画面を誰が何の権限で調べるか、APIや一括出力を含めるか、指摘をいつまでに直すかは決まりません。委託先に診断を任せる場合も、発注者が業務のルール（誰が何を見てよいか）を伝えなければ、認可の不備は見つかりません。対象と条件（利用者の種類、画面・API、稼働する版、外部連携、対象外とその理由）、方法と安全（自動と手動、負荷、停止条件、データの扱い）、成果物（到達した範囲、再現の条件、修正の状態）、受入れの判断（再テストの期限、残るリスクの判断者）を結び付けます。

政府機関等の統一基準は、アプリケーションのセキュリティ要件の仕様への明記と、開発時・運用中の脆弱性対策の確認を求めています。自治体向けのガイドラインも、ソースコード診断・Webアプリケーション診断・プラットフォーム診断を対象に応じて使い分ける考え方と、受入れ時の検査を解説しています。資料の位置付けは支援士解説1の1で整理しています。

まとめ

• 検査の方法は、動かすか・内部を見るか・自動か手動か・どの権限かで分ける。 SASTは静的、DASTは動的。名前より、実際に与えた情報と到達した範囲を読む。

• 自動診断は、到達した範囲しか見ない。 画面の漏れ、入力と出力の画面の違い、ロックや回数制限による中断に注意する。

• 診断の計画は、想定する脅威から決める。 どこから検査するか、IPSとの調整、時間帯、元に戻す手順。

• 「検出ゼロ」は安全の証明ではない。 認可の不備は、権限の異なる複数のアカウントで手動で確かめる。修正後は再テストと回帰テスト。

関連記事

• 前提：入力チェックだけで安全と言えますか｜支援士解説2の5（プログラムの脆弱性）

• あわせて読む：ログインできれば、安全なのか｜支援士解説2の4（認証・認可・セッション）

• 次に読む：保守を委託すれば、安全は続くのか｜支援士解説2の7（運用と保守）

• あわせて読む：脆弱性対応の優先順位はどう決める？｜支援士解説3の6（見つかった脆弱性への対応）

2026年10月改訂：午後の出題例と記述の型を加え、自動診断の落とし穴、診断の計画、開発工程でのSASTの使い方を補い、確認問題を四択で作り直して、構成を見直しました。