情報処理安全確保支援士(SC、登録セキスペ)の科目B(旧・午後問題)で、令和7年に入って存在感が増しているのがサプライチェーン・クラウドの問題です。業務委託先、外部のスクリプト、CI/CDサービス、親会社からの要求と、題材は「自社の外」にあるものばかりです。
この記事では、この分野の過去問3問を使って、「なぜその答えになるのか」「問題文のどの文に着目すれば答えが出るのか」を解説します。答えはIPAの解答例、つまずきやすい設問はIPAの採点講評で確認しています。分析にはAI(Claude)も使っています。
科目B全体の出題傾向は、科目Bの出題傾向を10回分分析した記事にまとめています。この記事は、その分野別シリーズの4本目です。1本目はWeb問題(XSS・CSP・CSRF)、2本目は認証・API・スマホアプリ問題、3本目はネットワーク・リモートワーク問題です。
結論:サプライチェーン問題は「3つの着眼点」で解ける
3問を並べてみると、答えの根拠になる文の場所はほぼ決まっていました。
- そのモノが「どこに置いてあるか」「誰が管理しているか」を確定する。外部のサーバから読み込むスクリプト、CIサービスのデータベースに預けた鍵、ファイルサーバの設計情報。置き場所が分かれば、SBOMに載らない理由も、漏えいの範囲も、権限の見直し方も決まる
- 漏れた情報で「攻撃者が次に何をするか」から逆算する。署名鍵とアップロード用のAPIキーが両方漏れたら、偽アプリの配布。ワンタイムパスワードが漏れたら、有効な間のログイン。対策は、その「次の一手」を止める形で答える
- 設問が求める「対策の種類」から外れない。防ぐのか、気付くのか、復旧するのか。採点講評では、復旧を問う設問に「攻撃を防ぐ対策」を書いた解答や、マルウェア対策に「利用者認証の強化」を書いた解答が誤答として挙げられています
技術の細かい知識より、表と図に書かれた「置き場所」と「業務の流れ」を拾えるかが点数を分けています。
この記事で使う過去問3問
| 回 | 題材 | 出てくる技術・考え方 | 採点講評で正答率が低かった設問 |
|---|---|---|---|
| 令和7年春期 問1 | システム開発会社のサプライチェーンリスク対策 | セキュリティ・バイ・デザイン、再委託、外部スクリプト、SBOM、踏み台サーバ、SAST | 設問5(2)が低い |
| 令和5年秋期 問3 | CIサービスへの不正アクセスと、利用企業での対応 | コンテナ、TOTPの中継、Certificate Transparency、ドメインフロンティング、WebAuthn、CAA、コード署名とHSM | 設問2(5)が低い |
| 令和7年秋期 問4 | 親会社から対策を求められた部品メーカー | サイバーセキュリティ経営ガイドライン、リスク対応、最小権限、ネットワーク分離、復旧計画 | 設問3がやや低い |
令和7年春期 問1(問題PDF):SBOMを作っても防げなかったインシデント
金融業向けにシステムを開発しているL社が、サプライチェーンリスク対策のガイドラインを作り、開発中のシステムを点検する問題です。開発プラットフォームには、ソースコードの管理、CI/CDパイプライン、SBOM作成の機能があります。
設問1:セキュリティ・バイ・デザインと再委託
着目する文: 表1のガイドライン案の項番9「システムの仕様,機能を精査し,不要な機能やセキュリティ上の欠陥がないことを設計書から確認すること」と、項番5「業務委託先でのセキュリティ管理に関する要件を,業務委託先との契約に含めること」。
- 設問1(1):セキュリティ・バイ・デザインの考え方は、解答例では「企画・設計工程からセキュリティ対策を組み込むという考え方」
- 設問1(2):再委託に備えて契約書に明記すべき事項は、解答例では「L社の業務委託先に要求する対策と同等のセキュリティ対策を再委託先にも要求させること」
(2)は、委託先と同じ水準を「再委託先にも求めさせる」という形がポイントです。L社が再委託先と直接契約するわけではないので、委託先に、再委託先へ要求させるという書き方になります。
設問2:外部のスクリプトはSBOMに載らない
着目する文: 「スクリプトPは,T社が運営するサーバ(以下,サーバTという)に配置され,システムQにアクセスしたWebブラウザがスクリプトPを都度読み込む」と、冒頭の「開発対象のSBOM作成機能はプラットフォームG上のリポジトリサーバ内のソースコード及びライブラリをシステム構成要素として一覧化する」。
過去のインシデントは、外部のサーバTが乗っ取られて、そこから読み込んでいたスクリプトPが改ざんされた、というものです。
- 設問2(1):影響を受けない配置方法は、解答例では「スクリプトPをダウンロードしておき,システムQのサーバ上に配置する方法」
- 設問2(2):古いWebブラウザのサポートを終えるために加えた変更は「スクリプトPを読み込む箇所をソースコードから削除する」
- 設問2(3):外部のスクリプトを把握するために修正した項番は1、修正内容は「連携している外部サービスを管理対象に含める」
D氏が「SBOMを作成していたとしても,スクリプトPはSBOMに含まれない」と言う理由は、冒頭の一文にあります。SBOM作成機能が一覧化するのはリポジトリサーバ内のソースコードとライブラリだけです。スクリプトPはサーバTに置かれていて、リポジトリにはありません。だから、SBOMとは別に、表1の項番1(情報資産の一覧)に外部サービスを足す、という答えになります。
採点講評では、設問2(1)の正答率はやや高かった一方で、「JavaScriptが正しく動作しない配置方法の解答が散見された」とあります。スクリプトはブラウザで動くので、システムQのWebサーバ上に置いてブラウザに配信する必要があります。
設問3:「問題なし」も答えになる
着目する文: 表2の「表1の項番」と「確認した図1の項番」の対応。
表2は、ガイドライン(表1)の項番ごとに、システムSの概要(図1)のどの項番を見たかを並べた表です。表1の項番の中身と、図1の項番の中身を、言葉で突き合わせていきます。
| 表1の項番(ガイドライン) | 図1の項番(解答例) | 確認結果(解答例) |
|---|---|---|
| 2 アカウントは利用者を特定できるように | ア:10 | a:開発環境の踏み台サーバで共用アカウントを利用している |
| 5 委託先との契約に要件を含める | イ:4 | 問題なし(問題文に記載済み) |
| 9 設計書から欠陥がないことを確認 | ウ:5 | b:問題なし |
| 15 インシデント対応手順書を作成 | エ:11 | c:問題なし |
図1の項番10には「会社ごとに発行した共用アカウントでログインする」とあり、表1の項番2の「アカウントの利用者を特定できるようにすること」に反します。一方、図1の項番5と11は、表1の項番9と15をそのまま満たしています。空欄だからといって必ず問題点があるとは限らない、というのがこの設問の作りです。
設問4:SBOMで脆弱性管理がしやすくなる理由
解答例は「利用しているソフトウェアやそのバージョンが明確になり,脆弱性の影響有無を容易に把握できるから」です。
採点講評では、正答率は平均的で、「SBOMの利用方法が説明できておらず,SBOMの定義を記載しただけの解答が散見された」とあります。「ソフトウェアの部品表である」で止めず、新しい脆弱性が公表されたときに、自社のどのシステムが影響を受けるかをすぐ調べられる、という使い道まで書く必要があります。
設問5:アクセスログの取得場所と、SASTを動かす場所
着目する文: 図1の項番10「開発LANにアクセスする際には一旦,踏み台サーバにログインする」「開発LAN上のサーバには製品仕様上,アクセスログが取れないものもある」と、冒頭の「ツールFは(中略)コンパイルエラーが解消されたソースコードに対してだけ正常な検査が可能である」。
設問5(1)は、社内からのアクセスログをどこで取るかです。VPN-GWを通るのはオフショア拠点からのアクセスだけですが、踏み台サーバは社内からもオフショアからも必ず通ります。開発LANのサーバではログが取れないものもあるので、解答例のdは踏み台サーバです。
設問5(2)は、図3の開発フローの(あ)と(い)で、SASTツール(ツールF)を実行する利点です。
| 場所 | 直前の処理 | 解答例の利点 |
|---|---|---|
| (あ)開発者の端末 | コンパイルの実行(1) | ツールFで検知できるエラーをより早く発見することができる |
| (い)プラットフォームG | コンパイルの実行(2)(複数の開発者の変更を反映した上で、コンパイルエラーが出ないことを確認) | CI/CDパイプラインの管理機能を使って自動実行することができる |
どちらも「コンパイルの直後」なのは、ツールFがコンパイルエラーのないソースコードしか検査できないからです。(あ)は開発の早い段階で見つかる利点、(い)は冒頭の「CI/CDパイプラインの管理機能で,ツールFでのチェックを自動的に行うようなワークフローを構成することができる」がそのまま根拠です。
採点講評では正答率が低く、「SAST,DAST,IASTといった開発プロセスで活用するセキュリティテストツールについて,それぞれの特徴を理解してほしい」とあります。SASTはソースコードを動かさずに検査するので、早い段階で使える、という特徴を押さえておけば、(あ)の利点が書けます。
令和5年秋期 問3(問題PDF):CIサービスから鍵が漏れたら、何が起きるか
継続的インテグレーション(CI)サービスを提供するN社が不正アクセスを受け、利用企業のソースコードとシークレット(APIキーなど)が漏えいしたおそれが出る問題です。前半はN社側の調査、後半は利用企業P社の対応です。
設問1:コンテナから出なくてもできること
着目する文: 「CIデーモンは,処理命令を受け取ると,特権を付与せずに新しいコンテナを起動し」と、表2の「バックエンド(中略)インターネットへの通信が可能である」。
利用者はビルドスクリプトに任意のコマンドを書けます。下線①は「コンテナによる仮想化の脆弱性を悪用しなくても成功してしまうもの」です。
| 選択肢 | 解答例 | 考え方 |
|---|---|---|
| ア CIデーモンのプロセスを中断させる | × | CIデーモンはコンテナの外(バックエンド)で動いている |
| イ バックエンド上の全プロセスを列挙して送信する | × | コンテナの外のプロセスは見えない |
| ウ インターネット上のWebサーバに不正アクセスを試みる | ○ | インターネットへの通信は許されている |
| エ 攻撃者サイトから命令を取得して実行する | ○ | 同上。コンテナの中で完結する |
| オ ほかの利用者のビルドスクリプトの出力を取得する | × | 別のコンテナの中身は見えない |
解答例はウ,エです。採点講評では正答率がやや低く、「コンテナを使ったシステムの構成及び特性をよく理解してほしい」とあります。コンテナの中だけで完結する処理か、外に手を伸ばす処理かで分けると判断できます。
設問2(1)(5):TOTPは中継され、WebAuthnは中継されない
着目する文: 「Uさんはメール中のURLを開き,クラウド管理サイトだと思ってログインを試みていた」と、図2の項番3「偽サイトでログインを試みてしまっても,クラウド管理サイトに不正ログインされることのないよう」。
- 設問2(1):不正ログインの方法は、解答例では「偽サイトに入力されたTOTPを入手し,そのTOTPが有効な間にログインした」
- 設問2(5):WebAuthnで不正ログインを防げる仕組みは、解答例では「認証に用いる情報に含まれるオリジン及び署名をサーバが確認する仕組み」
TOTP(時刻を使ったワンタイムパスワード)は、利用者が自分で入力する数字です。偽サイトに入力させれば、攻撃者はその数字を正規サイトにそのまま入力できます。ネットワーク問題の記事で扱った、SMSのコードを中継するフィッシングと同じ形です。
WebAuthnは、ブラウザがアクセス先のオリジン(ドメイン)を認証の情報に含めて、端末の秘密鍵で署名します。偽サイトで認証しても、オリジンが偽サイトのものになるので、正規サイトのサーバが受け付けません。
採点講評では、設問2(5)の正答率が低く、「WebAuthnをクライアント証明書認証やリスクベース認証などほかの認証方法と誤認した解答が多かった」とあります。「WebAuthnはフィッシング耐性がある認証方法である」「Passkeyという新たな方式も登場し,普及し始めている」とも書かれていて、今後も出やすい論点です。
設問2(2)(3)(6):サーバ証明書の不正発行とSNIの偽装
着目する文: 「ドキュメントルートに”/.well-known/pki-validation/“ディレクトリが作成され,英数字が羅列された内容のファイルが作成されていた」「TLSのServer Name Indication(SNI)には,著名なOSS配布サイトのドメイン名が指定されており(中略)HTTP Hostヘッダーでは別のドメイン名が指定されていた」。
| 設問 | 解答例 | 根拠 |
|---|---|---|
| (2) RFC 9162の技術 | ア Certificate Transparency | 発行されたサーバ証明書が記録される公開ログ。身に覚えのない証明書を見つけられる |
| (3) SNIを偽装する手法 | イ ドメインフロンティング | SNI(TLSの外から見える宛先)とHostヘッダー(暗号化された中の宛先)が違う |
| (6) 証明書を発行できる認証局を限定するDNSレコード | ア CAA | 権威DNSサーバに「このドメインの証明書を発行してよい認証局」を書く |
フロントエンドに作られたファイルは、攻撃者がドメインの持ち主であることを認証局に示すためのものと考えられます。フロントエンドの管理者権限を奪ったので、認証局Rにサーバ証明書を発行させることができた、という流れです。CAAレコードで認証局を限定しておけば、それ以外の認証局は発行を断るので、図2の項番4の対策になります。
設問2(4):シークレットは環境変数にある
着目する文: 表1のシークレット機能「ビルドスクリプトを実行するシェルに設定される環境変数を,Nサービス利用者が登録する機能」と、「管理者権限をもつ不審なプロセス(以下,プロセスYという)」。
シークレットは、ビルドスクリプトを実行するときに環境変数としてプロセスに渡されます。プロセスYはバックエンドの管理者権限で動いているので、ほかのプロセスの環境変数も読めます。解答例は「/procファイルシステムから環境変数を読み取った」です。
設問1と組み合わせると、コンテナの中のプロセスでは見えないものも、バックエンドの管理者権限があれば全部見えるということです。Uさんのアカウントには「バックエンドの管理者権限」があった、という一文が効いています。
設問3:署名鍵とAPIキーが両方漏れたら
着目する文: 表3のシークレット「APP_SIGN_KEY:コード署名の付与に利用する署名鍵とコードサイニング証明書」「STORE_API_KEY:Jストアにアプリをアップロードするための認証用APIキー」と、「認証用APIキーはJ社が発行し,契約者だけがJ社のWebサイトから取得及び削除できる」。
P社がNサービスに預けていたのは、アプリに署名する鍵と、アプリをストアに上げる鍵の2つです。両方そろえば、攻撃者は「P社の正規の署名が付いた偽アプリ」をストアに公開できます。
| 設問 | 解答例 | 根拠 |
|---|---|---|
| (1) 予想される攻撃 | 有効なコード署名が付与された偽のPアプリをJストアにアップロードする攻撃 | 漏れた2つの鍵の使い道を組み合わせる |
| (2) APIキーへの対応 | J社のWebサイトから削除する | 「契約者だけがJ社のWebサイトから取得及び削除できる」 |
| (3) HSMの利点 | 秘密鍵が漏れないという利点 | 署名はHSMの中で行い、鍵は外に出ない |
| (4) 利用者への影響と対応 | 影響:Pアプリを起動できない。対応:Pアプリをアップデートする | コードサイニング証明書を失効させたので、古い署名のアプリは検証に失敗する |
(4)は、本文の「スマートフォンOSは,各アプリを起動する前にコード署名の有効性を検証しており,検証に失敗したらアプリを起動しないようにしている」が根拠です。自社の対応(証明書の失効)が、利用者にどう跳ね返るかまで問われています。
採点講評では、設問3(3)の正答率がやや低く、「“電子署名を暗号化できる”,“秘密鍵が漏えいしても安全である”などといった,暗号技術の利用方法についての不正確な理解に基づく解答が散見された」とあります。HSMの利点は「漏れても大丈夫」ではなく、そもそも取り出せないので漏れないことです。
令和7年秋期 問4(問題PDF):親会社から求められた対策を整える
家電部品を作るL社が、親会社J社から「サイバーセキュリティ経営ガイドライン Ver 3.0」に基づく対策を求められる問題です。サプライチェーンの「下流」にいる会社が、上流から管理体制を求められる場面です。
設問1・設問2(1):パターンマッチングの弱点と、リスク対応の4分類
知識で取れる設問です。
- 設問1:パターンマッチング型は「未知の」マルウェアを検知できない。どちらの方式も「暗号化」された添付ファイル内のマルウェアは検知できない
- 設問2(1):リスク対応は、低減のほかに「回避」「移転」「保有」(順不同)
設問2(2):権限は「業務の流れ」から決める
着目する文: 「設計情報ファイルを扱う業務が図4だけなら」と、図4の試作時の製造の流れ。
図4を1行ずつ読み、設計情報ファイルを誰が保存し、誰が読むかを拾います。
| 所属組織 | 図4での設計情報ファイルの扱い | 解答例(読込/書込/権限変更) |
|---|---|---|
| 総務部総務課 | 出てこない | ×/×/× |
| 総務部情報システム課 | 出てこない(権限の管理だけ) | ×/×/○(印刷済み) |
| 営業部 | 項番2で保存し、正常に読み込めるか確認する | ○/○/× |
| 製造部設計課 | 項番3で参照する | ○/×/× |
| 製造部製造課 | 項番5で試作品が設計情報ファイルに適合しているか確認する | ○/×/× |
| 製造部品質保証課 | 項番5で同上 | ○/×/×(印刷済み) |
製造課は、NCプログラムを作るときに見るのは「設計図ファイル」ですが、項番5で設計情報ファイルに適合しているかを確認するので、読込権限は必要です。設計課と製造課の書込権限、設計課の権限変更権限は、図4に必要な場面がないので外します。本文に書かれた業務以外は認めないのが最小権限の原則です。
設問3:SCADAを守る対策は「認証」ではない
着目する文: 表4の項番3「電子メールに添付されたマルウェアによって,社内の一般PCにマルウェアの感染が広がった後,SCADAに感染が広がり」、項番4「購入したUSBメモリがマルウェアに感染していて,そのUSBメモリからSCADA操作用PCがマルウェアに感染し」と、図3のネットワーク図。
- f:図3中の(け)の箇所に,追加でFW
- g:USBメモリを接続したときの動きを確認するためのソフトウェアを導入した,社内LANから切り離された検査用PC
図3の(け)は、L3SWから製造課のSCADA・工作機械のネットワークへつながる線です。ここにFWを置けば、一般PCからSCADAへの感染の広がりを止められます。設問の条件「できるだけ効果が高いもの」「効果が同程度であれば,業務への影響が少ないもの」にも合います。
採点講評では正答率がやや低く、「SCADAの利用者認証の強化という解答が散見された」とあります。理由として「マルウェアは,OSやアプリケーションの脆弱性を悪用したり,正常に認証された利用者をだましたりして実行される」「マルウェア対策として利用者認証の強化はあまり効果がない」と書かれています。攻撃シナリオの「感染の経路」をふさぐのが答えの方向です。
設問4:問われているのは「防ぐ」ではなく「2時間で戻す」
着目する文: 図2の「全ての工作機械が停止してしまった場合でも,停止時間が2時間以内であれば出荷への大きな影響は避けられる」、表1のSCADA「故障時の予備機を1台保管している。予備機にはOSを含め何もインストールしていない」と、表6の既存の行。
表6は、被害のシナリオごとに、2時間以内に製造を再開するための「必要な仕組み」と「必要な手順」を並べた表です。
- h・i:予備機にOSとSCADAアプリを戻しても、SCADAの中のNCプログラムがなければ工作できません。解答例は「SCADA内のNCプログラムをバックアップ/リストアするための媒体とソフトウェア」と「SCADAにNCプログラムをリストアする手順」
- j・k・l:感染した一般PCが大量のパケットを送って、SCADAと工作機械の通信を妨げるシナリオです。解答例は、jが「マルウェアに感染した一般PCが,正常な通信を妨害するパケットを大量に送信して,SCADAと工作機械の間の通信ができなくなる」、kが「SCADA,工作機械及び製造監視用PCだけの独立したLANを構成するためのネットワーク機器」、lが「SCADA,工作機械及び製造監視用PCをL社のネットワークから切り離す手順」
解答例の備考には、いずれも「左の例に限らず」とあり、本文の状況に沿った内容なら正解になる設問です。
採点講評では、正答率は平均的で、「被害に至る攻撃を阻止する手段について言及した解答が散見された」とあります。「迅速な復旧のためにはバックアップの取得など平常時に何を行うかが重要」「被害に至る経緯を解明するよりも,事業の復旧を優先する場合もある」とも書かれています。設問の見出しが〔指示8に関する助言〕(事業継続・復旧体制)であることを確認してから答えれば、ずれを防げます。
3問に共通する「問題文のここを見る」チェックリスト
| 問題文に出てきたら | 何に使うか | 出てきた問題 |
|---|---|---|
| 「〇〇が運営するサーバに配置され」「都度読み込む」 | 自社の管理外にある部品。SBOMに載らない、改ざんされたら影響を受ける | 令和7年春 問1 |
| SBOMやツールが「何を対象にするか」の一文 | 対象外のものは別の手段で管理する | 令和7年春 問1 |
| 「共用アカウント」「ログが取れないものもある」 | 責任追跡性の不備。ログはみんなが必ず通る場所(踏み台など)で取る | 令和7年春 問1 |
| 「〇〇に対してだけ正常な検査が可能」 | ツールを実行できる工程の条件 | 令和7年春 問1 |
| 「環境変数」「管理者権限をもつ」 | 権限があれば、ほかのプロセスの環境変数(/proc)も読める | 令和5年秋 問3 |
| 預けている鍵・キーの一覧表 | 組み合わせて何ができるか(偽アプリの配布など)を考える | 令和5年秋 問3 |
| 「契約者だけが〇〇から取得及び削除できる」 | 漏えい時の対応の手段 | 令和5年秋 問3 |
| 「〇〇だけなら」「業務の流れ」の図 | 権限の見直し(最小権限)の根拠 | 令和7年秋 問4 |
| 「〇時間以内であれば」「予備機には何もインストールしていない」 | 復旧に足りないもの(データのバックアップ)を探す | 令和7年秋 問4 |
CBT方式の科目Bでは、問題文にマーカーを引けます。「どこに置いてあるか」「誰が管理しているか」が書かれた文には、最初に読んだ時点で色を付けておくと、設問で迷いにくくなります。
最低限おさえる知識はこれだけ
サプライチェーン・クラウドの問題で、問題文に説明がないまま前提にされていた知識は、次のくらいでした。
| 知識 | 押さえるポイント |
|---|---|
| セキュリティ・バイ・デザイン | 企画・設計の段階からセキュリティ対策を組み込む |
| 再委託の管理 | 委託先に、自社と同等の対策を再委託先へ求めさせる |
| SBOM | ソフトウェアの部品表。脆弱性が公表されたとき、影響の有無をすぐ調べられる |
| SAST・DAST・IAST | SASTはソースコードを動かさずに検査、DASTは動いているアプリを外から検査、IASTは動かしながら内部から検査 |
| コンテナ | 中のプロセスからは、ほかのコンテナやホストのプロセスは見えない。ただしネットワーク通信はできる |
| Certificate Transparency | 発行されたサーバ証明書の公開ログ。不正発行に気付ける |
| CAAレコード | 証明書を発行してよい認証局をDNSで指定する |
| ドメインフロンティング | SNIとHostヘッダーで別のドメインを指定し、通信先を偽装する |
| WebAuthn | オリジンと署名をサーバが確認する。フィッシングで中継されない |
| コード署名とHSM | 証明書を失効させると、古い署名のアプリは検証に失敗する。HSMは鍵を外に出さない |
| リスク対応 | 低減・回避・移転・保有 |
| 最小権限の原則 | 業務に必要な権限だけを与える |
ネットワーク分離やフィッシングの基本は3本目のネットワーク問題の記事、認証まわりは2本目の認証・API問題の記事にまとめています。
過去問の解説動画を見るなら
過去問の解説動画には、Udemyの講座を使っています。科目Bの過去問解説(令和7年秋・令和7年春・令和6年秋)が入っていて、この記事で扱った令和7年春 問1と令和7年秋 問4を動画で見直せます。
令和8年度対応|参考書の著者が教える 情報処理安全確保支援士 科目A・科目B対策(Udemy)
講座の内容を見る
まとめ
- サプライチェーン問題は、そのモノがどこに置いてあり、誰が管理しているかを確定すると、SBOMに載らない理由も、漏えいの範囲も、権限の見直し方も答えになる
- 漏えいの問題では、漏れた情報を組み合わせて攻撃者が次に何をするかを考える。署名鍵とアップロード用のキーがそろえば、正規の署名付きの偽アプリが配れる
- TOTPは偽サイトで中継されるが、WebAuthnはオリジンを確認するので中継されない。令和5年秋 問3では、ここの正答率が低かった
- SASTはソースコードを動かさずに検査するので、早い工程で使える。令和7年春 問1では、ここの正答率が低かった
- 対策を問われたら、設問の見出し(防ぐ・復旧する)と攻撃シナリオの経路に合わせる。マルウェア対策に利用者認証の強化、復旧の設問に阻止の対策、はどちらも講評で挙げられた誤答
この分野は、自社の外にあるものが題材になるぶん、本文の「置き場所」と「管理者」の記述がそのまま答えの根拠になります。解き直すときは、答えを覚えるのではなく、根拠になった文や表がどこにあったかを確認すると、初めて見る題材でも同じ場所を探せるようになります。
シリーズ5本目の脆弱性管理・資産管理問題の記事では、CVSS・EPSS・KEVカタログとサブドメインテイクオーバーを扱っています。
この分野の攻撃と基本の対策の組み合わせは、聞き流し用の一問一答動画(攻撃と対策・42問・YouTube)でも耳で復習できます。
関連記事
- 情報処理安全確保支援士 科目B(午後)の出題傾向を分析|出やすい分野ランキングと過去問リンク集
- 支援士 科目B(午後)のWeb問題の解き方|XSS・CSP・CSRF
- 支援士 科目B(午後)の認証・API・スマホアプリ問題の解き方|JWT・セッション固定
- 支援士 科目B(午後)のネットワーク・リモートワーク問題の解き方|VPN・DDoS・無線LAN
- 支援士 科目B(午後)の脆弱性管理・資産管理問題の解き方|CVSS・EPSS・KEV
- 支援士 科目B(午後)のコード問題を全部解説|「書く」はJava・SQL・正規表現の定番だけ
- 支援士 科目B(午後)のインシデント対応・ログ解析問題の解き方|ログは「時系列に並べて、2つのログで裏付ける」【過去問2問で解説】
参考にした情報
- IPA 過去問題(令和7年度春期 科目B 問1、令和5年度秋期 午後 問3、令和7年度秋期 科目B 問4の問題・解答例・採点講評)
この記事で引用した問題文・解答例は、IPAが公開している過去問題からの抜粋です。一部を省略・要約し、表の形に整理しています。
よくある質問(FAQ)
Q1. 支援士の科目Bで、サプライチェーンの問題は出ていますか?
新形式になった令和5年秋期から令和7年秋期の5回では、令和7年春期 問1(委託先管理とSBOM)が主題として出ています。令和5年秋期 問3(CIサービスからの漏えい)と令和7年秋期 問4(親会社から求められた管理体制)も、自社の外にある委託先やサービスが題材です。IPAの「情報セキュリティ10大脅威」でもサプライチェーンの脅威は上位にあり、令和7年春期 問1の出題趣旨でもそのことに触れています。
Q2. SBOMの問題では、何を書けばいいですか?
令和7年春期 問1では、SBOMで脆弱性管理がしやすくなる理由として、利用しているソフトウェアやそのバージョンが明確になり、脆弱性の影響有無を容易に把握できるから、が解答例でした。採点講評では、SBOMの定義を書いただけの解答が散見されたとされています。また、外部のサーバから読み込むスクリプトはSBOMに含まれないため、別の方法で管理する必要がある点も問われました。
Q3. WebAuthnは、なぜフィッシングに強いのですか?
令和5年秋期 問3の解答例では、認証に用いる情報に含まれるオリジン及び署名をサーバが確認する仕組み、とされています。偽サイトで認証しても、認証の情報に含まれるオリジンが偽サイトのものになるため、正規サイトでは受け付けられません。採点講評では、クライアント証明書認証やリスクベース認証と誤認した解答が多かったとされています。
Q4. 復旧計画の設問では、何に注意すればいいですか?
令和7年秋期 問4の採点講評では、復旧を問う設問に、被害に至る攻撃を阻止する手段を書いた解答が散見されたとされています。迅速な復旧のためには、バックアップの取得など平常時に何を行うかが重要です。設問の見出しが「防ぐ」なのか「復旧する」なのかを確認してから答えます。