令和7年春 SC午後 問2 解説：脆弱性対応の優先順位判断

診断ツールを回すと、脆弱性は必ず数十件から数百件出てきます。そして現場が困るのは「見つけること」ではなく「どれから直すか」です。全部すぐ直せるなら悩みませんが、人も時間も足りない。だから優先順位をつける。その判断の根拠を言葉にできるかどうかが、そのまま午後の得点になります。シリーズ第6弾は、令和7年度 春期（2025年4月）SC午後 問2のテーマである脆弱性対応の優先順位判断を扱います。

この問題は、IPAの採点講評によると全体の正答率は平均的でした。ただし講評は、攻撃条件の複雑さ（AC）の評価根拠を問う設問と、現状値とEPSS値を比較する設問の2問について、正答率が低かったと指摘しています。理由ははっきりしていて、CVSS基本値だけでは解けないように作られているからです。攻撃条件の複雑さ（Attack Complexity）をなぜLと評価しなぜHと評価したのか、CVSS現状値とEPSSのどちらが運用しやすいのか、環境値と領域をどう組み合わせて優先度を決めるのか。知識として名前を知っているだけでは、解答欄が埋まりません。

筆者はCIOだった頃、WAFが高価で運用ハードルも高く導入を見送り、Webサーバ側のアクセス制御設定を工夫して泥臭く守っていました。当時ぶつかっていたのも、結局は同じ問題です。全部は守れないという前提のなかで、どこから手を付けるかを説明できる根拠が要る。本問が問うているのは、まさにその根拠づくりです。

なお本記事では、IPAの問題文そのものは引用せず、同じ論点を扱う架空の事例に置き換えて再現しています。実際の問題文と解答例はIPAの試験問題・解答例のページで公開されていますので、記事を読んだあとに突き合わせてみてください。

事例シナリオ：一斉診断で出てきた数十件を、どう並べ替えるか

登場する企業とサイト

K社は、業務用ソフトウェアの開発・販売を行う従業員3,000名の企業です。自社ホームページのほか、製品サポート用サイト、ECサイト、キャンペーンサイトなど複数のWebサイト（以下、サイトといいます）を運営しています。セキュリティに関する問合せ窓口は情報システム部が担当し、Dさんが実務を、G課長が意思決定を担当しています。

K社には、脆弱性診断についての社内ルールがあります。

• 扱う情報の重要性や停止による影響を勘案し、各サイトの所管部門が重要サイトを指定する
• 重要サイトは、PF診断（プラットフォーム、すなわちOSやミドルウェアに対する脆弱性診断）とWebアプリ診断（Webアプリケーションプログラムに対する脆弱性診断）の両方を、初回リリース前に実施する
• 初回リリース後の再診断は任意。重要サイト以外の診断も任意
• 検出された脆弱性はCritical、High、Medium、Low、Noneの5段階の深刻度レベルに分類し、High以上は速やかな修正を必須、それ以外は所管部門が対応要否を判断する

診断は、専門ベンダーR社に依頼するか、情報システム部が選定した診断ツールを各サイト担当者が実行するかのいずれかです。R社のWebアプリ診断は、脆弱性を実際に悪用できることを確認した上で報告するため社内での評判が良好です。一方、診断ツールを使う場合の深刻度レベルは、CVSS基本値によって機械的に分類されます。

発端：キャンペーンサイトへの指摘

ある日、K社のキャンペーンサイトX（以下、サイトXといいます）にSQLインジェクションの脆弱性があるという指摘が、問合せ窓口に寄せられました。サイトXは重要サイトに指定されておらず、リリース前の診断を受けていません。サイトXの仕様は次のとおりです。

• Webサーバ、Webアプリケーションサーバ、DBサーバで構成される
• キャンペーン情報はDBサーバに格納しているが、顧客情報は保有していない
• キャンペーンページのURLのクエリパラメータにコンテンツ番号が含まれる（例：https://site-x.example.jp/info?article=20250401）
• コンテンツ番号がDB上に存在しない場合、またはSQLが構文エラーになる場合は「コンテンツがありません」というメッセージを返す
• クエリパラメータ article の値は、SQLでの検索で数値型として扱われる

情報システム部が診断ツールを実行したところ、深刻度レベルHighのSQLインジェクションが検出されました。Dさんが手作業で確認したところ、クエリパラメータの値を変えると、正常なコンテンツが返る場合と「コンテンツがありません」が返る場合に分かれました。

サイトXの担当者は「①重要情報の漏えいなどの問題は発生しない。DBには顧客情報もない。インターネットからアクセスできないようにする必要はない」と主張しました。これに対してDさんは、「本脆弱性はブラインドSQLインジェクションの脆弱性に該当し、同様の手法を繰り返せばDBのテーブル名を特定できる」と説明し、その先に何が起きるかを示して対応の必要性を説きました。

一斉診断の実施と、初回と異なった診断結果

この一件を受けて、情報システム部は公開サイトは全て重要サイトに指定するようルールを変更し、あわせて全公開サイトに対する一斉診断をR社に依頼しました。

診断の結果、High以上の脆弱性が検出されたサイトが数サイト、Medium以下が数十件検出されたサイトも多数ありました。ここでDさんが引っかかったのは、初回リリース時の診断以降アップデートも設定変更もしていないのに、初回の診断結果と今回の結果が食い違うサイトがあったことです。R社の診断は決められた手順に従って行われ、結果は技術レビューを経るため、診断員による差はほぼないと聞いています。

Dさんが改めてR社に確認したところ、結果が変わった要因は②2つあることが分かりました。Dさんはこれを踏まえ、初回リリース後も定期的な診断が必要であるとG課長に報告しました。

PF診断で検出された脆弱性

PF診断で検出された主な脆弱性は次のとおりです。

項番	サイト	脆弱性ID	脆弱性の内容	深刻度レベル	CVSS基本値
1	サイトA	P-1	SSL/TLSサーバの暗号強度が弱く、推奨されていない鍵交換をサポート	Medium	5.9
2	サイトB	P-2	OpenSSHでリモートから認証なしに任意のコード実行が可能	High	8.1
3	サイトB	P-3	管理者用Webログイン画面で認証試行が何回でも可能	Medium	5.3
4	サイトC	P-4	省略	High	7.2
5	サイトC	P-5	省略	Critical	9.8

項番1について、CRYPTRECが作成し、IPAとNICTが発行している「TLS暗号設定ガイドライン」では、鍵交換におけるビットセキュリティの基準が示されています。ECDHEについては128ビットセキュリティ以上を満たす曲線、DHEについては112ビットセキュリティ以上を満たす鍵長という基準です。K社は、この基準を満たす設定に変更することにしました。③対策は、弱い鍵交換方式を止めるという設定変更で完結します。

項番2の脆弱性P-2は、管理者がメンテナンス用にリモートアクセスで使っているOpenSSHで検出されました。OpenSSHでは、ログインが一定時間内に成功しないと認証試行のタイムアウト処理が実行されます。P-2は、あるセキュリティベンダーの報告によると、認証試行のタイムアウト処理が同時に多数実行されると起き得る問題であり、接続時間の設定が120秒の場合にその間に100件試行されると、OpenSSHのログに認証タイムアウトのメッセージが多数出力されます。報告では、平均3〜4時間で競合状態に勝ち得るとされ、実際のリモートコード実行に至るまでには平均6〜8時間を要するとのことでした。

修正済みバージョンへ更新できない場合の選択肢は2つ示されました。1つはトレードオフを承知で認証試行にタイムアウトを設けない設定変更、もう1つは④サイト担当者が攻撃を早期に検知する方法を採用して被害を抑止することです。サイトBでは最終的にOpenSSHの更新を行いました。

項番3の脆弱性P-3は、送信元IPアドレス制限が対策の一つですが、管理者が自宅や外出先からアクセスするため現実的ではありません。ログイン画面のアカウントロックも候補ですが、ロック解除の運用方法や実装の検討が必要です。サイトBでは、⑤アクセス元のPCを認証する対策を採用しました。

Webアプリ診断で検出された脆弱性

Webアプリ診断で検出された主な脆弱性は次のとおりです。

項番	サイト	脆弱性ID	脆弱性の内容	深刻度レベル	CVSS基本値
1	サイトA	W-1	本来閲覧できない画面を閲覧可能	Medium	4.3
2	サイトB	W-2	本来閲覧できない画面を閲覧可能	Medium	5.3
3	サイトC	W-3	OSコマンドインジェクション	Critical	9.8

W-1は、購入機能で商品の詳細を閲覧するリクエストに含まれるパラメータ item の5桁の数字を変えることで、一般会員が本来閲覧できない商品の説明画面を閲覧できたものです。

W-2は、管理者用アカウントでログインして発注確認機能のURL（https://site-b.example.jp/administrator0001/order_history のような推測困難な文字列を含むURL）を確認した上で、いったんログアウトして一般利用者アカウントでログインし直し、ブラウザのアドレスバーに当該URLを入力することで、他人の発注情報が全て閲覧できたものです。

W-1とW-2は「HTTPリクエストの内容を一部変更すると本来閲覧できない画面が閲覧できる」という点では同じですが、⑥CVSSの評価指標のうちAttack Complexity（AC）の値は、W-1がL、W-2がHと評価されました。

W-3は、問合せフォームが入力値を直接シェルに渡す作りになっており、任意のOSコマンドが実行できたものです。ただし、管理者権限が必要な操作はできませんでした。サイトCの仕様を確認すると、Webアプリケーションプログラムは一般利用者権限の専用アカウントでプロセスを実行していました。⑦管理者権限が必要な操作ができなかったのは、この仕様どおりの結果です。

新しい評価方法の検討

一斉診断が一段落したところで、情報システム部は脆弱性管理の課題を議論しました。対応の要否判断が不適切だったサイトや、対応が遅すぎたサイトがあったためです。G課長は、Dさんに新たな脆弱性評価方法の検討を指示しました。

Dさんが調査したところ、IPAが「脆弱性対応におけるリスク評価手法のまとめ」というレポートを公開していたので、これを参考にすることにしました。レポートでは、対応が必要な脆弱性を簡易的な1次評価で選び、さらに2次評価で優先度を評価する手法が提案されています。

Dさんの案は次のとおりです。

1次評価では、CVSS基本値とEPSS値の2軸で脆弱性を4つの領域に分類します。EPSS（Exploit Prediction Scoring System）は、公表された脆弱性が今後30日以内に悪用される確率を機械学習モデルで予測した値です。

• しきい値A（基本値）＝7.0、しきい値B（EPSS値）＝1%
• 基本値としきい値A、EPSS値としきい値Bの大小で、領域Ⅰ〜Ⅳに分類する
• EPSS値がしきい値Bを下回り、かつ基本値がしきい値Aを下回る領域Ⅳは対応不要とし、残りの領域Ⅰ〜Ⅲを2次評価の対象にする
• 境界上の値は、高い側の領域として扱う

Dさんは「EPSS値の代わりにCVSS現状値を用いる方法もあるが、⑧現状値と比べるとEPSS値は手間が掛からない」と説明しました。G課長は、しきい値の設定によって対応すべき脆弱性に漏れが出るようなら見直すこと、そして「EPSS値を用いた1次評価について、しきい値の見直し以外にも、（　あ　）を継続的に行うことが被害を防ぐ助けになる」と述べました。

ここでG課長が指摘したのは、Webアプリ診断で見つかった脆弱性にはEPSS値が報告されないことです。EPSS値はCVE番号が採番された脆弱性に対して算出されるため、個別のWebアプリケーションの実装に起因する脆弱性は対象外になります。Dさんは「⑨R社のWebアプリ診断であれば、見つかった脆弱性のEPSS値はしきい値Bよりも高いとみなすのが妥当であり、Webアプリ診断で検出される脆弱性は全て領域ⅠかⅢとみなす」と答えました。

2次評価では、CVSS環境値と1次評価で判定した領域を組み合わせて、最終的な対応優先度をS〜Cで決定します。次の表は、対象となった脆弱性から主なものを抜粋したものです（P-3とW-2は割愛しています）。環境値の算出にあたっては、現状評価基準の各評価指標を「Not Defined」と設定できます。環境評価基準の各評価指標の値の判断は、各サイト担当者に依頼します。

領域	環境値 0〜3.9	環境値 4.0〜6.9	環境値 7.0〜8.9	環境値 9.0〜10.0
Ⅰ、Ⅲ	C	B	A	S
Ⅱ	C	C	B	A

S：即時対応　A：対応優先度高　B：対応優先度中　C：対応優先度低

2次評価の実施

Dさんが実際に評価した結果は次のとおりです。

項番	脆弱性ID	EPSS値（%）	CVSS基本値	CVSS環境値	領域	対応優先度
1	P-2	42.0	8.1	7.6	Ⅰ	（　い　）
2	P-4	0.0	7.2	5.7	Ⅱ	（　う　）
3	P-5	2.4	9.8	9.1	Ⅰ	S
4	P-1	0.3	5.9	4.2	（　え　）	（　お　）
5	W-1	対象外	4.3	5.0	Ⅲ	B
6	W-3	対象外	9.8	9.8	Ⅰ	S

この運用によって、脆弱性対応の優先度評価がサイト担当者によらず、適切かつ迅速にできるようになりました。

設問

本番と同じつもりで、字数制限を守って手を動かしてみてください。字数制限のある設問は、書けた答案の文字数を必ず数えてから先へ進みましょう。

設問1

（1）下線①について、サイトXの担当者の主張が誤りである理由を、Dさんの説明を踏まえて40字以内で述べよ。

（2）下線②について、アップデートも設定変更もしていないサイトで診断結果が変わった要因を、2つそれぞれ20字以内で述べよ。

設問2

（1）下線③について、サイトAで行うべき設定変更の内容を35字以内で述べよ。

（2）下線④について、サイト担当者が攻撃を早期に検知する方法を、40字以内で具体的に述べよ。

（3）下線⑤について、採用した対策を20字以内で具体的に述べよ。

設問3

（1）下線⑥について、W-1のACがLと評価された評価根拠と、W-2のACがHと評価された評価根拠を、それぞれ30字以内で述べよ。

（2）下線⑦について、管理者権限が必要な操作ができなかった理由を、サイトCの仕様に触れて30字以内で述べよ。

設問4

（1）下線⑧について、CVSS現状値は手間が掛かり、EPSS値は手間が掛からない理由を、それぞれ40字以内で述べよ。

（2）本文中の（　あ　）に入れる適切な字句を15字以内で答えよ。

（3）下線⑨について、そのようにみなすことが妥当である理由を30字以内で述べよ。

設問5

表中の（　い　）〜（　お　）に入れる領域及び対応優先度を答えよ。また、（　お　）の脆弱性について、2次評価を行わない理由を30字以内で述べよ。

回答例

設問1の回答例

（1）DBのテーブル名などの構造を特定され、次の攻撃の足掛かりにされるから（34字）

サイト担当者の主張は「今この瞬間に漏れる重要情報がない」という一点に立っています。ブラインドSQLインジェクションが怖いのは、漏えいそのものではなく、攻撃者が手探りでDBの構造を特定できてしまうことです。テーブル名が分かれば、次は列名、次はデータ本体と段階的に進めます。

通常のSQLインジェクションは応答本文にデータそのものが出てきますが、ブラインドの場合は出てきません。だから攻撃者は条件式の真偽を1ビットずつ推定して中身を復元していきます。ここで書くべきは「情報が漏れる」ではなく、「次の攻撃につながる」という時間軸です。応答が2種類（正常なコンテンツか、コンテンツがありませんか）しか返らなくても、条件式の真偽を1ビットずつ確認すれば構造は復元できます。SQLインジェクションの攻撃手法そのものはSQLインジェクションの過去問解説記事で詳しく扱っています。

（2）

• 新たな脆弱性が発見されたこと（14字）
• 深刻度の評価が見直され値が変わったこと（19字）

「サイトは変わっていないのに結果が変わった」という状況で、変わり得るのはサイト側ではなく外側です。外側で変わるものは2つしかありません。時間の経過とともに新しい脆弱性が公表されること、そして既知の脆弱性についてリスクの評価が見直されて値が変わることです。

この設問は、脆弱性情報が固定された静的なデータではないという前提を問うています。診断は写真ではなく定点観測である、と覚えておくと書きやすくなります。JVNなどの脆弱性情報データベースの更新のされ方はJVNと早期警戒パートナーシップの記事で整理しています。

設問2の回答例

（1）基準を満たす鍵長・曲線の鍵交換だけを許可し、弱い方式を無効にする（32字）

この設問は知識の量ではなく、対策のレイヤを間違えないかを見ています。暗号強度が弱い鍵交換をサポートしているという指摘に対して、プログラム修正やネットワーク機器の追加は不要です。サーバの設定で、基準を満たさない鍵交換方式を無効にすればよい。ECDHEなら128ビットセキュリティ以上を満たす曲線、DHEなら112ビットセキュリティ以上を満たす鍵長という基準を、そのまま設定に落とし込みます。

（2）ログに認証タイムアウトのメッセージが多数出たらサイト担当者に通知する（34字）

「早期に検知する方法」を聞かれたら、何を見て、どうなったら、誰に知らせるかの3点セットで書きます。この事例では、攻撃の過程で「認証試行のタイムアウト処理が同時に多数実行される」と書かれているので、見るべきものはOpenSSHのログに出力されるタイムアウトのメッセージ、条件は「多数」、通知先はサイト担当者です。

事例中に、競合状態に勝ち得るまで平均3〜4時間、実際のリモートコード実行に至るまで平均6〜8時間を要すると書かれているのが伏線です。攻撃の成立まで数時間かかるなら、その間に気づけば間に合う。だから修正版へ更新できない場合の代替策として検知が挙がっています。これは緩和策の典型で、脆弱性そのものはなくならないが被害の成立を防ぐという発想です。解決策と回避策の区別はJVNの読み方をまとめた記事で整理しています。

（3）クライアント証明書による認証（14字）

「アクセス元のPCを認証する」という表現に対応するのは、PCに導入したクライアント証明書を使ったクライアント認証です。パスワードは人を認証しますが、証明書は端末を認証できます。送信元IPアドレス制限が使えない（自宅や外出先からアクセスする）という制約が、そのまま「IPアドレスではなく端末そのものを識別する」という方向に誘導しています。

設問3の回答例

（1）

• W-1：パラメータitemの値が容易に推測できるから（22字）
• W-2：発注確認機能のURLが推測困難で入手が必要だから（24字）

採点講評でも正答率が低いと指摘された設問です。多くの受験者がAC（Attack Complexity）ではなくC（Confidentiality Impact、機密性への影響）の説明を書いてしまいました。両者はどちらも「見えてはいけないものが見えた」話なので、混同しやすいのです。

ACは「攻撃者が制御できない条件がどれだけあるか」を表します。W-1は5桁の数字を変えるだけなので、攻撃者は自分の操作だけで到達できる。よってL（低い）です。W-2は、まず推測困難なURLを知らなければ始まりません。攻撃者の意のままにならない事前の情報収集が必要になる。よってH（高い）です。なお「管理者としてログインしていること」のような権限の話はPR（Privileges Required）の領域であり、ACの根拠として書くと別指標の説明になってしまいます。

攻撃の結果ではなく、攻撃の入口に至るまでの条件を書く。これがACの設問の書き方です。CVSSの各評価指標の意味は脆弱性評価の完全ガイドにまとめてあるので、AV・AC・PR・UI・S・C・I・Aの8つを一度整理しておいてください。

（2）一般利用者権限の専用アカウントでプロセスを実行しているから（29字）

OSコマンドインジェクションで実行されるコマンドは、Webアプリケーションのプロセスの権限で動きます。プロセスが一般利用者権限なら、攻撃者も一般利用者権限しか得られません。逆にrootやAdministratorで動かしていれば、そのまま管理者権限を奪われます。

この設問は「脆弱性はあったが被害が限定された理由」を問うており、答えは最小権限の原則が効いたことです。攻撃を防いだのは入力値検証ではなく、権限設計だった。多層防御がどこで効いたかを読み取る練習になります。

設問4の回答例

（1）

• 現状値：攻撃コードの有無などを多数の公開サイトの情報から自分で判断する必要があるから（38字）
• EPSS値：FIRSTのサイトで公開されている値をそのまま使えばよいから（30字）

これも正答率が低かった設問です。差がつくのは知識ではなく、利用手順を具体的に想像できているかでした。

本問が前提にしているのはCVSS v3.1です（採点講評も「CVSSv3の評価指標」と明記しています）。v3.1の現状評価基準（Temporal Metrics）は、攻撃される可能性（Exploit Code Maturity）、利用可能な対策のレベル（Remediation Level）、脆弱性情報の信頼性（Report Confidence）の3つから算出します。なおv4.0ではこれが脅威評価基準（Threat Metrics）に改称され、RLとRCは廃止されてExploit Maturityの1指標だけになりました。これらは誰かが一覧で配ってくれるものではありません。攻撃コードが公開されているか、実証コードどまりか、ベンダーの正式パッチが出ているか。評価者が複数の公開情報を調べて自分で判定する必要があります。ここが「手間」の正体です。

一方EPSS値は、FIRSTのEPSS Special Interest Groupが運営する枠組みのもとで機械学習モデルにより算出され、CVE単位で日次公開されている数値をそのまま引ける。APIやCSVで一括取得もできます。評価者がやることは参照だけです。

「EPSSは自動で計算されるから楽」という書き方では弱い。誰が値を作るのかという点に踏み込んでください。現状値は自分で作る、EPSS値は他者が作ったものを使う。この対比が採点の軸です。

（2）EPSS値の監視（8字）

EPSS値は毎日更新されます。攻撃コードの公開や実際の悪用の観測を反映して、昨日0.1%だった値が今日5%になることがある。つまり、1次評価は一度やって終わりではありません。しきい値の見直し以外に継続的に行うべきことは、EPSS値そのものの監視です。

「脆弱性情報の収集」と書きたくなりますが、文脈は「EPSS値を用いた1次評価について、しきい値の見直し以外にも」です。話題はEPSSに限定されているので、EPSS値の監視まで具体化します。設問が絞り込んでいる範囲より広い答えを書くと減点されるのは、午後全体に共通するルールです。

（3）実際に悪用できることを確認した上で報告されているから（26字）

EPSS値は「悪用される確率の予測」ですが、R社のWebアプリ診断は「悪用できたという事実」を報告します。予測より事実の方が強い。だから、EPSS値が付かない脆弱性であっても、しきい値B（1%）より高い側とみなして差し支えありません。

事例の冒頭で、R社のWebアプリ診断は脆弱性を実際に悪用できることを確認した上で報告するため評判が良好だと紹介されているのが伏線です。何気ない紹介文に見えて、設問の根拠がそこにしかありません。事例の前半に出てくる「評判がよい」「定評がある」といった表現は、後半の設問の根拠になると考えてください。

設問5の回答例

• （　い　）A
• （　う　）C
• （　え　）Ⅳ
• （　お　）対応不要（2次評価の対象外）
• 理由：1次評価で領域Ⅳと判定され、対応不要となるから（23字）

手順は必ず「1次評価（領域）→2次評価（優先度）」の順です。順序を逆にすると必ず間違えます。

（い）のP-2は、EPSS値42.0%がしきい値B（1%）を超え、基本値8.1がしきい値A（7.0）を超えるので領域Ⅰ。領域Ⅰ・Ⅲの行で環境値7.6を見ると7.0〜8.9の列なのでAです。

（う）のP-4は、EPSS値0.0%でしきい値Bを下回り、基本値7.2はしきい値Aを超えるので領域Ⅱ。領域Ⅱの行で環境値5.7を見ると4.0〜6.9の列なのでCです。ここが引っかけどころで、同じ環境値でも領域が違えば優先度が変わります。領域Ⅰ・Ⅲなら同じ環境値でBでした。

（え）（お）のP-1は、EPSS値0.3%がしきい値Bを下回り、基本値5.9もしきい値Aを下回るので領域Ⅳ。領域Ⅳは2次評価の対象外なので、環境値4.2が算出されていても優先度は付きません。環境値の数字だけ見て表を引くと、ここで事故ります。

なお、W-1とW-3はEPSS値が対象外ですが、設問4(3)の考え方によりEPSS値はしきい値Bより高い側とみなします。基本値4.3のW-1はしきい値A（7.0）を下回るので領域Ⅲ、基本値9.8のW-3は上回るので領域Ⅰです。W-1は環境値5.0でB、W-3は環境値9.8でSです。W-1は基本値4.3のMedium、つまり従来の「High以上は速やかな修正を必須」というルールでは所管部門の判断に委ねられていた脆弱性ですが、新しい評価方法ではBの優先度が付きます。深刻度レベルだけで対応要否を決めていた運用の穴が、ここで塞がれているわけです。

採点ポイント

なお本記事は、問われている論点を保ったまま事例を架空の企業・サイトに再構成しています。そのため設問の番号や構成は本試験と一致しません。論点の対応関係を確認したい場合は、IPAが公開している問題冊子と採点講評を併せて参照してください。

加点される要点

この問題で点になっているキーワードを並べると、傾向がはっきりします。

• テーブル名を特定できる／次の攻撃につながる（ブラインドSQLインジェクションの危険性）
• 新たな脆弱性の発見／評価の変更（診断結果が変わる2つの要因）
• ログのメッセージが多数出たらアラート（検知方法の具体性）
• クライアント証明書（IPアドレス以外で端末を識別する手段）
• 値が容易に推測できる／推測困難で入手が必要（ACの評価根拠）
• 一般利用者権限で実行している（被害が限定された理由）
• 自分で判断する必要がある／そのまま使える（現状値とEPSS値の手間の差）
• 実際に悪用できることを確認済み（予測ではなく事実）
• 領域を先に決めてから優先度表を引く（2段階評価の手順）

派手な攻撃名はほとんど登場しません。点になっているのは、手順と根拠の言語化です。

よくある減点・失点パターン

ACの評価根拠にCの説明を書いてしまう。 採点講評が明示的に指摘した最頻出の失点です。「他人の発注情報が閲覧できるから」は影響（C）の話であって、条件の複雑さ（AC）の話ではありません。指標名を見たら、その指標が何を測っているのかを口に出してから書き始めてください。

現状値とEPSS値の違いを「精度」や「新しさ」で答える。 聞かれているのは手間です。どちらが正確か、どちらが新しい指標かではなく、評価者の作業量の差を書きます。設問が指定した観点から外れると、内容が正しくても0点になります。

ブラインドSQLインジェクションの危険性を「情報が漏えいする」で止める。 担当者は「漏れる重要情報がない」と主張しているので、その反論になっていません。構造を特定され、次の攻撃につながるという段階性を書きます。

サイトXの仕様を踏まえずに答える。 採点講評は設問1について「本文中で示されているWebサイトの仕様が考慮されていない解答が散見された」とも指摘しています。パラメータ article は数値型として扱われ、存在しない場合も構文エラーの場合も同じ「コンテンツがありません」が返る——この仕様が、真偽を1ビットずつ読み取れるという結論の前提です。仕様の記述は飾りではなく、設問の足場です。

検知方法を「ログを監視する」とだけ書く。 何のログの何を見るのかが入っていないと、具体性を問う設問では加点されません。「OpenSSHのログの認証タイムアウトのメッセージ」まで書きます。

領域を飛ばして環境値だけで優先度表を引く。 表の行は領域で決まります。領域Ⅳなら表を引く前に対応不要で終わりです。手順を守れば確実に取れる設問なので、ここを落とすのは非常にもったいない。

EPSS値を「深刻度」として説明する。 EPSSは深刻度ではなく悪用される確率の予測です。CVSSが「当たったらどれだけ痛いか」、EPSSが「当たりそうか」。この役割分担を混ぜると、設問4は全滅します。

字数調整のコツ

30字前後の設問は、要素1つを具体的に書き切れば埋まります。40字の設問は「何を・どうする必要があるから」まで入れて因果を完結させます。この問題では理由を問う設問が多いので、文末を「〜から」「〜ため」で締める型を先に用意しておくと、書き出しで迷いません。字数が足りないときは対象を具体化し（「ログ」→「OpenSSHのログの認証タイムアウトのメッセージ」）、はみ出すときは事例の固有名詞を代名詞化せずに削れる修飾語から落とします。

頻出パターン

深刻度と優先度を区別させる型

「CVSS基本値が高い＝先に直す」ではない、という気づきを問う型です。基本値は脆弱性そのものの性質、環境値は自組織での影響、EPSS値は悪用される確率の予測。3つは別の軸であり、掛け合わせて初めて優先順位になります。午後でこの型が出たら、どの値が何を表しているかを紙の端に書き出してから設問に入ると事故りません。脆弱性管理の全体像はシステム運用セキュリティ完全ガイドで扱っています。

CVSSの評価指標の意味を問う型

AC、PR、UI、Sあたりは毎回のように顔を出します。特にACとC、PRとUIは混同しやすいので、「ACは攻撃者が制御できない条件の数」「PRは攻撃前に必要な権限」「UIは被害者の操作が必要か」「Sはスコープが変わるか」と一言で言えるようにしておきます。CVSSベクタが問題文に載っている場合は、そこに答えが半分書いてあると考えてよいです。

対策が使えない制約下で代替策を出す型

「送信元IPアドレス制限は現実的でない」「修正版に更新できない」といった制約が事例に書かれていたら、それは代替策を答えさせる合図です。引き出しとして、端末認証（クライアント証明書）、アカウントロック、多要素認証、検知と通知、ネットワーク的な隔離を用意しておきます。解決策（根本対策）と回避策（被害を抑える緩和策）の区別は、JVNと早期警戒パートナーシップの記事で整理したとおりです。

診断結果の読み方を問う型

「診断で検出されなかった＝安全」ではありません。診断は実施した時点の、実施した範囲についての結果です。時間が経てば新たな脆弱性が公表され、評価も変わる。だから定期的な再診断が要る。この論理は、脆弱性診断・ペネトレーションテスト・SBOM運用のいずれをテーマにしても共通して使えます。ツールによる診断の仕組みはWeb脆弱性診断ツールの記事で扱っています。

権限設計が被害範囲を決めるという型

OSコマンドインジェクション、ファイルアップロード、テンプレートインジェクションなど、コード実行につながる脆弱性では必ず「どの権限で実行されるか」が問われます。プロセスの実行権限、DBの接続ユーザの権限、ファイルの所有者。同じ脆弱性でも権限設計次第で被害の大きさが変わるという視点を持っておくと、初見の攻撃名でも答えが書けます。

まとめ：脆弱性対応は「深刻度」ではなく「手順」で決める

令和7年春 午後問2は、脆弱性の名前を知っているかではなく、優先順位を決める手順を説明できるかを問う問題でした。骨格は3つです。1つ目はCVSS基本値・環境値・EPSS値は別の軸であること。基本値は脆弱性そのものの性質、環境値は自組織での影響の大きさ、EPSS値は今後30日以内に悪用される確率の予測です。2つ目は1次評価で領域を決め、2次評価で優先度表を引くという順序。領域Ⅳなら表を引く前に対応不要で終わります。3つ目は評価は一度で終わらないこと。EPSS値は毎日更新され、脆弱性情報も日々増えるため、しきい値の見直しとEPSS値の監視を継続的に回す必要があります。

CIOだった頃、WAFは高価で運用のハードルも高く、導入を見送ってWebサーバ側のアクセス制御設定で泥臭く守っていました。使える手段が限られているほど、どこから手を付けるかの判断は重くなります。CVSSとEPSSを組み合わせた評価は、まさにその判断の根拠を作るための道具です。「深刻度Highだから直します」ではなく「悪用される確率が高く、自社環境での影響も大きいから、この順で直します」と言えるようになる。試験問題の形をしていますが、実務でそのまま使える枠組みです。

午後でこのテーマが出たら、値の名前を並べるのではなく「その値が何を測っていて、誰が作るのか」まで書き切ってください。基本値は脆弱性の性質を測り、共通の基準として配布されるもの。現状値は攻撃コードの状況を測り、評価者自身が公開情報を集めて判断するもの。EPSS値は悪用される確率を測り、外部が算出した値をそのまま参照できるもの。環境値は自組織での影響を測り、システムを知っているサイト担当者にしか判断できないもの。誰が値を作るのかという視点が入っていれば、「手間が掛かる理由」を問われても手が止まりません。

本記事は情報処理安全確保支援士（SC）試験対策を目的として作成しています。

参考資料

• 情報処理安全確保支援士試験（IPA）
• 令和7年度春期 情報処理安全確保支援士試験 午後 解答例（IPA・PDF）
• 令和7年度春期 情報処理安全確保支援士試験 午後 採点講評（IPA・PDF）
• 脆弱性対応におけるリスク評価手法のまとめ（IPA）
• EPSS（FIRST）

事例解説シリーズ

• 令和7年秋 SC午後 問1 解説：SaaSの格納型XSSとファイルアップロード検証不備
• 令和7年秋 SC午後 問2 解説：暗号技術による機密性・完全性の担保
• 令和7年秋 SC午後 問3 解説：リモートワーク環境の導入とVPNサービスの選定
• 令和7年春 SC午後 問1 解説：サプライチェーンリスク管理
• 令和7年春 SC午後 問4 解説：放置ドメインとサブドメインテイクオーバー