令和7年春 SC午後 問1 解説：サプライチェーンリスク管理

SC午後の記述式では、自社の中だけで完結する問題はほとんど出ません。むしろ「自社の外にある誰か」が絡んだ瞬間に、守るべき範囲と、守らせる手段と、守れているかを確かめる方法が一気に噛み合わなくなる。その噛み合わなさをどう言語化できるかが、そのまま得点になります。シリーズ第5弾は、令和7年度 春期（2025年4月）SC午後 問1のテーマであるサプライチェーンリスク管理を扱います。

この問題の面白いところは、「サプライチェーン攻撃」という攻撃手法そのものを問うていない点です。問われるのは、委託先と再委託先に何をどう要求するか、自社サイトが読み込んでいる外部のスクリプトをどう管理下に置くか、使っているソフトウェアの一覧をどう脆弱性対応につなげるか、そして開発現場の共用アカウントや踏み台サーバやコード検査ツールをどう回すかという、きわめて地味な管理の話です。攻撃の華やかさではなく、管理の抜け漏れに点がある。ここを取り違えると、知識はあるのに解答欄が埋まらないという事故が起きます。

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

事例シナリオ：旅行予約サービスを支える三層の委託関係

登場する企業とシステム

T社は、国内向けのオンライン旅行予約サービス「たびさがし」を運営する中堅事業者です。会員は約200万人、宿泊と交通の予約をWebサイト上で完結できます。予約フォームでは氏名・連絡先・クレジットカード番号を扱うため、T社にとって予約システムは最重要の情報資産です。

T社の開発体制は自社だけで閉じていません。

• T社：サービス企画、要件定義、受け入れテスト、運用監視を担当。情報セキュリティ担当はAさん。
• 委託先U社：予約システムの設計・開発・保守を受託するシステムインテグレータ。
• 再委託先V社：U社が会員管理機能の一部をさらに委託しているソフトウェア開発会社。T社とV社の間に直接の契約はありません。

さらに、T社のWebサイトは自社で作ったものだけで動いているわけではありません。アクセス解析タグ、チャットボットのウィジェット、広告効果測定タグの3つが、それぞれ外部事業者のサーバから配信されるJavaScriptとして読み込まれています。これらは「購入した製品」でも「自社で書いたコード」でもないため、T社の資産管理台帳にはどこにも載っていませんでした。

T社の開発環境は、インターネットから直接は触れない場所に置かれています。U社とV社の開発者は、T社が用意した踏み台サーバ（bastion host）にインターネット経由でログインし、そこから開発環境のソースコード管理サーバとビルドサーバにアクセスします。

ここで押さえておきたいのは、T社のファイアウォールが守っているのはDMZと開発環境だけだという点です。利用者のブラウザが外部事業者のスクリプト配信サーバへ取りに行く通信は、T社のネットワークを一切通りません。「自社サイトの一部として動いているのに、自社のどの機器も経由しない」という構図が、後の設問の土台になります。

ガイドライン案の作成

委託先起因のインシデントが同業他社で相次いだことを受け、T社の経営会議は「サプライチェーン全体でのセキュリティ強化」を決定しました。Aさんは外部コンサルタントのBさんの助言を受けながら、調達から運用までのライフサイクルに沿った委託先向けセキュリティ要求ガイドラインの案をまとめます。

ガイドライン案の主な項目は次のとおりです。

項番	項番工程	要求事項
1	調達	利用する外部サービス（SaaS、外部配信スクリプト等）を洗い出し、管理対象として台帳に登録すること
2	調達	利用するOSSライブラリの名称とバージョンを記録すること
3	契約	業務委託先に求めるセキュリティ管理要件を、業務委託契約に含めること
4	企画・設計	設計書のレビュー時に、セキュリティ機能の実装方針が盛り込まれているかを確認すること
5	開発	ソースコードに対する静的解析を実施し、検出された脆弱性を修正すること
6	開発	開発環境へのアクセスは個人ごとに払い出したアカウントで行うこと
7	リリース	リリース前に、利用ソフトウェアの構成情報を最新化すること
8	運用	脆弱性情報を継続的に収集し、影響有無を判定すること

Aさんが案をBさんに見せたところ、Bさんは「①セキュリティ・バイ・デザインの考え方が一部入っていますね」とコメントし、続けて「②項番3は、このままだと不十分です」と指摘しました。

過去インシデントの振り返り：外部スクリプトの改ざん

ガイドライン案の有効性を検証するため、Aさんは2年前にT社で起きたインシデントを振り返りました。

当時、予約フォームのページは日付選択UIライブラリ「スクリプトP」を、提供元W社の配信サーバから直接読み込んでいました。ある日、W社の配信サーバが侵害され、スクリプトPに不正なコードが追記されます。改ざんされたスクリプトPは、予約フォームに入力されたカード番号を攻撃者のサーバへ送信していました。T社のWebサーバのファイルは一切改ざんされておらず、T社側のWAFにも異常なログは残っていません。発覚したのは、カード会社からの不正利用の連絡を受けてからでした。

インシデント対応の記録には、次の2点が残っていました。

• 応急対応として、③予約フォームのソースコードにある変更を加えて被害の拡大を止めた。
• 恒久対応として、④スクリプトPを外部サーバ改ざんの影響を受けない配置に変更した。

Aさんはここで、より根本的な疑問に突き当たります。「そもそもT社は、自社サイトが外部のどのスクリプトを読み込んでいるかを把握していなかった。SBOMを作れば把握できるのだろうか」。Bさんの答えは「SBOM（Software Bill of Materials、ソフトウェア部品表）は自社が作るソフトウェアの構成部品を記録するもので、外部サービスから配信されるスクリプトは対象外になりがちです。⑤別の項番のほうが効きます」というものでした。

開発プロジェクトの点検で見つかった4つの穴

続いてAさんは、現在進行中の予約システム改修プロジェクトを点検し、U社の開発リーダーCさんにヒアリングを行いました。判明した問題点は4つです。

問題1：OSSライブラリの一覧がない。 予約システムは多数のOSSライブラリに依存していますが、どのライブラリのどのバージョンを使っているかをまとめた資料がありません。半年前に広く報道されたライブラリの脆弱性が公表された際、影響有無の判定に2週間かかりました。U社が使っているビルドツールにはSBOMの生成機能が備わっていますが、Cさんいわく「現状では特に利用していません」。

問題2：共用アカウントの利用。 ソースコード管理サーバへのログインに、U社とV社の開発者が「dev-team」という共用アカウントを使っていました。T社の内部監査部門は、この運用に対して⑥監査指摘を出しています。

問題3：踏み台サーバのログの取得範囲。 踏み台サーバではログイン成功・失敗のログを取得していましたが、⑦踏み台サーバから先の操作についてはログを取っていませんでした。

問題4：静的解析ツールが使われていない。 U社はSAST（Static Application Security Testing、ソースコードを実行せずに脆弱性を検出する静的解析）のツールFを保有していますが、使われていません。ツールFはコンパイルエラーが解消されたソースコードでなければ正常に検査できません。Cさんは「開発者の端末で実行するのと、CI/CDパイプライン上で実行するのと、どちらがよいのか決めかねている」と話しました。Bさんは「⑧どちらにも別の利点があります。片方だけを選ぶ前提で考えるのをやめましょう」と助言しました。

設問

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

設問1

（1）下線①について、セキュリティ・バイ・デザインとはどのような考え方か。「工程」という語を用いて35字以内で述べよ。

（2）下線②について、Bさんが不十分だと指摘した理由を踏まえ、項番3に追記すべき事項を50字以内で述べよ。

設問2

（1）下線③について、応急対応としてソースコードに加えた変更の内容を30字以内で述べよ。

（2）下線④について、変更後のスクリプトPの配置を30字以内で述べよ。

（3）下線⑤について、Bさんが「効く」と述べたガイドライン案の項番を答え、その項番が外部スクリプトの把握に有効である理由を40字以内で述べよ。

設問3

（1）問題1について、SBOMを作成することで脆弱性管理が容易になる理由を45字以内で述べよ。

（2）下線⑥について、内部監査部門が指摘した問題点を30字以内で述べよ。

設問4

（1）下線⑦について、踏み台サーバで追加して取得すべきログの内容を30字以内で述べよ。

（2）下線⑧について、ツールFを開発者の端末で実行する場合の利点と、CI/CDパイプライン上で実行する場合の利点を、それぞれ40字以内で述べよ。

回答例

設問1の回答例

（1）システムの企画・設計工程からセキュリティ対策を組み込む考え方（30字）

ガイドライン案の項番4が手がかりです。「設計書のレビュー時に、セキュリティ機能の実装方針が盛り込まれているか」を確認する、つまり完成したものを後から検査するのではなく、設計の段階で作り込みを確認している。この時制のズレに気づけるかどうかがすべてです。「いつ（企画・設計工程から）」「何を（セキュリティ対策を）」「どうする（組み込む）」の3要素を落とさずに書きます。

（2）委託先に要求するものと同等のセキュリティ対策を再委託先にも要求させること（36字）

項番3は「業務委託先に求める要件を契約に含める」としか書いていません。T社と直接契約があるのはU社だけで、V社とは契約関係がない。だから項番3のままでは、U社の先にあるV社にはT社の要求が一切届きません。これが「不十分」の中身です。

ここで書くべき本丸は同等水準の対策を再委託先にも要求させることの一点です。IPAの解答例もこの要素だけで構成されています。実務の業務委託契約では再委託の事前承諾も定番の条項ですが、採点の軸ではないので、字数に余裕がなければ切り捨てて構いません。

もう一つ、語尾に注意してください。「再委託先にも要求する」ではなく「要求させる」です。T社とV社には契約がないので、T社が直接要求することはできない。U社に要求させる、という使役の形でなければ、実行できない対策を書いたことになります。

設問2の回答例

（1）予約フォームからスクリプトPを読み込む箇所を削除する（26字）

応急対応なので、UIが多少崩れても構わないから出血を止める、という判断です。外部サーバを直せるのはW社だけであり、T社が自力でできるのは「取りに行くのをやめる」ことだけ。ここで「WAFで遮断する」と書くと外しになります。スクリプトPを読み込むのは利用者のブラウザであって、T社のWAFを通る通信ではないからです。事例の構成図で確認した「T社のネットワークを通らない」という事実が、そのまま選択肢を絞ります。

（2）スクリプトPをダウンロードし、T社のWebサーバ上に配置する（30字）

恒久対応は、依存先そのものを自社の管理下へ引き取ることです。自社サーバに置けば、配信元が改ざんされても利用者には届きません。代わりにT社がバージョン更新の責任を負うことになりますが、それは「管理対象になった」ということであり、むしろ望ましい状態です。

実務では、外部配信のままSRI（Subresource Integrity、読み込むファイルのハッシュ値をHTMLに書いておき、一致しなければ実行しない仕組み）で守る手もあります。ただし本問は「外部サーバ改ざんの影響を受けない配置方法」を聞いているので、配置の話で答えます。設問が何を聞いているかに答えるのが記述式の基本です。

（3）項番1／外部サービスを洗い出し台帳に登録するので、外部配信スクリプトも管理対象になるから（40字）

SBOMは自社が開発・提供するソフトウェアの構成部品表であり、他社のサーバから配信されてくるスクリプトは対象に入らないのが普通です。したがって、外部スクリプトを捕まえる網は別に必要になります。それがガイドライン案の項番1、すなわち利用する外部サービスの棚卸しと台帳登録です。

「SBOMを作れば全部わかる」という思い込みを試すのがこの設問の狙いです。SBOMの守備範囲と資産管理台帳の守備範囲は違う、という線引きを持っておきましょう。

設問3の回答例

（1）利用するソフトウェアとバージョンが一覧化され、脆弱性公表時に影響範囲を迅速に特定できるから（45字）

SBOMの定義を書く設問ではありません。聞かれているのは「脆弱性管理がなぜ容易になるか」という効果です。答えの骨格は、一覧化されている（原因）→影響範囲を迅速に特定できる（結果）という因果です。事例で「影響有無の判定に2週間かかった」と書かれているのは、この因果を逆から示すための伏線です。

SBOMそのものの仕組みや標準フォーマット、OSSの脆弱性管理の全体像はサプライチェーン攻撃とSBOMの記事で詳しく扱っています。本記事では、午後で聞かれる「使い方」の側だけに絞ります。

（2）操作を行った利用者を特定できず、責任追跡性が確保できない（28字）

共用アカウントの問題は必ずここに帰着します。ログには「dev-team がソースコードを変更した」としか残らず、U社の誰なのかV社の誰なのかが分かりません。責任追跡性（accountability）が確保できない、と一言で書けると強いです。

なお、パスワードが共有されるので退職者が使い続けられる、最小権限が適用できない、といった派生の問題もあります。ただし監査指摘としての本丸は「行為者を特定できないこと」なので、30字という短い枠ではそこに集中させます。

設問4の回答例

（1）踏み台サーバから開発環境への接続先と実行した操作のログ（27字）

踏み台サーバのログイン記録だけでは「入ったこと」しか分かりません。インシデント時に必要なのは「入ってから何をしたか」です。踏み台サーバは開発環境への唯一の入口なので、ここで接続先と操作内容を記録しておけば、開発環境側の全サーバにログ基盤を入れなくても追跡できます。踏み台サーバを置く価値は、アクセス経路を絞ることと、その1点でログを集約できることの両方にあります。

（2）

• 開発者の端末で実行する場合：コードを書いた直後に脆弱性を検出でき、その場で修正して手戻りを小さくできる（37字）
• CI/CDパイプライン上で実行する場合：CI/CDの管理機能で自動実行でき、実行漏れなくコード全体を検査できる（35字）

この設問は「どちらが正しいか」ではなく「それぞれの利点は何か」を聞いています。軸はタイミングと自動化の2つです。端末での実行は、書いた直後に気づけるぶん手戻りが小さい。パイプライン上の実行は、気づくのは遅れる代わりに管理機能で自動実行されるので、人が実行を忘れても必ず走ります。

なお事例に「ツールFはコンパイルエラーが解消されたソースコードでなければ正常に検査できない」とあったのは、書きかけのコードにいきなり流しても意味がないという制約を示す伏線です。開発者端末で実行する場合も、コンパイルが通る状態まで書いてから実行する運用が前提になります。

採点ポイント

加点される要点

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

• 同等の（再委託先に要求する対策の水準）
• 企画・設計工程から（セキュリティ・バイ・デザインの時制）
• 自社の管理下に配置する（外部依存を減らす方向性）
• 読み込む箇所を削除する（応急対応の具体性）
• 一覧化される／影響範囲を特定できる（SBOMの効果）
• 利用者を特定できない（共用アカウントの本質）
• 操作内容のログ（ログイン記録との差分）
• 早期発見／自動実行による実行漏れ防止（SASTの2つの実行場所）

どれも派手な攻撃名ではなく、管理の言葉です。午後問1系の設問は、こうした管理用語を自分の言葉ではなく試験の言葉で書けるかを見ています。

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

「セキュリティを考慮する」で止まる。 セキュリティ・バイ・デザインの説明で最も多い失点です。いつの工程で、何を、どうするのかが入っていないと、ほぼ0点になります。

再委託先に「T社が直接指導する」と書く。 契約関係がないので実行できません。統制は委託先U社を通じて、契約の連鎖で及ぼします。「誰と誰の間に契約があるか」を図に描いてから書くと防げます。

外部スクリプト対策をWAFやサーバ側の対策で答える。 前述のとおり、外部スクリプトの取得はT社のネットワークを通りません。事例の構成を読み違えたまま知識で答えると、まとめて落とします。

SBOMの定義を書いてしまう。 「ソフトウェア部品表のこと」と書いても、聞かれているのは効果なので加点されません。定義を答えさせる設問と効果を答えさせる設問を読み分けてください。

共用アカウントの問題を「パスワード漏えいの危険がある」と書く。 間違いではありませんが、監査指摘の文脈で問われているときの本命は責任追跡性です。

SASTの利点を「脆弱性が見つかる」と書く。 どちらのタイミングでも脆弱性は見つかります。タイミングによる差を書かなければ、2つの解答欄が同じ内容になってしまいます。

字数調整のコツ

30字前後の設問は、要素1つを具体的に書き切るだけで埋まります（理由まで入るのは「〜だから」型の設問だけです）。45字から50字の設問は、要素2つを「及び」「ので」でつなぐか、1つの要素を「何を・誰に・どうさせる」まで書き切るかのどちらかで埋まります。字数が足りないときは主語を補い、はみ出すときは「〜すること」を「〜する」に、「〜しているソフトウェア」を「〜するソフトウェア」に縮めます。固有名詞（T社、スクリプトP、ツールF）は短いので、迷ったら入れておくと採点者に伝わりやすくなります。

頻出パターン

委託の階層を問う型

「再委託先にどう要求を及ぼすか」は、サプライチェーンをテーマにした午後問題の定番です。解答の引き出しは3つ用意しておきます。再委託には委託元の事前承諾を要すること、再委託先にも委託先と同等の対策を要求させること、再委託先での実施状況を委託先経由で報告・確認できるようにすることです。契約の連鎖でしか統制できない、という原則を押さえていれば応用が効きます。

外部依存の可視化を問う型

自社が知らないうちに依存している外部のものをどう把握するか、という型です。OSSライブラリはSBOM、外部配信スクリプトやSaaSは資産管理台帳への登録、公開資産全般は外部からの棚卸しと、対象ごとに手段が違うことを整理しておきます。「SBOMで全部カバーできる」と思い込んでいると、本問の設問2(3)のような設問で必ず落とします。

ログの取得対象を問う型

「ログは取っています」と事例に書いてあるときほど、何のログかを確認してください。認証ログ（誰が入ったか）、操作ログ（何をしたか）、通信ログ（どこへつないだか）は別物です。設問は「不足しているログ」を聞いてくるので、事例に書かれているログの種類を読み取り、その補集合を答えることになります。共用アカウントの論点と組み合わさると、「ログはあるが人が特定できない」という二段構えの指摘になります。ログの種類ごとの読み方はログ解析の完全ガイドでも整理しています。

検査の実施タイミングを問う型

SASTに限らず、レビュー、DAST、ペネトレーションテスト、脆弱性診断のいずれについても「いつ実施するか」で利点が変わります。上流ほど手戻りが小さく、下流ほど実際の動作に近い状態を検査できる、という軸を1本持っておけば、初見のツールが出てきても書けます。セキュリティ・バイ・デザインの考え方そのものはセキュリティバイデザインとDevSecOpsの記事で扱っています。

用語の定義を問う型

セキュリティ・バイ・デザインのように、カタカナの考え方を日本語で説明させる設問は毎回のように出ます。用語集を眺めるだけでなく、30字程度で説明する練習をしておくと、本番で手が止まりません。定義を答える設問では、必ず「いつ・何を・どうする」の3要素が入っているかを見直してください。

まとめ：サプライチェーンは「誰が持っているか」を書き出せた範囲しか守れない

令和7年春 午後問1は、攻撃手法ではなく管理の抜け漏れに点がある問題でした。骨格は3つです。委託は契約とガイドラインで再委託先まで同じ水準を要求すること、外部依存は資産管理台帳とSBOMで「使っているもの」を一覧化してから脆弱性対応につなげること、そして開発現場の統制は共用アカウント・踏み台・コード検査ツールを「誰が・いつ・何をしたか」が残る形で回すことです。

CIOだった頃、機密情報のアクセス権を設計しようとして最初にぶつかったのは、権限の話ではなく情報の格付けが存在しないことでした。守る対象が定義されていないのだから、誰に何を許すかも決めようがない。結局、情報分類の定義づくりに一番長い時間を使いました。資産管理台帳もSBOMも、やっていることは同じです。守る前に、まず持ち物を書き出す。台帳が整っていない組織では、脆弱性情報が公開されても「うちは影響を受けるのか」に答えられません。

午後の記述でこのテーマが出たら、対策の名前を並べるのではなく「その統制が、何を・いつ・どこまでやってくれるのか」まで書き切ってください。契約とガイドラインは再委託先に同じ水準を要求し、遵守状況を確認できる根拠にするもの。台帳と定期棚卸しは、把握していない外部スクリプトの読み込みを検知して管理下に戻すもの。SBOMは脆弱性情報が出たときに影響範囲を特定するためのもので、脆弱なコードを実際に食い止めるのは上流でのコード検査と是正プロセスです。可視化する統制と、止める統制は別物。この切り分けが頭に入っていれば、初見の事例でも解答欄は埋まります。

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

参考資料

• 情報処理安全確保支援士試験（IPA）
• 令和7年度春期 情報処理安全確保支援士試験 午後 解答例（IPA・PDF）

事例解説シリーズ

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