情報処理安全確保支援士（SC）試験の勉強を進めていくと、テキストのあちこちで「JVN」「CVSS」「情報セキュリティ早期警戒パートナーシップ」といった用語に出会います。午前IIの用語問題としては暗記できても、午後の長文記述になると「なぜその対策が正解になるのか」が論理的に説明できず、手が止まってしまう。そんな声をよく耳にします。
筆者はかつて事業会社のCIO（最高情報責任者）として、限られた予算のなかでWebサーバーをどう守るかという判断を迫られた経験があります。理想の製品を導入できない制約のなかで「今あるカードで何とか時間を稼ぐ」という現場の思考は、まさにこれから解説する「回避策（ワークアラウンド）」そのものでした。SC試験の午後問題が問うているのは、この現場のトレードオフを言語化できるかどうかです。
本記事で学べること（学習目標）は次の3点です。
- JVNの役割と、午前IIで確実に得点したい「情報セキュリティ早期警戒パートナーシップ」の仕組み（IPAとJPCERT/CCの役割分担）
- JVNレポートを読むときに真っ先に見るべき「概要・影響・対策」の3項目と、CVSSによる深刻度評価の考え方
- 午後の記述問題で合否を分ける「解決策（根本対策）」と「回避策（ワークアラウンド）」の決定的な違い
専門用語を辞書的な丸暗記で終わらせず、午後の長文を読み解く武器へと変えていきましょう。
そもそもJVNとは何か｜日本の脆弱性情報のハブと公的な枠組み
脆弱性という言葉はニュースで日常的に耳にしますが、その情報が「誰によって、どのように管理され、どうやって手元に届くのか」を意識したことはあるでしょうか。まずは日本国内の脆弱性ハンドリングの中心である「JVN」と、その背後にある公的な枠組みを整理します。
JVNは「公式な脆弱性お知らせサイト」
JVN（Japan Vulnerability Notes）は、一言で言えば「日本国内で使われているソフトウェアの弱点（脆弱性）と、その対策情報を公表する公式なポータルサイト」です。OSやミドルウェア、ネットワーク機器のファームウェア、国産のグループウェアや業務パッケージに至るまで、人間がプログラムを書いている以上、そこには必ずバグや設計上の見落とし（脆弱性）が潜んでいます。
たとえば「細工したパケットを送りつけるだけでサーバーが再起動しサービスが止まる（可用性の侵害）」「入力フォームに特殊な文字列を打ち込むと認証をバイパスしてデータベースの機密情報を抜き取られる（機密性の侵害）」といった弱点です。JVNは、こうした弱点のうち社会的な影響が大きいものについて、影響範囲や修正プログラムの適用をシステム管理者やユーザーに促す、重要な情報インフラとして機能しています。
JVNは2004年から運用されており、IPAとJPCERT/CCが共同で運営しています。テキストの文字面だけで「JVN＝脆弱性ポータル」と暗記するのではなく、一度JVNの実際のサイトにアクセスし、自分が毎日使っているアプリやOSの名前で検索してみてください。日々おびただしい数の脆弱性が公表されている現実を肌で感じることが、セキュリティを学ぶ出発点になります。
なお、JVNには公表情報のポータルとは別に、脆弱性対策情報を蓄積したデータベース「JVN iPedia」もあります。CVSSスコアやCVE番号、CPE（製品識別子）で検索でき、海外製ソフトの情報に加えて国産製品の脆弱性も日本語で確認できる点が、日本の管理者にとっての大きな利点です。
試験頻出「情報セキュリティ早期警戒パートナーシップ」
午前II（および午後の状況説明の理解）でJVNとセットで問われるのが「情報セキュリティ早期警戒パートナーシップ」という枠組みです。これは、民間の研究者や企業がソフトウェアの脆弱性を発見したとき、悪用される前に安全かつ円滑に修正・公表するための、日本の官民連携の仕組みです。「ソフトウエア製品等の脆弱性関連情報に関する取扱規程」（経済産業省告示）を踏まえて運用されています。
もし、誰も気づいていない有名アプリの致命的な欠陥を発見したとして、承認欲求から自身のSNSやブログでいきなり「このソフトに大穴があります」と公開してしまったらどうなるでしょうか。ベンダー（製品開発者）が修正プログラムを用意する間もなく、攻撃者がその情報を悪用し、無防備なシステムを一斉に攻撃する「ゼロデイ攻撃」の引き金を引くことになります。
こうした事態を防ぐため、発見された脆弱性情報はまず公的な受付窓口に「非公開の状態」で届け出られ、関係機関が水面下でベンダーと連絡を取り合います。そして、ベンダーが修正プログラム（パッチ）を用意し、ユーザーが安全に対策を打てる準備が整った段階で、初めてJVNを通じて広く一般公開されます。試験では、この「未公開の脆弱性を安全に扱い、ゼロデイ攻撃を防ぐ」というプロセスの目的そのものが問われます。
IPAとJPCERT/CCの役割分担を正確に押さえる
この枠組みで学び始めの人が最も混乱し、かつ試験で最も狙われるのが、登場する2つの公的組織の役割分担です。その2つとは、IPA（独立行政法人情報処理推進機構）とJPCERT/CC（一般社団法人JPCERTコーディネーションセンター）です。
実務のフローに沿って整理すれば、境界線は明確です。
- IPA（情報処理推進機構）は「受付機関」 脆弱性の発見者からの届出を受け付ける窓口であり、情報の管理・集計を担います。国内の脆弱性報告が最初に集まる「総合受付カウンター」だとイメージしてください。
- JPCERT/CCは「調整機関」 IPAから通知を受けた脆弱性について、影響を受ける製品開発者（ベンダー）との間で、修正パッチの作成スケジュールや公表日の「調整（コーディネーション）」を担う実務部隊です。国内外のセキュリティ機関とも連携します。
ベンダーによる修正の準備が完了すると、IPAとJPCERT/CCが共同運営するJVN上に対策情報が公開されます。
午前IIでこのテーマが出たら、問題文のキーワードを冷静に拾ってください。「届出の受付」とあれば答えはIPA、「製品開発者との調整」とあれば答えはJPCERT/CCです。この切り分けは高度試験系で繰り返し問われる定番であり、確実に得点したいポイントです。似た名前の組織（NISCやJIPDECなど）を選択肢に並べる引っかけも定番なので、役割で判別する癖をつけておきましょう。
JVNレポートで真っ先に見る「3つの重要項目」とCVSS
実際のJVNのページを開くと、CVE-IDやCWE分類、CVSSのベクトル文字列などが並び、どこを見ればよいか迷いがちです。しかし、リスクの全体像を短時間でつかむために見るべき項目は、実質3つです。この3点を素早く抽出する訓練が、午後の長文から必要な事実を拾う速読力に直結します。
概要と影響｜どんな被害が起きるのかを想像する
JVNレポートの最上部にあるのが「概要（Description）」と「影響（Impact）」です。ここには技術論を脇に置いた要約が簡潔に書かれています。
概要欄には「どのベンダーの、どの製品の、どのバージョンに弱点があるのか」という対象範囲が示されます。そして最も注視すべきが次の「影響」欄で、「この脆弱性を悪用されると最悪どうなるのか」が事実ベースで記述されています。
具体例を挙げます。
- 遠隔の第三者によって、サーバー上で任意のOSコマンドを実行される可能性がある
- 認証を必要とせずに、データベース内の情報を閲覧・改ざんされる可能性がある
- 細工されたリクエストの処理により、サービス運用妨害（DoS）状態に陥る可能性がある
この影響欄を読みながら「これは情報漏えい（機密性の侵害）につながるのか」「システム停止（可用性の侵害）を招くのか」を瞬時に脳内でプロットする癖をつけてください。午後の事例問題で、攻撃シナリオと想定被害を記述させる設問の模範解答は、まさにこのJVNの影響欄のバリエーションだからです。
CVSS｜脆弱性の深刻度を客観的に数値化する
リスクの深刻度を主観ではなく客観的な物差しで評価する世界標準が、CVSS（Common Vulnerability Scoring System）です。JVNでは、CVSSスコアが「0.0〜10.0」の数値と、重要度のラベル（緊急・重要・警告・注意など）で示されます。
学び始めの人が陥りがちなのが、ベクトル文字列（例：AV:N/AC:L/PR:N/UI:N…）の英数字をいきなり全部暗記しようとすることです。まずは、その数値が何を意味するのか根本のロジックを押さえましょう。CVSSの基本評価基準（Base Metrics）のスコアは、おおむね次の要素の組み合わせで高くなります。
- 攻撃の難易度：攻撃条件の複雑さ、必要な権限レベル、ユーザーの関与の有無。特別な権限が不要で、ユーザーが何も操作しなくても発動する脆弱性ほど点数が高い。
- 攻撃元区分：インターネット越しに攻撃できる（Network）ものは点数が高く、物理的に機器の前に立つ必要がある（Physical）ものは低い。
- 影響の大きさ：機密性・完全性・可用性への打撃が大きいほど点数が高い。
つまり「インターネット経由で、権限なしに、操作も不要でシステムを破壊できる」脆弱性は最高の10.0（緊急）に近づきます。
ここで試験対策上とても重要なのが、CVSSの評価基準は1種類ではないという点です。CVSSには次の3グループがあります。
- 基本評価基準（Base Metrics）：脆弱性そのものの特性を表す普遍的なスコア。時間や環境で変化しない。ニュースで「CVSS 9.8」と報じられるのは通常これ。
- 現状評価基準（Temporal Metrics）：攻撃コードの出回り具合や修正パッチ・回避策の有無など、時間とともに変わる要素を反映する。
- 環境評価基準（Environmental Metrics）：そのサーバーがインターネットに面しているか、守る情報の機密性が高いかなど、組織固有の事情を加味する。
午前IIで問われる定番は「基本評価基準は、利用環境に依存しない脆弱性そのものの深刻度を表す」という定義です。基本評価基準を出発点に、自組織の環境評価基準を当てはめて最終判断する、という流れを押さえておきましょう。
実務では、システム管理者はこのCVSSスコアを基準に「今夜緊急でパッチを当てるか」「次回定期メンテナンスまで様子を見るか」をトリアージ（優先順位付け）します。
対策｜レポートの締めくくりで最重要のパート
JVNレポートの締めくくりが「対策（Solution）」のセクションです。多くの場合、ここにはベンダーへのリンクとともに「最新の修正バージョンを適用する」という記述が並びます。ただし、公表されて間もない脆弱性では「修正モジュールが提供されるまでの暫定的な措置」が併記されることがあります。
たとえば「設定ファイルの該当パラメータを変更する」「ファイアウォールで特定ポートへのインバウンド通信を遮断する」「影響を受けるプラグイン機能を一時的に無効化する」といった指示です。SC午後の作問者は、このJVNの対策記述をベースに、架空企業の環境に合わせたシナリオを組み立てています。このセクションを読むときは、文字を追うだけでなく「なぜこの設定変更で攻撃を防げるのか」というネットワークやOSの動作に立ち返って因果を意識することが、記述の得点力を高める鍵になります。
なお、この「対策」欄で示される措置こそが、次章で解説する「解決策」と「回避策」という2つの言葉に分かれます。ここが本記事の核心です。
SC試験の合否を分ける「解決策」と「回避策」の決定的な違い
ここからが本記事の最重要テーマであり、SC午後の合格ラインを越えられるかどうかの分岐点です。JVNの対策欄や設問文には「解決策」と「回避策」が明確に使い分けられて登場します。この2つを混同していると、午後の記述でどれだけ長文を書いても、前提条件を無視した解答として得点にならないという事態に陥ります。
解決策（根本対策）｜パッチ適用とバージョンアップ
「解決策」とは、プログラムのソースコードに存在するバグや設計ミスを、修正済みのコードに書き換えることで、脆弱性そのものをシステムから消し去る根本的なアプローチです。具体的には、ベンダーが配布する修正パッチの適用や、ソフトウェアのバージョンアップがこれに当たります。
医療にたとえるなら、病気の原因そのものを取り除く「根治治療」です。解決策を正しく適用できれば、その脆弱性を狙う攻撃コードがどれだけ送られてきても、システムが誤動作する余地は構造的になくなります。
「それなら常に解決策だけを選べばよいのでは」と思うかもしれません。しかし現場には、教科書どおりにいかない事情があります。本番環境で稼働する基幹サーバーやWebアプリにパッチを適用することは、システムの一部を書き換える行為です。これにより、これまで正常に動いていた別システムとの連携が突然壊れたり（デグレード）、処理性能が低下したりするリスクが常に伴います。
そのため、実務で解決策を適用するには、本番と同等の「検証環境」で回帰テスト（リグレッションテスト）を行い、サービス停止のためのダウンタイムを関係部門と調整する、というコストと時間のかかるプロセスが必要になります。ここに、すぐには解決策を打てないという制約が生まれます。
回避策（ワークアラウンド）｜時間を稼ぐための応急処置
パッチの検証や社内調整に1週間かかるとして、その間、深刻な脆弱性を抱えたサーバーをインターネット上に無防備なまま放置するわけにはいきません。攻撃者はスキャンを仕掛けてくるからです。
そこで必要になるのが「回避策（ワークアラウンド）」です。これは、プログラムのバグ（弱点）そのものはシステム内に残ったまま、システムの「運用方法」や「周辺の設定」を変えることで、攻撃者が弱点に到達できないようにし、攻撃の成立を防ぐ応急処置です。
医療の例えに戻すと、根治はできないが、感染拡大を防ぐために一時的に隔離する時間稼ぎの措置に当たります。回避策は、SC午後で頻出するパターンに沿って整理すると理解しやすくなります。
- ネットワークレイヤー：ファイアウォールやルーターで、攻撃元と想定されるIPアドレス帯や、脆弱性のあるサービスが使う特定ポートへのアクセスを一時的に遮断する。
- ミドルウェアレイヤー：Webサーバーの構成ファイルを変更し、脆弱性のある特定URLへのリクエストに 403（アクセス拒否）を返して、バックエンドの処理に到達させない。
- サービスレイヤー：業務影響を精査したうえで、脆弱性を抱える機能（デーモンやサービス）自体を一時的に停止する。
設問の制約条件が「どちらを答えさせたいか」を決める
午後の設問文は注意深く読んでください。もし問題文の制約に「本番システムへのパッチ適用は次回の定期メンテナンス（1か月後）まで実施できない」と書かれ、設問で「管理者が実施すべき対策を答えよ」とあれば、それは回避策を答えさせる誘導です。ここで「最新のパッチを当てる」と書いてしまうと、前提条件を無視した解答となり、得点になりません。
逆に、恒久的に脆弱性を除去する対策を問われているのに回避策だけを書くと、根本対策に触れていないとして不十分な解答になります。つまり、解決策と回避策のどちらを答えるべきかは、あなたが決めるのではなく、設問の制約条件が決めます。「今この制約のなかで、何を答えれば設問の要求を満たすか」を読み取る力が問われているのです。
現場でも同じ判断が日々起きています。予算や時間の制約から理想の対策をすぐに打てないなかで、手持ちの設定を工夫してシステムを守り抜く。この現実の思考回路こそ、午後問題が測ろうとしている「回避策」の本質です。試験の問題用紙にあるネットワーク構成図は絵空事ではなく、誰かが予算と納期の狭間で下した判断の写し鏡だと考えてみてください。
SC試験での出題パターンと対策
ここでは、JVNと解決策・回避策のテーマが試験本番でどう問われるかを、出題パターンに沿って整理します。あわせて、学び始めの人が陥りやすい罠も押さえておきましょう。
午前IIは「役割分担」と「CVSSの定義」が定番
午前IIでは、情報セキュリティ早期警戒パートナーシップにおけるIPAとJPCERT/CCの役割分担が繰り返し問われます。「製品開発者などとの調整を行う機関はどれか」という問い方であれば正解はJPCERT/CC、「発見者からの届出を受け付ける機関はどれか」であれば正解はIPAです。選択肢にはNISC（内閣サイバーセキュリティセンター）やJIPDEC（日本情報経済社会推進協会）など、紛らわしい組織が並ぶのが定番です。名称の雰囲気で選ばず、必ず「受付＝IPA／調整＝JPCERT/CC」という役割で判別してください。
CVSSについては「基本評価基準は利用環境に依存しない脆弱性そのものの深刻度を表す」という定義や、基本・現状・環境の3グループの区別が狙われます。「時間で変化するのは現状評価基準」「組織ごとに変わるのは環境評価基準」という対応関係を押さえておきましょう。
これらは高度試験系（応用情報や高度区分の午前）でも共通して出題されてきた定番テーマです。出題年度を特定して丸暗記するより、役割と定義を理屈で理解しておくほうが応用が利きます。
午後は「解決策と回避策の書き分け」で差がつく
午後試験では、JVN情報をもとにした現場対応力が直接問われます。典型的には、Webサーバーに深刻な脆弱性が見つかったが稼働要件によりすぐにパッチを当てられない、といった状況で「システム管理者がとるべき回避策を◯字以内で述べよ」という設問が立ちはだかります。
ここで「提供された最新パッチを適用する」と書くと、それは解決策であって設問が求める回避策ではないため、得点になりません。「該当する不正な通信を遮断する」「影響を受ける特定機能を一時的に無効化する」といった、時間稼ぎのための設定変更を書けるかどうかが分かれ目です。
学び始めの人が陥る罠｜「とりあえずAllow All」
回避策として「特定のポートを遮断する」という対策を学ぶとき、頭の中の前提が「ホワイトリスト方式（基本はすべて拒否）」になっているかを確認してください。サーバー構築の演習で通信がつながらないとき、切り分けのつもりでファイアウォールやセキュリティグループを「Allow All（すべて許可、0.0.0.0/0）」にしてしまい、通信が通った安心感からそのまま元に戻さない、という失敗は現場でよく見かけます。
一時的な切り分けとして許可を広げること自体は間違いではありませんが、最小権限の原則（不要な通信は最終行ですべて拒否する）を崩したまま放置すると、脆弱性を自ら作り出すのと同じです。午後でパケットフィルタリングルールの空欄を埋めさせる問題では、この「不要な通信は最後に必ず拒否する」という思想が身についていないと、条件の抜け漏れを見落として失点します。演習の段階から、この大原則を体に染み込ませておきましょう。
JVNの「超訳」トレーニングで読解スタミナを鍛える
SC午後は、長文を読み進めるスピードとスタミナが要求されます。この読解力を日常的に鍛えるのに有効なのが、JVNの記述を自分の言葉に「超訳」する習慣です。
- 「リモートの攻撃者が、細工されたHTTPリクエストを送信することで……」 → インターネットにつながってさえいれば、外部から攻撃用の文字列を送りつけられるだけで。
- 「影響を受けるシステムにおいて、任意のコードを実行される可能性がある……」 → サーバーの中で好きなコマンドやプログラムを勝手に実行されてしまう状態。
この脳内翻訳の速度が上がると、午後のリード文を読んだ瞬間に「今回はコマンドインジェクションの話だから、対策は入力値検証の強化（解決策）か、WAFでの遮断（回避策）を答えさせる流れだな」と、設問の骨子が先読みできるようになります。テキストを何周も読むより、1日1件のJVNレポートを超訳するほうが、実戦的な読解力が身につきます。
【演習】JVNと解決策・回避策の理解度チェック（全10問）
このテーマは、午前IIでは「情報セキュリティ早期警戒パートナーシップにおけるIPAとJPCERT/CCの役割分担」「CVSSの評価基準の定義」が繰り返し問われ、午後では「制約条件のもとで管理者がとるべき対策（多くは回避策）を字数制限つきで記述させる」形で問われます。定番の引っかけは、受付機関（IPA）と調整機関（JPCERT/CC）の取り違え、CVSSの基本／現状／環境の混同、そして設問が回避策を求めているのに解決策（パッチ適用）を答えてしまうパターンです。以下の練習問題で本記事の理解度を確認してみましょう。
まとめ：現場のトレードオフを言語化し、SC午後につなげよう
一見すると無機質なアルファベットの羅列に見えるJVNの脆弱性レポートも、背後にある「情報セキュリティ早期警戒パートナーシップ」の思想と、現場の運用フェーズを意識して読めば、極めて論理的な「システムを守るための指示書」であることが見えてきます。
- JVNと早期警戒パートナーシップ：ゼロデイ攻撃から社会を守るための官民連携の枠組みであり、「受付＝IPA、調整＝JPCERT/CC」という役割分担は午前IIの定番の得点源です。
- JVNの3項目とCVSS：概要・影響・対策の3点を真っ先に抽出し、CVSSの基本評価基準（環境に依存しない深刻度）を出発点に、現状・環境評価基準で自組織向けに補正する、という読み方を押さえましょう。
- 解決策と回避策：脆弱性を根本除去する解決策（パッチ適用・バージョンアップ）が、業務影響やデグレード検証のためすぐに打てない局面で、設定変更やアクセス遮断によって時間を稼ぐのが回避策です。どちらを答えるかは設問の制約条件が決めます。
限られた予算や時間のなかで、理想の対策を打てないまま手持ちの設定を工夫してシステムを守り抜く。CIOとして予算制約に直面した立場から言えば、この現場のトレードオフを言語化できるかどうかが、午後の記述で問われている核心です。そして、演習中に「つながらないからとりあえずAllow All」にしてしまう習慣は、最小権限の原則を崩す危険な癖であり、早いうちに矯正しておきたいポイントです。
SC試験は、過去問の答えを暗記した秀才を選ぶ試験ではありません。日々現れる脆弱性と限られたリソースという現実のなかで、論理的思考と現場の知恵でシステムを守れるかを問う、実戦的なシミュレーションです。まずは身近なJVNレポートを一つ、自分の言葉で超訳することから始めてみてください。共に「SC試験合格」を掴み取りましょう。
本記事は情報処理安全確保支援士（SC）試験対策を目的として作成しています。
参考資料
- IPA「情報セキュリティ早期警戒パートナーシップガイドライン」 https://www.ipa.go.jp/security/guide/vuln/partnership_guide.html
- JPCERT/CC「JVNについて（About JVN）」 https://www.jpcert.or.jp/english/vh/project.html
- IPA「脆弱性対策：Japan Vulnerability Notes（JVN）について」 https://www.ipa.go.jp/security/vulnerabilities/jvn/about.html
- 経済産業省「脆弱性関連情報取扱体制」 https://www.meti.go.jp/policy/netsecurity/vulinfo.html
- Japan Vulnerability Notes（JVN） https://jvn.jp/