脆弱性対応の優先順位はどう決める？——CVSS・EPSS・KEV・パッチ管理・ASMを午後の問われ方で読む｜支援士解説3の6

この記事の重要度：Sランク（午後で繰り返し主役になる最重要の分野）

この記事で分かること：

• CVE・CVSS・EPSS・KEVの違いと、自組織の環境に照らした対応の優先度の決め方

• 資産の把握とASM、すぐに直せないときの暫定対策、パッチの適用から確認までの管理

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

シラバスとの対応：小項目3-6「脆弱性への対応」。脆弱性診断の方法は支援士解説2の6、SBOMと委託先の管理は支援士解説3の10、保守の委託は支援士解説2の7、侵害の疑いがある場合の対応は支援士解説4の3で扱います。

午後の問題では、「脆弱性が公表された。どれから、どう対応するか」がよく問われます。CVSSの点数、悪用の状況、外部から届くか、業務への影響を読み取って優先度を決め、すぐにパッチを当てられないなら暫定対策を選び、当てたら全台で有効になったかを確かめる。どの段階にも、正答率の低かった設問があります。

この記事では、脆弱性対応を「特定・判断・実施・確認」の流れで整理し、CVSS・EPSS・KEVの読み方、資産の把握とASM、暫定対策の選び方、パッチの管理を順に見ていきます。

1. 脆弱性対応は、情報を受け取る前から始まる

脆弱性と、攻撃と、被害を分ける

脆弱性とは、攻撃などによって悪用される可能性のある弱点です。この回では主に、ソフトウェア、機器、設定に関する弱点を扱います。

例えば、本来は管理者だけが実行できる操作を、認証せずに呼び出せてしまう不具合があれば、脆弱性になり得ます。その不具合を利用して侵入を試みる行為が攻撃であり、データが取得されたりサービスが停止したりすることが被害です。

脆弱性があるからといって、すでに侵入されていると断定はできません。一方、まだ被害が確認されていないことを理由に、対処しなくてよいとも言えません。

ここを分けると、2つの作業が見えてきます。1つは弱点を取り除いたり、悪用される条件を減らしたりすること。もう1つは、悪用された兆候がないかを調べることです。

侵害の疑いがある場合には、単に更新して終わりではなく、インシデント対応として、調査・封じ込め・証拠の保全なども必要になります。修正プログラムは、すでに盗まれた認証情報などの秘密情報や、作られた不正アカウントを、必ず元に戻してくれるものではありません。

情報を集めても、使っているものが分からなければ動けない

脆弱性の速報を受け取ったとき、最初に必要になるのは、自分たちに関係するかという確認です。そのためには、使っている製品と構成を把握しておかなければなりません。

サーバとPCだけではありません。VPN機器、ファイアウォール、複合機のファームウェア、Webアプリケーションのライブラリ、クラウド上のコンテナなども対象になり得ます。

例えば、システムの名称は分かっていても、その中で使う部品の版が分からなければ、事業者へ照会して回答を待つことになります。あらかじめ構成情報の管理と照会先を決めておくことが、対応速度に関わります。

脆弱性情報を集める

情報の入手先は、一つではありません。製品の提供元のアドバイザリ、JVN、JPCERT/CCやIPAの注意喚起、CISAのKEVカタログ、業界の情報共有の組織（ISAC）、自組織の脆弱性診断の結果などがあります。大切なのは、誰が、どの製品について、どの情報源を確認するかを決め、資産台帳と照らせるようにしておくことです。

情報源によって、公開の時期や詳しさが違います。最初に読んだ時点の情報だけで判断を固定せず、更新を追います。

基本の流れは、特定・判断・実施・確認

脆弱性対応の流れは、情報を受け取ってから、大きく次の4つの段階で整理できます。

1. 特定する：製品の通知、JVN、診断結果、外部からの報告などを受け取り、どの資産・版・設定が影響を受けるかを調べる。

2. 判断する：悪用状況、公開範囲、業務影響から、措置と期限を決める。

3. 実施する：暫定対策、更新、設定変更、停止などを行う。

4. 確認する：対処の有効性、業務の正常性、取り残しを確認して記録する。

ただし、必ず一列に順番を待つという意味ではありません。実際の配備と照合し、調査中・緩和済み・修正済みを区別し、未完了の対象や例外も記録します。緊急性が高ければ、影響調査と並行して、公開範囲を絞ったり、侵害の兆候を調べたりします。判断に必要な情報がすべてそろうまで、無条件に何もしないという運用にはしません。

パッチ管理を継続的な保守として位置付ける考え方は、NIST SP 800-40 Rev.4でも示されています。本稿の流れは、その考え方を自治体の判断場面に合わせて整理したものです。NIST SP 800-40 Rev.4「Guide to Enterprise Patch Management Planning」

午後での問われ方

• 平成30年度秋期 午後I問3：公開サーバのアプリケーションフレームワークの脆弱性を突かれた場面で、攻撃がほかの機器に広がったかを調べる方法が問われました。解答例は、攻撃の内容に沿って、調べる機器と内容を組み合わせるものです。例えば「外部メールサーバ又はログ管理サーバ」で「外部メールサーバからサイトZへの接続の有無を確認する」、「FW1又はログ管理サーバ」で「サイトZとHTTPを使用した通信を確認する」といった組合せです。採点講評は、攻撃の内容とかけ離れた解答も散見されたので、攻撃の内容から何を調査すべきかを見極めてほしいとしています。

2. CVE・CWE・CPEと、情報を探す場所

CVE：同じ脆弱性について話すための識別子

CVEは、公開された脆弱性を共通の識別子で扱うための仕組みです。CVE IDは、一般に CVE-西暦-連番 の形式で表されます。

製品ベンダー、診断会社、利用者がそれぞれ別の呼び方をしていると、同じ問題を話しているのか分かりにくくなります。CVE IDがあれば、情報の対応付けをしやすくなります。CVE Program「FAQs」

ただし、CVEの番号自体が、危険度や対処の優先順位を表しているわけではありません。また、一つのCVEが複数製品・複数の版へ影響する場合もあります。CVE一件だから自分たちの機器も一台、と数えないようにします。

逆に、CVEがまだ付いていない（未付与の）報告や、自分たちのアプリケーション固有の不具合でも、対応が必要な脆弱性はあります。番号の有無だけを受付や対処の条件にしないことが大切です。

CWE：何が原因で弱くなっているかを分類する

CWEは、ソフトウェアやハードウェアの弱点の種類を整理したものです。例えば、不適切な入力の扱い、認証の欠如、メモリの不適切な操作など、問題の型を分類します。CWE「About CWE」

CVEが個々の問題の識別に役立つのに対し、CWEは、同じ種類の弱点がどこに繰り返されているかを横断的に確認する材料になります。同じ種類の弱点でも、修正方法は製品ごとに別です。

例えば、複数のサービスで同種の認可の不備が見つかったなら、一件ずつ修正するだけでなく、共通の設計やレビュー項目を見直す必要があるかもしれません。個別対応から再発防止へつなぐときに、分類の意味が出てきます。

CPE：製品やプラットフォームを共通の形式で表す

CPEは、IT製品やプラットフォームの名前などを、共通の形式で扱うための仕組みです。製品名やバージョンなどを照合するときに利用されます。

ただし、名前の照合だけで影響判定が完了するわけではありません。製品のエディション、OS向けの修正、機能の有効・無効などで条件が異なる場合があります。

製品を共通の形式で表すことと、その環境で悪用が成立するかを評価することは別の段階です。NIST「Common Platform Enumeration」

JVNとJVN iPedia：日本語で情報を追う入口

JVNは、IPAとJPCERT/CCが共同で運営する脆弱性対策情報のポータルサイトです。JVN iPediaは、脆弱性対策情報を蓄積・検索するデータベースです。JVN「JVNとは？」、JVN iPedia

利用するときは、見出しや深刻度の表示だけでなく、影響を受ける製品、対策、ベンダーの情報へのリンクを確認します。日本語の情報で概要をつかみ、製品の公式情報（公式アドバイザリ）で、自分たちが使う版の条件と更新日を確認するという使い分けが基本です。JVN iPediaは、検索用のデータベースとして使います。

公式アドバイザリとは、脆弱性の影響範囲や対策手順に関する開発元の技術案内です。公表後に対象製品や修正版の情報が追加されることもあるため、最初に読んだ状態だけを永久に正しいものとして扱わないようにします。

診断結果も、重要な情報源になる

外部で公表された情報だけでなく、自分たちの脆弱性診断、コードレビュー、構成チェックの結果も管理対象です。

その際には、検出したツール名と危険度だけでなく、対象、検査した日時・版、成立条件、証拠、誤検知の可能性、未検査の範囲を確認します。

例えば、応答に表示された製品バージョンから判定した診断と、実際の修正済みパッケージの情報を照合した判定では、根拠が違います。結果が食い違えば、都合のよいほうを選ぶのではなく、何を見て判定したかを調べます。

午後での問われ方

• 令和4年度秋期 午後I問1：IoT製品の開発を題材に、Webアプリケーションの二つの脆弱性が該当するCWEを、解答群から選ぶ設問がありました。解答は、シェルが実行するコマンドをパラメータで不正に指定できる脆弱性が「CWE-78 OSコマンドインジェクション」、罠サイトから攻撃リクエストを送らせる脆弱性が「CWE-352 クロスサイトリクエストフォージェリ」です。CWEは、弱点の種類で分類する仕組みだと分かっていれば答えられます。

3. CVSSは深刻度を示すが、対応の順番は決めてくれない

点数の前に、何を評価しているかを見る

CVSSは、脆弱性の特性や技術的な深刻度を共通の枠組みで表す仕組みです。0から10のスコアを使いますが、自組織の年間損失額や、翌日に侵入される確率をそのまま表すものではありません。

例えば、外部から認証なしで悪用できるのか、特定の権限が必要なのか、利用者の操作が必要なのか、情報の機密性・完全性・可用性にどう影響するのか、といった条件が関係します。

同じ点数でも、その成り立ちは同じとは限りません。情報漏えいが中心の問題と、サービス停止が中心の問題では、守る業務によって判断が変わる場合があります。

3.1と4.0では、評価基準の構成が違う

CVSS 3.1では、基本評価基準（Base）、現状評価基準（Temporal）、環境評価基準（Environmental）という3つのグループで整理します。

基本評価は脆弱性そのものの特性、現状評価は攻撃コードや対策の状況など時間とともに変わる要素、環境評価は利用環境を踏まえる要素です。FIRST「CVSS v3.1 Specification Document」

一方、CVSS 4.0は、Base、Threat、Environmental、Supplementalの4つです。旧版のTemporal（現状評価基準）はThreat（脅威評価基準）に置き換わりました。教科書では名称変更と説明されることもありますが、評価項目も見直され、Threatは攻撃コードの成熟度で評価します（修正の状況や情報の信頼度の項目はなくなりました）。

Threatは悪用の状況、Environmentalは利用環境、Supplementalは安全への影響や復旧など、追加の判断材料を表します。SupplementalはCVSSの最終スコアを直接変更しません。FIRST「CVSS v4.0 Specification Document」、各評価基準の節

CVSSはFIRSTが管理する評価体系です。本稿では3.1と4.0を区別して説明しています。問題文や通知に記載されたバージョンを先に確認しましょう。

深刻度レベルと、主な評価項目

CVSSの点数は、次の深刻度レベルに対応付けて伝えるのが一般的です。

• 9.0〜10.0：緊急（Critical）

• 7.0〜8.9：重要（High）

• 4.0〜6.9：警告（Medium）

• 0.1〜3.9：注意（Low）

• 0.0：なし（None）

3.1の基本評価基準の主な項目は、次のとおりです。

• AV（攻撃元区分）：ネットワーク経由か、隣接ネットワークか、ローカルか、物理的なアクセスが必要か

• AC（攻撃条件の複雑さ）：攻撃の成立に、特別な条件が必要か

• PR（必要な特権レベル）：攻撃者に、どの程度の権限が必要か

• UI（ユーザ関与レベル）：利用者の操作が必要か

• S（スコープ）：影響が、脆弱なコンポーネントの外に及ぶか

• C・I・A：機密性・完全性・可用性への影響

ACは「攻撃条件の複雑さ」で、Cの「機密性への影響」とは別の項目です。略号を取り違えないようにします。

ベクトルは、採点の条件を確認するために読む

例えば、次のベクトルは、3.1の基本値9.8（緊急）になる典型的な組合せです。

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

ネットワーク経由で（AV:N）、特別な条件なしに（AC:L）、権限なしで（PR:N）、利用者の操作なしに（UI:N）攻撃でき、機密性・完全性・可用性への影響がいずれも大きい（C:H、I:H、A:H）、という意味です。点数の版と評価条件を確かめずに、別の版の点数と比べないようにします。

CVSSのベクトル文字列は、評価に用いた条件を略号で表したものです。数字だけでは見えない根拠を確認できます。

例えば、攻撃元の条件を示すAV、必要な権限を示すPR、利用者の関与を示すUIといった項目があります。AVがNetworkであっても、その機器が自組織でインターネット公開されていることを意味するわけではありません。脆弱性の攻撃条件と、実際の配置は別に調べます。

4.0では、攻撃成立に関わる前提条件を扱うATが追加され、脆弱なシステムへの影響と、その後に影響を受けるシステムへの影響も分けて表します。旧版の項目を1対1に置換して点数を読み替えることはできません。FIRST「CVSS v4.0 User Guide」、変更点

実務で点数を共有するときは、版、評価グループ、ベクトル、情報源、確認日も残すと、後から理由を追いやすくなります。評価元の違う点数を、条件を見ずに平均して使うのも適切ではありません。

高い点数と、自組織の緊急性は同じではない

例えば、深刻な脆弱性があっても、該当製品を使っていなければ、自組織のその製品への修正作業は発生しません。ただし、部品として組み込まれていないかまで確認する必要はあります。

逆に、点数が相対的に低くても、公開中の重要なサービスで実際の悪用が確認されていれば、対応を急ぐ理由になります。

また、外部非公開だから問題ないとも限りません。内部の端末やアカウントが侵害され、そこを起点に悪用される可能性があります。公開・非公開は重要な材料ですが、唯一の材料ではありません。

CVSSは自組織の被害確率ではありません。CVSSを無視するのではなく、共通の評価を出発点にしながら、自分たちの環境と現在の脅威を重ねる。この順序で理解すると、点数への過信を避けられます。

午後での問われ方

• 令和7年度春期 午後問2：公開サイトの脆弱性診断で検出された脆弱性を題材に、CVSSの深刻度レベルと対応の優先度が問われました。CVSSv3の評価項目のうち、攻撃条件の複雑さ（AC）の評価の根拠を答える設問があります。

• 平成30年度秋期 午後I問3：アプリケーションフレームワークの脆弱性を突いた攻撃への対応が題材でした。基本評価基準・現状評価基準・環境評価基準の三つで脆弱性の深刻さを評価する仕組みの名称として、「CVSS」が問われています。

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

• 令和7年度春期 午後問2では、CVSSv3の攻撃条件の複雑さ（AC）を問う設問の正答率が低く、多くの受験者が機密性への影響（C）と答えていたと指摘されています。

• 平成30年度秋期 午後I問3では、CVSSの名称を問う設問の正答率が低く、基礎的な知識として正確に覚えてほしいとされています。

• 令和元年度秋期 午後II問2では、CVSSを問う設問の正答率が低く、基本値・現状値・環境値の三つを正しく理解して、脆弱性対策に活用してほしいとされています。

記述の型

• CVSSの基本値だけで対応の順番を決めない理由：「自組織の環境や、実際の悪用の状況が反映されないから」

• 三つの評価基準：「基本値は脆弱性そのものの特性、現状値は攻撃コードの公開状況など時間とともに変わる要素、環境値は利用者の環境を反映する」

4. EPSSとKEVは、CVSSとは別の問いに答える

EPSS：今後30日間の悪用を予測する

EPSSは、公開されたCVEについて、今後30日以内に実環境で悪用される確率を予測するモデルです。FIRSTが公開しており、0から1の確率と、相対的な順位を表すパーセンタイルが提供されます。FIRST「EPSS」

例えば、説明用の値としてEPSSが0.20であれば、モデルによる予測は20％です。パーセンタイルが0.95であることを、95％の確率で悪用されると読むのは誤りです。後者は、対象群の中での相対的な位置を表します。

また、この20％は、自分たちの庁内システムが20％の確率で侵入されるという意味でもありません。モデルの対象は、その脆弱性の実環境での悪用です。自組織の接続条件、機能の有効性、既存対策などは別に確認します。

予測は更新されるため、取得日も重要です。一度取得した低い値を使い続け、新たな悪用情報を見落とす運用は避けます。

KEV：すでに悪用が確認されているものを把握する

KEV（Known Exploited Vulnerabilities）カタログは、米国CISAが公開する、悪用確認済みの脆弱性のカタログです。予測ではなく、実際の悪用に関する証拠に基づく情報として、対応の優先度を考える材料になります。CISA「Known Exploited Vulnerabilities Catalog」

ここで大切なのは、未掲載であることを、悪用されていない証明にしないことです。新しい情報の収集や確認には時間差があり、カタログ以外の製品ベンダーやCSIRTの情報も参照します。

また、KEVへの掲載は、自分たちの環境がすでに侵害された証拠ではありません。対象となる製品・版と攻撃条件を調べ、必要に応じて侵害の兆候も調査します。

米国の連邦機関向けに示される対応期限を、日本の自治体の一律の法的期限として扱うこともできません。自組織への適用関係と、参考にする脅威情報を区別します。CISAによる適用範囲の説明

3つの情報を、無理に1つの点数へまとめない

整理すると、CVSSは技術的な深刻度、EPSSは悪用の予測、KEVは確認された悪用を知る材料です。

例えば、EPSSが低くても、KEVやベンダーの通知で悪用を把握したなら、その事実を無視してよいわけではありません。予測値を、すでに分かっている事実より優先させないことが大切です。

すべてを独自の計算式に投入して最終点数だけを出すと、判断理由が見えなくなる場合があります。少なくとも、影響対象か、悪用状況はどうか、どこから到達できるか、何の業務が影響するかを説明できる状態を保ちます。

優先度の判断ルールを、前もって作る

脆弱性が公表されるたびに一から議論していては、対応が遅れます。指標と自組織の条件を組み合わせた判断ルールを、前もって決めておきます。例えば、次のような区分です（期限は組織の基準で決める）。

• 最優先：KEVに掲載されている、または提供元が悪用を報告している。かつ、インターネットから到達できる資産にある → 直ちに暫定対策を行い、修正を急ぐ

• 優先：CVSSの深刻度が緊急・重要で、対象の製品を使っている → 期限を決めて修正する。EPSSやKEVの変化を監視する

• 計画対応：それ以外で、対象の製品を使っている → 定期の保守で修正する

• 調査中：対象かどうか未確定 → 担当と回答期限を決める

ルールは、判断を速くするための出発点です。業務の重要性や、既存の緩和策によって区分を変える余地を残し、変えた理由を記録します。

午後での問われ方

• 令和7年度春期 午後問2（3.と同じ問題）：CVSSの現状値の代わりにEPSS値を使う方法が取り上げられました。手間の違いの理由として、解答例は、現状値は「攻撃コードなどの情報を多くの公開サイトにある情報から判断する必要があるから」、EPSS値は「FIRSTのサイトで公開されている値をそのまま使えばよいから」です。運用に追加する対策は「EPSS値の監視」です。

• 令和7年度春期 午後問4：IT資産管理と脆弱性管理が題材で、対策の優先度などを、CVSSの深刻度とKEVカタログへの掲載の有無に基づいて判断する方針が示されました。CVSSの最新のバージョン番号として「4.0」が、KEVカタログの正式名称（Known Exploited Vulnerabilities catalog）と、そこに載る脆弱性の性質が問われ、後者の解答例は「実際に悪用された」です。脆弱性管理の改善策として、「該当SWを保有する管理部門に対策の優先度を連絡し、対策実施を確認する」ことも示されています。

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

• 令和7年度春期 午後問2では、CVSSv3の現状値とEPSS値を比べて、手間の掛かる理由と掛からない理由を問う設問の正答率が低く、それぞれの利用手順を理解していない解答が散見されたと指摘されています。

• 令和7年度春期 午後問4では、KEVカタログを問う設問の正答率が低かったとされています。講評は、対応の優先度を考えるうえでは、脆弱性の技術的な特性、脆弱性を取り巻く現状、利用者の環境が重要で、KEVカタログは現状の評価に使われると説明しています。

記述の型

• EPSSを使う利点：「公開されている値をそのまま使え、評価の手間が少ない」

• EPSSの運用上の注意：「値が変動するので、継続的に監視する」

• KEVに掲載されている意味：「実際に悪用された」

• 優先度の理由：「悪用の事実（KEV）」「外部から到達できる」「影響する業務」の三点で書く

5. 資産を把握する：台帳・SBOM・ASM

資産台帳に、判断に必要な情報を持たせる

資産台帳は、機器の所在や管理者を把握するだけでなく、脆弱性情報と結び付けられることが重要です。

例えば、製品・ベンダー、バージョン・ビルド、稼働する環境、管理者、利用業務、公開範囲、保守先、サポート期限などを対応付けます。OSだけでなく、ファームウェアやミドルウェア、ライブラリも必要な範囲で把握します。

ただし、項目の多い台帳を作れば解決するわけではありません。更新作業後に台帳が古いままなら、脆弱性情報との照合を誤ります。構成変更を行った際に、実機・管理システムの情報と台帳を更新する手順まで必要です。

バージョンが古く見えても、修正済みの場合がある

OSの提供元などが、既存の版へセキュリティ修正を取り込むバックポートを行う場合があります。この場合、元の製品のバージョン表示だけを比べると、修正済みの環境を未修正と判断することがあります。Red Hat「Backporting Security Fixes」

逆に、最新版という名前だけで、対象の修正が入っていると決めつけることもできません。対象製品向けのアドバイザリ、パッケージの版、修正履歴などを確認します。

例えば、事業者から影響なしと言われた際には、使用していないのか、版が対象外なのか、修正が取り込まれているのか、成立条件を満たさないのかを分けて聞くと、根拠が明確になります。

SBOM・VEX：ソフトウェアの部品と、その影響

SBOMは、ソフトウェアを構成する部品や依存関係を示す一覧です。脆弱性が公表された部品が、システムに直接、または別のライブラリの依存先として含まれていないかをたどる材料になります。どの版の成果物の一覧かを確認し、部品の存在だけで悪用の成立は確定しないことに注意します。

VEXは、ある脆弱性について、製品が影響を受けるか（影響あり・影響なし・修正済み・調査中など）を伝える情報です。対象・版・状態・判断の根拠を示し、利用する側は発行元と更新時点を確認します。調査中は、影響なしではありません。CSAFは、こうしたセキュリティアドバイザリを機械可読形式でやり取りするための標準です。SBOMは部品、VEXは影響の説明、CSAFは情報の形式と、役割を分けて覚えます。SBOMの作り方と供給者の管理は支援士解説3の10で扱います。

ASM：攻撃者の目で、自組織の公開資産を探す

ASM（Attack Surface Management）は、インターネットからアクセスできる自組織のサーバや機器を、攻撃者の視点で探し出し、そこにある脆弱性を継続的に評価・管理する取組みです。台帳外の公開サービスや、残ったままの検証環境を見つける助けになります。

主な流れは、次の三つです。

1. 発見：WHOISや公開Webサイトから自組織が管理するドメイン名を特定し、DNSの検索などでIPアドレスとホスト名の一覧を作る

2. 情報収集：見つけた資産のOS、ソフトウェアとその版、開いているポートなどを、通常のアクセスの範囲で集める

3. リスク評価：集めた情報と、公開されている既知の脆弱性を照らし合わせる

インターネットを自分でスキャンする方法は、他社のデータセンターやクラウドの環境に負荷を与えるおそれがあり、時間もかかります。既に作られたデータベースを検索するサービスを使う方法もあります。

ASMは、公開情報から「脆弱性がありそう」と推定するもので、確度は高くありません。見つけた資産は、ポートスキャン、脆弱性スキャナー、脆弱性診断（支援士解説2の6）で詳しく確かめます。また、外から見える範囲だけでは、内部資産の全把握の代わりにはなりません。見つかった資産の所有者・管理責任を、内部の構成管理や契約の情報と照合します。ドメインが似ているだけで自組織の所有物と決めつけることも避けます。

台帳から漏れる資産と、使い終わった資産

事業部が独自に契約したクラウドサービスやレンタルサービス、他社のデータセンターに置いたサーバなど、情報システム部門を通さずに用意された資産は台帳に載りにくく、脆弱性の確認から漏れます。IT部門の許可を得ずに業務で使われる端末やクラウドサービスは、シャドーITと呼ばれます。

使い終わった資産を放置すると、脆弱性を残したまま改ざんされたり、残ったDNSの設定からサブドメインを乗っ取られたりします（DNSの設定の問題は支援士解説3の5）。使い続ける資産は、不要なサービス・機能・アカウントを止め、必要最小限の構成にします。これを要塞化（ハードニング）と呼びます。台帳は、予備機や復旧環境も対象にし、変更後も実際の状態と一致させます（図4）。

午後での問われ方

• 令和7年度春期 午後問4（4.と同じ問題）：未把握の公開IT資産を見つけて管理することが題材でした。登録漏れをなくす対象として「レンタルサービスを契約して利用した」「他社データセンターを契約して利用した」公開IT資産が、公開情報の調査に使う仕組みとして「WHOIS」が問われています。見つけた公開サーバは「ポートスキャンでWebのポートだけが開いていることを確認する」「脆弱性スキャナーを実行して、脆弱性の有無を確認する」とされ、その後の扱いは、利用を継続する場合「一旦、サービスを停止し、脆弱性を修正後に再開する」、継続しない場合「速やかにネットワークから切り離し、機器を廃棄する」です。運用の手順として、「情シ部がIT資産管理台帳にあるSWについて、重要な脆弱性情報が発表されていないかを継続的に確認する」ことも示されています。

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

• 令和7年度春期 午後問4では、利用を継続する場合と継続しない場合を取り違えて、反対に答えた解答が散見されたと指摘されています。長文を根気よく読み、慎重に答えることが求められています。

記述の型

• 台帳の登録漏れを防ぐ対象：「事業部が契約したクラウドサービス、レンタルサービス、他社データセンターの公開IT資産」

• 見つけた公開サーバの確認：「ポートスキャンで開いているポートを確認し、脆弱性スキャナーで脆弱性の有無を確認する」

• 古い公開サーバの扱い：「継続するなら一旦停止し、脆弱性を修正後に再開する。継続しないなら速やかにネットワークから切り離し、廃棄する」

6. 架空の3案件で、対応の順番を考える

最初の問いは、どれが一番高い点数かではない

次の3つの情報が届いた、架空のケースを考えます。製品名や脆弱性番号は実在のものではなく、判断の練習用です。

【A：公開中のファイル受渡しサービス】

• 対象バージョンを使用しており、問題の機能は有効。

• インターネットから、認証前の入口へ到達できる。

• ベンダーが実際の悪用を報告している。

• 修正版はある。更新には短時間の停止が必要。

【B：庁内の帳票作成サーバ】

• 対象バージョンを使用している。

• CVSSの基本値はAより高いが、悪用には特定の権限が必要。

• 接続元は限定され、外部からは直接到達しない。

• 月末処理との互換性を確認してから更新する必要がある。

【C：同じ部品を使っているかもしれない委託システム】

• 構成情報が不足しており、対象かどうか未確定。

• 提供元へ問い合わせ中。

• 公開範囲と問題の機能の利用状況も確認中。

この条件なら、Aは初動を急ぐ理由が明確です。悪用の事実、到達可能性、影響対象であることがそろっているからです。保守日を待つだけでなく、更新や暫定措置、侵害の兆候の確認を具体化します。

図5の言葉で言えば、Aは「対象・機能有効」「認証前に到達可能」「悪用の報告あり」がそろうので、更新・暫定措置を急ぎます。Bは悪用に特定権限が必要なので、業務への影響を検証し、更新期限を決めます。Cは構成が未確定なので、提供元に確認しながら、担当と回答期限を設定し、必要な当面措置を検討します。

Aを優先しても、Bを放置してよいわけではない

BはAと比べて攻撃条件が限られますが、内部のアカウント侵害を起点に悪用される可能性は残ります。業務の重要性や権限の配布状況によっては、Bも非常に高い優先度になる場合があります。

ここでは、Aの緊急対応を進めながら、Bの更新計画、検証内容、期限を決めるという判断が考えられます。実際の順位は、追加情報や業務影響によって見直します。

問題文にない攻撃条件や、絶対に安全という前提を足さないことも、選択肢を読むうえで大切です。内部という言葉だけで、攻撃できないと読み替えないようにします。

Cの未確定を、一覧の外へ追い出さない

Cは、調査中として担当者と回答期限を設定します。情報が足りないから低リスク、とは判断できません。

例えば、公開サービスで影響の可能性が高いなら、対象の確定を待つ間に、機能の利用停止が可能か、ログをどこまで確認できるかを調べます。ただし、根拠なくすべてのサービスを止めればよいという意味ではありません。不確実性と停止の影響を含めて、判断者へ伝えます。

調査期限を設けることで、回答待ちのまま案件が消えることを防げます。委託先がさらに別の提供元へ確認している場合にも、自分たちの担当者と次の確認時点は残します。

優先順位を、作業と期限へ変換する

高・中・低のラベルだけでは、誰が何をするのかが分かりません。優先順位を決めたら、今日の措置・修正予定・確認方法へ具体化します。

• 今日行うこと：公開範囲の制限、ベンダーへの確認、ログの保全など。

• 更新前に行うこと：検証、停止の調整、バックアップ、切戻し準備など。

• 更新時に行うこと：対象への適用、必要な再起動、動作確認など。

• 更新後に行うこと：残存対象の確認、暫定措置の整理、記録の更新など。

期限は、脅威の緊急性と実施可能性を踏まえ、組織の基準と権限に従って設定します。本稿の事例は判断の考え方を示すものであり、すべての自治体に共通する日数を定めるものではありません。

記述の型

• 優先度を上げる理由：「実際に悪用されており、インターネットから認証前に到達できる」

• 点数が高くても急がない理由：「悪用に特定の権限が必要で、外部から直接到達しない」（ただし期限を決めて対応する）

• 対象が未確定の案件：「担当者と回答期限を決め、調査中として管理する」

7. すぐに修正できないとき：攻撃の条件を崩す暫定対策

修正版がないことと、何もできないことは違う

脆弱性への根本的な対応として、パッチや修正版の適用が必要になる場合があります。ただし、公表時点では修正版がないことも、互換性の確認が必要なこともあります。

その間に検討するのが、回避策や緩和策です。例えば、問題の機能を無効にする、接続元を限定する、不要な公開を止める、特定の経路を遮断する、といった方法です。

重要なのは、実際の攻撃条件に効くかを確認することです。認証前に悪用される脆弱性に対し、利用者のパスワードだけを変更しても、問題の入口が残る可能性があります。

WAFやIPSのルールを追加する対策も、検査できる通信、ルールの対象、迂回経路、誤検知の影響などに左右されます。仮想パッチと呼ばれる保護でも、ソフトウェア自体の欠陥を修正したこととは分けて管理します。

攻撃の条件を読み、それを崩す対策を選ぶ

暫定対策は、脆弱性情報から攻撃が成立する条件を読み取り、その条件を崩すものを選びます（図6）。

• どこから届くか：インターネットから直接届くなら、公開の一時停止や接続元の限定が効く。社内からしか届かないなら、外部の遮断だけでは足りない

• 認証の前か後か：ログインする前に悪用できるなら、利用者のパスワードを変えても入口はふさがらない

• 利用者の操作が必要か：ファイルを開く、Webページを見る、といった操作で成立するなら、接続元の限定は効かない。その形式のファイルの受信を止める、該当する機能を無効にする

• どの機能が対象か：その機能を止めても業務が回るか。止めた機能を、誰が、いつ戻せるか

• 攻撃に必要な通信は何か：攻撃の途中で外部への通信が必要なら、その通信を遮断すると成立しないことがある

接続元の限定は、許可した接続元や、すでに侵害された社内の端末からの攻撃は防げません。WAFやIPSで攻撃の通信を遮断する仮想パッチも、検査できない通信や迂回経路があれば効かず、ソフトウェアの欠陥そのものは直りません。

ゼロデイでも、既知の脆弱性でも、残る条件を見る

ゼロデイ攻撃の典型は、提供元の修正プログラムが公開される前に、脆弱性を悪用する攻撃です。脆弱性の存在を知ってから、誰も何もできない時間が固定であるという意味ではありません。

未知の問題を完全に予測することはできなくても、不要な機能の停止、最小権限、ネットワーク分割、監視などは、攻撃が成立する条件や影響の軽減に役立ちます。

一方、修正版が公開された後も、適用されなければ弱点が残る場合があります。ゼロデイという名前だけに注目して、既知の脆弱性の対応を後回しにしないことが重要です。

仮想パッチを使うときの確認

WAFやIPSに、その脆弱性を突く通信を遮断するルールを追加する方法は、修正までの時間を稼ぐのに役立ちます。使うときは、次を確かめます。

• 検査できるか：HTTPSの通信は、WAFで復号できなければ中身を検査できない。クラウド型のWAFなら、DNSの設定を変えて通信をWAFへ向ける必要がある

• 迂回されないか：WAFを通らずに、サーバへ直接届く経路が残っていないか

• 誤検知の影響：正常な通信を遮断して業務が止まらないか。まず検知だけで動かし、影響を見てから遮断に切り替える方法もある

• 状態の管理：ソフトウェアは直っていないので、「修正済み」ではなく「緩和済み」として、修正の予定と合わせて管理する

暫定対策には、期限と解除条件を付ける

例えば、問題の機能を止めて影響を抑えたとしても、翌月に業務担当者が必要になって再度有効にすれば、条件が戻ってしまいます。

何を止めたか、理由、責任者、業務影響、恒久対策の予定、解除してよい条件を記録します。次の保守で修正版を適用した後にも、暫定措置を解除してよいか、別の目的で残すべきかを判断します。

案件の状態も、修正済み、緩和済み、調査中、延期承認済みなどを区別します。全部を対応済みと一つにまとめると、ソフトウェアの弱点が残っている対象を見失います。

先送りするなら、残るリスクを誰が判断するか

停止の影響が大きい場合でも、更新しない判断には責任が伴います。技術担当者だけで業務上の損失を決めたり、業務担当者だけで攻撃の成立条件を判断したりするのは困難な判断です。

担当者は、影響対象、悪用状況、取り得る措置、停止した場合の影響、先送りした場合のリスク、次の見直し期限を整理します。そのうえで、組織の権限に従って承認を得ます。

承認があるからリスクが消えるわけではありません。悪用の拡大や暫定措置の不十分さが分かったら、期限前でも再判断します。

午後での問われ方

• 令和4年度秋期 午後I問2：Javaのログ出力ライブラリの脆弱性を悪用されたインシデントが題材でした。会員サーバへの攻撃が失敗したのは、攻撃者がログイン用の利用者IDとパスワードを知らなかったからだ、という見方に対し、そうではない理由として解答例は「ログ出力処理する文字列中に攻撃文字列が含まれれば悪用可能だから」（認証の前でも悪用できる）です。攻撃が失敗した本当の理由は「会員サーバからインターネット宛てのLDAP通信が許可されていないから」で、攻撃に必要な外部への通信を、ファイアウォールが止めていたことになります。

• 平成30年度秋期 午後I問3（3.と同じ問題）：被害の拡大を防ぐ措置として「Eサーバをネットワークから切り離して、待機サーバを公開する」が示されています。WAFの導入の検討では、ハードウェア型のWAFに必要な機能として「インターネットからのHTTPS通信を復号する機能」が問われました。クラウド型のWAFを使う場合は、Eサーバへのアクセスの経路をWAF経由に変えるために「外部DNSサーバ」の設定を変え、WAFのIPアドレスが変わっても影響が出ないように「CNAME」レコードで別名を定義します。

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

• 令和4年度秋期 午後I問2では、報告されている脆弱性情報から、実際のシステムで影響を受ける条件を把握する設問の正答率が低く、影響を評価する手法について理解を深めてほしいとされています。

• 平成30年度秋期 午後I問3では、クラウド型WAFサービスを使ううえでの留意点を問う設問の正答率が低かったとされています。

記述の型

• 暫定対策の例：「脆弱性のある機能を無効にする」「接続元を限定する」「公開を一時的に停止する」

• 認証前に悪用される脆弱性：「パスワードの変更では、攻撃の入口はふさがらない」

• 回避策の注意点：「ソフトウェアの脆弱性そのものは修正されていない」

• 暫定対策の管理：「期限と解除の条件を決め、恒久対策の予定と合わせて記録する」

8. パッチは、配布した後の確認までが仕事

適用前：対象と変更内容を確かめる

パッチは、不具合などを修正するための更新です。脆弱性対応では、対象の版、前提となる更新、適用順序、再起動やサービス再起動の要否を確認します。

同じ名称の製品でも、OSや構成が異なれば更新の手順が違う場合があります。インターネットで見つけたファイルを、そのまま本番へ適用するのではなく、正規の提供元と対象を確認します。署名など、提供元が示す真正性・完全性の確認方法も利用します。

ハッシュ値だけを確認する場合には、その基準値をどこから得たかも重要です。更新ファイルと基準値が同じ不正サイトに置かれていれば、一致しただけでは正規のものと判断できません。

テストは、修正確認と回帰テストを分ける

修正確認は、対象の弱点への対処が有効か、つまり弱点が解消・軽減されたことを確かめる作業です。ベンダーの方法、適用状態、関連設定などを確認し、必要に応じて許可された範囲で再診断します。

回帰テストは、変更によって既存機能が壊れていないか、既存業務への影響を確認するテストです。リグレッションテストとも呼びます。脆弱性への対処と、既存業務が動くことの両方を確かめます。

例えば、ファイル受渡しサービスを更新したら、アップロード画面が開くことだけでは足りません。受付、権限別の参照、職員のダウンロード、通知、外部システムとの連携、監査ログなど、変更の影響を受ける重要な処理を選んで確認します。

脆弱性診断で指摘が消えたから業務も正常、業務画面が動いたから脆弱性も修正済み、と読み替えないようにします。診断だけ、画面表示だけで確認を終えません。

テスト環境の差を、判断に含める

本番と検証環境で、版、設定、認証基盤、データ量、外部接続先が大きく異なると、確認結果をそのまま本番に当てはめられません。

完全に同じ環境を用意できない場合でも、差異を記録し、何を確認でき、何が残るかを整理します。本番の個人情報を安易に複製するのではなく、必要な条件を満たすテストデータと安全な環境を準備します。

緊急性が高いときには、確認項目を危険度に応じて絞り、先行適用や適用後監視を組み合わせる判断もあります。ただし、テストを短縮したことと、問題がないと確認できたことは別です。省略した範囲と理由を残します。

バックアップと切戻しは、実際に戻せる条件で用意する

更新で業務が動かなくなった場合に備え、停止調整、データと構成の保全、切戻し手順、判断者、必要時間を確認します。

ソフトウェアだけ旧版に戻しても、更新時に変更したデータベース形式と合わなくなることがあります。また、更新後に受け付けたデータをどう扱うかも問題になります。戻す対象と、失われる・再処理が必要なデータまで考えます。

そして、脆弱性を修正した更新から旧版へ戻れば、弱点が再び残ることがあります。切戻しが成功したので安全、とは言えません。暫定対策を併せて戻す・追加する必要があるかを評価します。

適用中：全台一斉か、段階的かを選ぶ

対象が多い場合は、代表的な端末や一部のサーバへ先行適用し、その結果を見て広げる方法があります。段階的に実施すると、不具合の影響を抑えられる場合があります。

一方で、段階適用に時間をかけるほど、未修正の対象が残る期間（未修正期間）も長くなります。外部で悪用が進んでいる場合などは、先行検証を短くし、公開制限を併用するなど、状況に応じた判断が必要です。

冗長構成では片系ずつ更新できる場合もありますが、製品が異なる版の混在を許容するか、切替え時に状態が同期するかを確認します。2台あるから無停止更新できるとは限りません。

適用後：配信成功と、修正の有効化を区別する

管理ツールに配布済みと表示されても、端末が受け取っただけ、インストールは完了したが再起動待ち、といった状態があり得ます。

対象の版、適用結果、必要な再起動、実際に動いているプロセスやコンテナなどを確認します。コンテナイメージを更新しても、古いイメージから起動した実行中の環境が残っている場合には、その状態も見ます。

適用時には、配布・インストール・有効化の状態を分けて確かめます。長期間オフラインの端末、予備機、災害時用の環境、バックアップから復元する旧イメージも取り残しになり得ます。全体確認では、これらを探し、旧イメージや復旧手順も見直します。今日の稼働系だけでなく、次に起動するものまで管理対象として考えます。

適用の期限を決め、守られているかを確かめる

脆弱性が公表されると、修正プログラムが出た後も、まだ適用していない機器を狙う攻撃が広がります。そこで、適用の期限を決め、守られているかを確かめ、守られていない端末を接続させない仕組みまでそろえます。

• 修正プログラムのリリースから、決めた期限内に適用する。端末の種類ごとに期限を変えることもある

• 担当者が、ルールが守られているかを定期的に確認する

• 社内ネットワークやリモートアクセスへの接続時に、OSの版、修正プログラムの適用状況、マルウェア定義ファイルの版を確かめ、条件を満たさない端末の接続を拒否する。接続しようとする端末の状態を確かめ、条件を満たさない端末を隔離したり接続させなかったりする仕組みは、一般に検疫ネットワークと呼ばれる

完了の証拠を、次の担当者が読める形にする

例えば、対象一覧、変更前後の版、実施日時、作業者、テスト結果、未適用の対象と理由、暫定措置の状態を記録します。

脆弱性一件につき対象が100台あれば、1台直ったことと全体の完了は違います。母数と残数を合わせ、例外の期限と管理者を残します。完了という状態を、感覚ではなく根拠で説明できることが重要です。

午後での問われ方

• 令和7年度秋期 午後問3：リモートワーク環境の導入が題材でした。社有PCは、脆弱性修正プログラムがリリースされたら「2週間以内」に適用し、各部の情報セキュリティ推進者が毎月確認する規程でした（社有スマホなどは1週間以内）。導入するVPNサービスは、接続時に接続元PCのOSの版、修正プログラムの適用状況、マルウェア定義ファイルの版を確かめて接続の可否を判定でき、規程を満たさないPCからの接続を拒否する設定にしています。古い版のOSを使い続けるPCへの対応として、解答例は「Kサービス接続時のログからOSがバージョンXの社有PCを抽出し、アカウント名から利用者を特定後、利用者の所属する部の情報セキュリティ推進者に報告し、バージョンYへの移行を促してもらう」です。

• 令和元年度秋期 午後II問2：ITとOTが混在する工場のセキュリティ対策が題材でした。脆弱性への対策として、解答例には「当該脆弱性に対応したパッチを適用する」と「脆弱性をもつソフトウェアの利用を停止する」の二つが示されています。

記述の型

• 適用前の確認：「検証環境で、既存の機能に影響がないか（回帰テスト）を確認する」

• 切戻しの注意点：「修正した脆弱性が再び残る」

• 適用状況の確認：「全ての対象で、修正が有効になったか（再起動の有無を含む）を確認する」

• 適用ルールを守らせる仕組み：「接続時に修正プログラムの適用状況を確認し、条件を満たさない端末の接続を拒否する」

9. SCAPは、確認の方法を共通化する

個別の画面確認を、機械で扱える形にする

同じ設定を何百台も確認するとき、担当者が1台ずつ画面を開く運用では、確認漏れや結果のばらつきが生じやすくなります。

SCAPは、セキュリティに関する検査や評価を自動化するための共通仕様群です。製品や設定の識別、チェック内容、検査方法、結果の表現などを共通化して扱います。NIST「Security Content Automation Protocol」

1つの検査ソフトの名前ではありません。また、構成仕様は版によって異なるため、常に特定の仕様だけで構成されていると固定して覚えるのではなく、まず何を共通化するのかを理解します。

関連する名前の役割を分ける

• CPE：製品・プラットフォームを共通の形式で識別する。

• CCE：セキュリティ設定に関する事項を共通の識別子で扱う。

• XCCDF：設定チェックリストや評価ルールなどを記述する。

• OVAL：システムの状態を検査・評価するための内容を表現する。

教科書では、SCAPを構成する仕様として、これにCVE（脆弱性の識別）とCVSS（深刻度の評価）を加えた六つ（CVE・CCE・CPE・CVSS・XCCDF・OVAL）が挙げられています。午前IIでは、この六つで覚えておきます。ただし、CWEは弱点の種類、CCEは設定に関する識別であり、似た略語でも対象が異なります。

また、CCEの番号があれば、それだけで自組織が採用すべき設定値まで決まるわけではありません。識別することと、組織の基準を決めることは別です。

例えば、ある設定項目を共通の識別子で扱い、チェックリストで満たすべき状態を定め、検査内容に従って実際の状態を収集する、という流れで考えます。

検査できなかった結果を、合格に変えない

自動検査では、権限不足、接続失敗、対象外のOS、古い検査定義などによって、必要な状態を確認できない場合があります。

不適合が出ていないことと、必要な項目が全部適合したことは同じではありません。対象外、エラー、未評価を分け、どこまで確認できた結果なのかを読みます。

例えば、管理者権限を必要とする項目を、権限のないアカウントで検査していたら、重要な確認が抜ける可能性があります。自動化の仕組みも、内容と実行条件を管理して初めて役立ちます。

未知の脆弱性や複雑な業務ロジックの欠陥まで、SCAPを使うだけですべて検出できるわけではありません。診断、レビュー、脅威情報、構成管理と組み合わせて使います。

10. 脆弱性の報告を受ける側として

自組織が公開するWebサービスや製品について、外部から脆弱性の報告が届くこともあります。発見・報告を受けてから、内容の確認、関係者との調整、修正、情報の公開へ進める一連の取扱いを、脆弱性ハンドリングと呼びます。

• 受付の窓口と、内部の連絡先を決めておく。報告内容には攻撃につながる情報が含まれるので、関係者だけで扱う

• 再現の確認は、許可と安全な条件のもとで、必要最小限の情報で行う。報告者に、個人情報を大量に取得して証明するよう求めない

• 詳細の公開は、修正の状況と利用者への影響を見て、時期を調整する。国内には、情報セキュリティ早期警戒パートナーシップの仕組みがある。ソフトウェア製品の脆弱性は、IPAが届出を受け、JPCERT/CCが製品開発者と調整する。Webサイトの脆弱性は、IPAが届出を受けてサイトの運営者に通知する

• バグバウンティは、定めた条件に合う脆弱性の発見・報告に報奨金などを提供する取組み。対象、許可する検証、禁止する行為、公表の扱いを明示する。報奨制度があるから、どんな検証をしても許されるわけではない

• 製品の脆弱性に対応するチームをPSIRT、組織のインシデントに対応するチームをCSIRTと呼ぶ（体制は支援士解説4の1）

記述の型

• 報告を受けたときの再現確認：「許可された範囲で、必要最小限の情報を使って確認する」

• 詳細の公開時期：「修正の状況と利用者への影響を踏まえ、関係者と調整して決める」

11. ソフトウェアの導入とサポート期限も管理する

自由に入れたソフトは、更新の対象から漏れやすい

利用者が必要なソフトウェアを導入できることと、導入したものを組織で管理できることは別です。

例えば、職員が一時的な作業用に入れたツールを管理部門が把握していなければ、そのツールの脆弱性が公表されても対象を特定できません。ブラウザの拡張機能や、利用者権限で動くツールも、業務上の必要性と管理方法を確認します。

承認された配布経路、導入申請、管理者権限の制限、更新責任、不要になった際の削除などを規程と運用に含めます。禁止するだけで業務が進まないなら、正規の申請・審査を通じて必要なものを使える経路も用意します。

サポート終了は、更新計画の問題でもある

サポートが終わると、今後見つかった問題に対する修正が提供されなくなる場合があります。今日、既知の脆弱性をすべて直したつもりでも、その後の対応能力が失われることがあります。

そのため、サポート期限は、期限が来た日に確認するのでは遅い場合があります。後継製品の選定、予算、調達、移行、データ変換、業務テストなどに時間がかかるためです。

例外的に使い続ける判断が必要になったとしても、孤立化や接続制限だけで永続的に安全とはしません。残るリスク、管理者、監視、終了期限を具体化し、適用する規程に照らして判断します。

クラウドでも、すべてを提供元に任せられるとは限らない

クラウドサービスでは、基盤の更新を提供元が担う場合があります。一方、利用者側で管理するOS、アプリケーション、コンテナ、連携設定などが残る構成もあります。

どの層を誰が更新するか、重大な脆弱性の通知を誰が受けるか、影響の回答をいつ得るか、適用の証拠をどう確認するかを契約や運用で整理します。

ベンダーがクラウドを使っていると説明しただけで、自治体側の確認が不要になるわけではありません。サービスの利用形態と契約の責任分担に即して確認します。

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

• 「CVEは、脆弱性の深刻度を0.0〜10.0で表す」→ 誤り。CVEは識別子。深刻度はCVSS

• 「CWEは、ソフトウェアの弱点の種類を分類したもの」→ 正しい

• 「CVSS v3の基本値は、利用者の環境によって変わる」→ 誤り。環境によって変わるのは環境値。基本値は脆弱性そのものの特性

• 「CVSSの現状値は、攻撃コードの公開状況などによって、時間とともに変わる」→ 正しい

• 「CVSS 4.0の補足評価（Supplemental）は、スコアを引き上げる」→ 誤り。スコアそのものは変えない

• 「EPSSのパーセンタイルが0.95なら、95%の確率で悪用される」→ 誤り。全体の中での相対的な順位

• 「KEVに掲載されていない脆弱性は、悪用されていない」→ 誤り。掲載には時間差がある

• 「ゼロデイ攻撃は、修正プログラムが提供される前に脆弱性を悪用する攻撃である」→ 正しい

• 「SCAPは、脆弱性の検査や設定の確認を自動化するための共通仕様群である」→ 正しい

• 「回帰テストは、修正した脆弱性が解消されたかを確かめるテストである」→ 誤り。変更によって既存の機能が壊れていないかを確かめる

• 「仮想パッチを適用すれば、ソフトウェアの脆弱性は修正済みとして扱える」→ 誤り。欠陥そのものは残る

• 「ASMは、外部から見える自組織の資産を、攻撃者の視点で把握する取組みである」→ 正しい

理解度チェック

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

問1　EPSSの読み方

ある脆弱性のEPSSの確率が0.20、パーセンタイルが0.95だった。最も適切な読み方はどれか。

• ア：自組織のシステムが、20%の確率で侵入される

• イ：95%の確率で悪用される

• ウ：今後30日以内に、その脆弱性が実環境で悪用される確率の予測が20%で、全体の中では上位5%に入る

• エ：CVSSの基本値が2.0である

正解：ウ。EPSSは、その脆弱性が世の中で悪用される確率の予測です。自組織の侵入確率ではなく（ア）、パーセンタイルは相対的な順位です（イ）。

問2　対応の優先度

同時に二つの脆弱性が報告された。Aは社内LANの業務サーバの製品で、CVSS 9.8、KEVへの掲載はない。Bはインターネットに公開しているVPN装置で、CVSS 7.5、KEVに掲載されている。最も適切な判断はどれか。

• ア：CVSSが高いAを先に対応し、Bは次の定期保守で対応する

• イ：悪用が確認され、外部から到達できるBを先に対応し、Aも計画を立てて対応する

• ウ：Bは点数が7.5なので、対応しない

• エ：どちらもKEVの対応期限が来るまで待つ

正解：イ。悪用の事実と到達可能性がそろうBを急ぎます。Aを放置してよいわけではなく、計画を立て、EPSSやKEVの変化も監視します。

問3　暫定対策

インターネットに公開しているサーバに、ログインの前に悪用できる脆弱性が公表された。修正プログラムはまだない。最も適切な暫定対策はどれか。

• ア：利用者全員のパスワードを変更する

• イ：脆弱性のある機能を無効にするか、公開を一時停止して接続元を限定する

• ウ：CVSSの点数が下がるまで待つ

• エ：サーバのログの保存期間を延ばす

正解：イ。ログインの前に悪用できるので、パスワードを変えても入口はふさがりません（ア）。攻撃が成立する条件を崩す対策を選び、期限と解除の条件を付けて管理します。

問4　パッチ適用後の確認

管理ツールで、全端末への修正プログラムの配布が「配布済み」と表示された。完了と判断する前に確かめることとして、最も適切なものはどれか。

• ア：特に確認せず、完了として記録する

• イ：配布済みと表示されたので、再起動待ちの端末も修正済みとみなす

• ウ：インストールの完了、必要な再起動、修正後の版を確かめ、電源が入っていない端末や予備機などの取り残しと、その理由を確認する

• エ：脆弱性診断の指摘が消えたので、業務の動作確認は省く

正解：ウ。配布できたことと、修正が有効になったことは違います。エは修正の確認と回帰テストを混同しています。

問5　見つかった古い公開サーバ

ASMで、台帳に載っていない古い公開サーバが見つかった。業務では使っておらず、今後も使う予定はない。最も適切な対応はどれか。

• ア：一旦サービスを停止し、脆弱性を修正してから再開する

• イ：台帳に登録だけして、そのまま公開を続ける

• ウ：速やかにネットワークから切り離し、機器を廃棄する

• エ：次のASMの実施まで様子を見る

正解：ウ。使い続けないなら、切り離して廃棄します。アは利用を継続する場合の対応で、二つを取り違えないようにします。

実務と国・自治体では

実務では、仕様書に「セキュリティパッチを適用すること」と書くだけでは、情報が出てから適用するまでの判断が残ります。どの製品・部品の情報を誰が確認するか、影響の有無をどの構成情報で回答するか、定期保守を待てない緊急時の連絡先と権限、暫定対策の実施と解除を誰が判断するか、修正の確認と業務の動作確認の分担を、保守契約で決めておきます。判断者には、CVEの番号と点数だけでなく、「今夜更新すれば手続が1時間止まる」「延期すれば外部から悪用される条件が残る」のように、業務上の選択肢として示します。

政府機関等の統一基準は、導入時と運用中の脆弱性対策、対策の状況の定期的な確認、システムへの影響を考慮した計画的な措置を求めています。自治体向けのガイドラインも、変更履歴の管理や、更新時の他システムとの整合、サポート終了への対応を例文で示しています。資料の位置付けは支援士解説1の1で整理しています。

まとめ

• 脆弱性対応は、資産の把握から始まる。 台帳・構成・公開範囲が分からなければ、影響を判断できない。ASMで台帳の外を探し、使い終わった資産は片付ける。

• CVSSは深刻度、EPSSは悪用の予測、KEVは悪用の事実。 答える問いが違う。事実を予測より優先し、最後は自組織の配置と業務に照らす。

• すぐに直せないときは、攻撃の条件を崩す暫定対策を。 どこから届くか、認証の前か後か、利用者の操作が要るか。期限と解除条件を付け、修正済みとは分けて管理する。

• パッチは確認までが仕事。 回帰テスト、切戻し、再起動、取り残し、そして期限を守らせる仕組み。

関連記事

• 次に読む：委託すれば、任せて安心？｜支援士解説3の10（SBOM・サプライチェーン）

• あわせて読む：脆弱性検出ゼロなら、安全と言えるのか｜支援士解説2の6（脆弱性診断）

• あわせて読む：保守を委託すれば、安全は続くのか｜支援士解説2の7（保守の委託と更新）

• あわせて読む：インシデントから復旧したら、もう安全？｜支援士解説4の3（侵害の疑いがあるとき）

2026年10月改訂：午後の出題例と記述の型を加え、CVSSの評価項目、ASMと資産の把握、攻撃の条件から選ぶ暫定対策、パッチの適用ルールの節を補い、SBOM・VEXと届出制度の詳細は関連する回へ移して、構成を見直しました。