情報処理安全確保支援士試験 令和７年春午後問１の問題解説

R7春 午後Ⅰ 問1「サプライチェーンリスク対策」—問題文のていねい解説

1) 物語の設定（登場人物とシステム）

L社は外部ベンダーやオフショア拠点も関わる開発・運用体制を持ち、設計書は「プラットフォームG」に保存、静的解析ツール「F」は開発端末とプラットフォームGに導入されています（Fは“ビルドが通ったソースに対してのみ”正常検査可。CI/CD管理機能で自動化も可能） 。
経営陣の指示で、情報セキュリティ担当Bさんは登録セキスペのD氏と一緒に、サプライチェーンリスク対策を強化した社内ガイドラインを作る流れです 。

2) ガイドラインの骨子（表1）

ガイドラインは「共通・調達・開発・リリース／デプロイ・運用」というライフサイクル工程別に並ぶ構成です 。抜粋の主な項目は次のとおり：

• 共通：アカウントは必要最小限に発行し、責任追跡性（誰が使ったか特定可能）を確保／情報資産を一覧化し構成情報を最新把握／業務委託先～再委託先まで一覧管理／委託先のセキュリティ要件を契約に明記／開発環境のアクセス制御とアクセスログ記録 。

• 開発：レビュー＋SASTの二重チェック／設計書で不要機能や欠陥がないかを確認 。

• リリース・デプロイ：SBOM作成、リリース版のバージョン管理 。

• 運用：稼働監視／アクセス制御／入退室管理／インシデント対応手順書整備 。

この「再委託」や「共同利用資産」まで視野を広げる粒度が、本問のサプライチェーン対策の肝です（表1の見出しにも“共同で利用するものも含めて一覧化”の文言） 。

3) 図1の要点（体制・運用の実情）

• 運用拠点：S銀行のセキュアルームに入退室装置（カード認証）を導入し、入室者を限定。物理面の統制が効いている設定です 。

• 契約：N社との契約では、L社のポリシー順守や再委託禁止を明記し、監査で順守確認まで実施 。

• 開発プロセスの現状：設計書はプラットフォームGへ格納。ただしSBOMは未作成。レビューは開発リーダーの人手中心、リリース版はリーダーが更新管理する等、やや属人的な運用が残る描写です 。

• 資産管理とOSS：サーバ／NW機器は台帳登録するが、OSSライブラリは開発者が取得し台帳未登録という弱点が示されます 。

• ネットワークと踏み台：開発LANへは踏み台サーバ経由で入り、会社ごとの共用アカウントでログイン（手書きの利用記録簿）。一部サーバはアクセスログが取れない制約も言及 。

• ツール配置：ツールFは開発端末とプラットフォームGに導入済み 。

これらの「現状の穴」（SBOM未作成／OSSの未管理／共用アカウント／ログの欠落）に、後段の設問が刺さってきます。

4) 「過去のインシデント」の確認（設問2につながる背景）

事件：T社が運営するサーバTに置いてあったスクリプトP（古いブラウザ対応用）が改ざんされ、利用者が悪性サイトへリダイレクトされる事象が発生。L社のシステムQは都度外部から読み込む構成だったため、影響を受けました 。
発見経緯：ユーザ問合せで発覚。担当者は「サーバT侵害」のニュース自体は知っていたが、「自社システムも影響を受ける構成」だと結び付けられなかった点が課題として示されます 。
示唆：他社の発表では、配置方法が違えば影響なし、という含み。つまり「外部ホスト依存か、内部配置か」が被害有無を分け得るという、サプライチェーン（外部依存）設計の勘所を押さえさせる狙いです 。

5) 点検の実施（設問3～5の足場）

• SBOMの是非：Cさんは「設計書で把握できるのでは？」と問うが、Bさんは将来的な脆弱性管理がしやすいこと、プラットフォームGで作成可能であることを理由にSBOM作成を勧めます。ここで「SBOM未作成」という現状と、表1「10. SBOM作成」の項目がつながります 。

• アクセスログの取り方：オフショア→社内のアクセスログはVPN-GWで取れているが、社内からのアクセス分が未取得。Bさんは図2中の“d”でログ取得を提案。図1の描写から“d”が何を指すかを読み解く力が問われます（後の設問関連） 。

• ツールFを流れのどこで回すか：図3の開発フローには(あ)/(い)という二つの差し込みポイントが示され、「特性を踏まえればどちらにも利点がある」と書かれています（早期検出 vs パイプライン自動実行など、トレードオフを考える設問へ） 。

6) 設問の狙い（どの“文言”が点になるかの道しるべ）

本文末に見出しだけ並ぶ設問構成は次のとおり。答え方の型をイメージして読むと拾うべき根拠が見つけやすくなります。

• 設問1：ガイドライン作成
  ①「セキュリティ・バイ・デザイン」の考え方の定義を端的に／②再委託に備えて契約に明記すべき事項を具体的に（表1の“契約に含めること”や“再委託まで管理”の文言がヒント） 。

• 設問2：過去のインシデント確認
  ③ スクリプトPが影響を受けない“配置方法”（本文の「外部から都度読み込む構成」が問題の根因）を答える／④ ソース側の変更で再発防止（本文の構成を踏まえて“どこをどう変えるか”）／⑤ ガイドラインどの項番をどう修正すべきか（「共同利用資産」や「外部サービス連携」まで管理対象に含める観点が本文に散りばめられています） 。

• 設問3：点検の実施
  「図2の a〜e を、表1のどの項番に対応付けるか」「a/b/cの観点で問題点の有無」など、工程別のガイドラインと現場実装のひも付けが問われます（“dでログ取得”指示や“共用アカウントと責任追跡性の齟齬”がヒント） 。

• 設問4：SBOMの効果
  SBOMをなぜ作るのか（本文のやり取り＋表1の位置付け）から、脆弱性対応の俊敏性へ結びつけます 。

• 設問5：ツールFの実行位置
  図3の(あ)/(い)それぞれの利点を、検出の早さやCI/CDによる自動化の観点で整理（ツールFの特性記述が根拠） 。

なお、試験全体の出題趣旨は「サプライチェーンリスク対策の知識・侵害発生時の対策検討能力」を問うことにあります。本文の“外部依存の棚卸（共同資産・外部サービス）”と“契約・監査・技術対策（ログ、SBOM、SAST、CI/CD）”の両輪で読むのがコツです。

7) 用語の確認（本文の理解に必須）

• セキュリティ・バイ・デザイン：企画・設計段階からセキュリティ要件を埋め込む考え方。後付け修正ではなく、最初から“作り込み”。

• SBOM：ソフトウェア部品表。利用しているOSSやコンポーネントとバージョンを可視化し、脆弱性情報の当たりを付けやすくする。本文では「プラットフォームGで作成可能」と示唆あり 。

• SAST：ソースを静的解析。ビルド成功後のコードに対して正しく動くツールFの特性が本文に明記 。

• 責任追跡性：誰がどのアカウントで何をしたかを追えること。共用アカウントと両立させるには“発行・利用のひも付け”やアクセスログがカギ（表1“アカウント特定”“アクセスログ記録”） 。

---

まとめ（読み方の指針）

1. 工程別ガイドラインの各項目を本文の現状描写にマッピングし、ズレ（不足）を見つける。

2. **外部依存（CDN／外部JS／再委託）**は“自社外でも管理対象”として捉える。

3. CI/CD×SAST×SBOM×ログの位置付けを、早期検出・自動化・可視化・追跡の観点で整理する。

この視点で本文の該当記述を拾えば、各設問で問われる「配置方法」「契約に明記」「どの項番をどう直す」が自然に導ける構造になっています。