令和7年度 春期 情報処理安全確保支援士試験 午後 問1｜サプライチェーン攻撃から金融系システム開発を守る——情報処理安全確保支援士で学ぶSBOM・SAST・再委託先管理の実務

この記事で扱うセキュリティ事例

• 試験区分: 情報処理安全確保支援士

• 出典: 令和7年度 春期 情報処理安全確保支援士試験 午後 問1

• 主なテーマ: サプライチェーンリスク、セキュリティ・バイ・デザイン、SBOM、CI/CDとSAST、委託先・再委託先管理、踏み台サーバと共用アカウント

この記事は「情報処理安全確保支援士 午後問題 全70問」シリーズの1本です。→ 全70問の一覧・テーマ別索引はこちら

導入: なぜこの事例が重要なのか

「自社のコードは安全に書いた。だからシステムは安全だ」——この前提が、近年もっとも危うくなっています。攻撃者は、堅牢に守られた本丸を正面から狙うのではなく、その本丸が依存している外部の部品やサービス、あるいは開発を請け負った委託先を経由して侵入してくるようになりました。これがサプライチェーン攻撃（供給網のどこか一点を侵害し、そこを足がかりに本来の標的へ到達する攻撃）です。

IPA（独立行政法人情報処理推進機構）の「情報セキュリティ10大脅威」組織編には、サプライチェーンに関連する脅威が7年連続でランクインしています。つまりこれは一過性の流行ではなく、構造的に増え続けている脅威だということです。

情報処理安全確保支援士試験の令和7年度春期・午後 問1は、まさにこのテーマを正面から扱いました。金融業向けにシステムを開発するL社が、サプライチェーンリスク対策を強化するためにセキュリティガイドラインを作り、全プロジェクトを点検していく——という、攻撃を受けてから慌てるのではなく「攻撃される前に弱点を潰す」予防的な物語です。SBOM（ソフトウェア部品表）、SAST（静的アプリケーションセキュリティテスト）、CI/CDパイプライン、再委託先管理といった、いま現場で問われている言葉が次々と登場します。受験者にとっても実務者にとっても、知識の地図を一枚作るのに格好の題材です。

インシデントの概要

舞台はL社。金融業向けにシステムを開発している、従業員1,000名の企業です。金融系というだけで、扱うシステムには高い安全性と信頼性が求められます。

L社のシステム開発プロジェクトでは、プラットフォームGというソフトウェア開発プラットフォームを使っていました。このプラットフォームGには、ソースコードや開発ドキュメントのバージョンを管理する機能、CI/CDパイプライン（ビルド・テスト・デプロイといった開発工程を自動化する仕組み）の管理機能、そして開発対象のSBOM（Software Bill of Materials。利用しているOSSやライブラリとそのバージョンを一覧化した「部品表」）を作成する機能が備わっていました。CI/CDパイプラインの管理機能を使えば、テストやリリースを自動で実行できます。ただしSBOM作成機能は、現状では特に使われていませんでした。

加えてL社は、SASTツール（以下、ツールF）を採用していました。SAST（Static Application Security Testing。ソースコードを実行せずに静的に解析してセキュリティ上の欠陥を探す手法）のツールであるツールFは、プラットフォームG上のリポジトリサーバや開発者の端末にインストールして使うもので、コンパイルエラーが解消されたソースコードに対してだけ正常な検査ができる、という特性を持っていました。そしてプラットフォームGのCI/CDパイプライン管理機能を使えば、ツールFでのチェックを自動的に行うワークフローも組めます。

ここで経営陣が動きます。業務委託先でのセキュリティ侵害に起因する情報セキュリティインシデントが大きく報道されるなど、外部環境が変化したことを受けて、L社経営陣はサプライチェーンリスク対策の強化を考えるようになりました。経営陣の指示で、情報セキュリティ担当のBさんが、サプライチェーンリスク対策を強化したセキュリティガイドライン（以下、ガイドライン）を作成し、全てのシステム開発プロジェクトと運用サービスを点検することになります。Bさんは独力で抱え込まず、L社が契約しているセキュリティコンサルタントで、情報処理安全確保支援士（登録セキスペ）のD氏に相談することにしました。

何が起きたのか

物語は三つの段階で進みます。「ガイドラインを作る」「過去のインシデントに照らして有効性を検証する」「実際に動いているシステムSを点検する」——この順に、サプライチェーンの弱点が一つずつ浮き彫りになっていきます。

ガイドラインを作る

BさんはまずD氏に、ガイドラインの構成を相談します。D氏の助言は明快でした。「システムライフサイクルの工程に合わせるのがよい」。L社のシステム開発業務を踏まえ、調達・開発・リリース／デプロイ・運用という工程に分類し、さらに全工程に共通する項目も抜き出して記載する——この方針です。

これを受けてBさんが作ったガイドライン案（表1）は、工程ごとに対策を並べたものでした。共通項目には「情報資産を業務委託先と共同利用するものも含めて一覧化・管理する」「各工程のアカウントは必要な利用者にだけ発行し、責任追跡性を確保するため利用者を特定できるようにする」「情報資産ごとにパッチ適用状況など最新の構成情報を把握する」といった内容が並びます。調達工程には「業務委託先の企業を、再委託先まで含めて一覧管理する」「業務委託先でのセキュリティ管理に関する要件を契約に含める」。開発工程には「開発プラットフォームへのアクセス制御」「アクセスログの記録」「ソースコードの人手レビューおよびSASTツールでのチェック」「設計段階で不要な機能やセキュリティ上の欠陥がないか確認する」。リリース・デプロイ工程には「開発したソフトウェアのSBOMを作成する」「リリースしたソフトウェアのリリースバージョンを管理する」。運用工程には監視やアクセス制御、入退室管理、インシデント対応手順書の作成が含まれていました。

D氏はこの案を見て、二つのコメントを返します。一つは、Bさんがすでに「セキュリティ・バイ・デザイン（企画・設計の段階からセキュリティを組み込む考え方）」を一部取り入れている点への評価。もう一つは改善提案で、「業務委託先が再委託を行う場合に備えて、L社と業務委託先との間の契約書に明記すべき事項を具体的に示しておくとよい」というものでした。委託先だけでなく、その先の再委託先まで責任の鎖をつなぐ——ここが最初の論点です。

過去のインシデントに照らして検証する

修正したガイドライン案を経営陣に報告すると、新たな指示が下ります。「過去に外部ベンダーでのセキュリティ侵害に起因してL社で起きたインシデントに対し、このガイドラインが有効かを評価せよ」。

BさんとD氏が確認した1件目のインシデントは、サプライチェーン攻撃の典型でした。L社が開発・運用していたシステム（システムQ）は、古いWebブラウザをサポートするためにJavaScript（スクリプトP）を利用していました。スクリプトPは当時広く使われていたT社製のもので、T社が運営するサーバT上に置かれ、システムQにアクセスしたWebブラウザがそのスクリプトPを都度読み込むよう構成されていたのです。

ある日、そのサーバTが乗っ取られます。スクリプトPが改ざんされたことによって、システムQの利用者のアクセスが、悪意のあるWebサイトにリダイレクト（自動的に別のURLへ転送）させられてしまいました。利用者からの問合せで気付いて対策を打ちましたが、当時の情報セキュリティ担当は、サーバTが侵害されたというニュース自体は知っていたものの、それがシステムQに影響するとは把握していませんでした。「外部の部品が侵害されると、それを読み込んでいる自社システムまで危なくなる」——この想像力の欠落が、被害を広げた点に緊張感があります。

D氏はここで本質を突きます。「他社の発表によると、スクリプトPを利用していたシステムでも、スクリプトPの配置方法が違えば影響を受けなかったようですね」。つまり、外部サーバから都度読み込むのではなく、別の配置にしていたシステムは被害を免れていた、ということです。L社が実際に取った対策は少し別の角度でした。Webブラウザ開発元での古いWebブラウザの公式サポートが終了していたことから、システムQのソースコードに変更を加えて、古いWebブラウザのサポート自体を終了したのです。

そしてもう一つ、SBOMとの関係も検証されます。Bさんは「ガイドライン案の項番10（SBOM作成）が、このインシデントを未然に防ぐのに有効では」と考えました。しかしD氏は冷静に否定します。「いいえ、SBOM作成機能でSBOMを作っていたとしても、スクリプトPはSBOMに含まれないので、インシデントは防げなかったでしょう」。プラットフォームGのSBOM作成機能は、リポジトリサーバ内のソースコードやライブラリを一覧化するもの。外部サーバから都度読み込む外部スクリプトは、自社リポジトリの構成要素ではないため、SBOMには載らないのです。この指摘を受けてBさんは、SBOM以外の手段で「システムが利用している外部のスクリプトを把握できるよう」、ガイドライン案の項目を一つ修正しました。

実際のシステムSを点検する

ガイドラインの準備が整い、いよいよ現在進行中のプロジェクトの点検です。最初の対象は、システムSの開発プロジェクトと運用サービスでした。

システムSは、L社が3年前からS銀行向けに提供しているインターネットバンキングシステムです。運用と追加機能の開発をL社が請け負っています。開発は、L社の従業員、L社に派遣された派遣エンジニア、そして他の業務委託先の従業員が行っており、運用ツールなど一部のソフトウェアはN社が開発することがありました。N社との業務委託契約には、N社内のセキュリティ管理の実施事項とともに、N社が再委託を行わないことが明記されています。

開発環境にも特徴がありました。開発は、L社内の従業員LAN、L社内のパートナーLAN、オフショア拠点にある業務委託先のLANに接続した端末で実施されます。テストなどのために開発系サーバがあるLAN（開発LAN）へアクセスするには、いったん踏み台サーバ（内部ネットワークへ入る際に経由させる中継用サーバ）にログインする必要がありました。ここで問題が潜んでいます。踏み台サーバには、L社や業務委託先など会社ごとに発行した共用アカウントでログインし、ログインごとに利用記録簿に記載する運用になっていたのです。つまり、誰が操作したかをアカウント単位では特定できない状態でした。さらに開発LAN上のサーバには製品仕様しかなく、アクセスログが取れないものもありました。

そのほかにも点検で見えた弱点があります。システムSに組み込むOSSライブラリは開発者が取得していましたが、資産管理台帳には入力していませんでした。SBOMも作成していません（図1の項番6で「SBOMは作成しない」とされていました）。Bさんは、システムSの担当者Cさんへのヒアリング前に、表1の各項番について図1の記述に基づいて対策状況を整理し、その結果を表2にまとめました。

ヒアリングで論点を詰める

ヒアリングでまず話題になったのはSBOMです。Cさんは「システムSのソフトウェア構成は設計書で把握できると考えているが、SBOMの作成も必要か」と問いました。Bさんの答えは「SBOMを利用すると、将来、脆弱性管理がしやすくなる。プラットフォームGで作成できる」。設計書という静的な文書ではなく、機械可読な部品表を持つことの意味が、ここで効いてきます。

次に開発工程のアクセス対策です。表1の項番7（アクセスログの記録）について、Cさんは「オフショア拠点から開発LANへのアクセスはVPN-GW（VPNゲートウェイ）でアクセスログを取得できているが、社内からのアクセスについては取得できていない」と明かします。Bさんは「アクセスログは図2中の踏み台サーバで取得するのがよい」と助言しました。社内からのアクセスも必ず踏み台サーバを経由するため、そこでログを取れば抜けがなくなる、という発想です。

最後にSASTの組み込みです。表1の項番8について、現在はソースコードの変更内容を開発リーダーがレビューしているだけでした。Bさんは「開発リーダーのレビューに加えて、ツールFでチェックするのがよい」と提案します。Cさんが「開発フローのどこでツールFを実行すればよいか」と尋ねると、Bさんは図3のシステムSの開発フロー中の「（あ）または（い）で実行するのがよく、それぞれ利点が異なる」と答えました。図3を見ると、（あ）は開発者の端末側でコンパイル実行（1）の後・開発者によるテストの前、（い）はプラットフォームG側でコンパイル実行（2）の後・開発リーダーによるレビューの前に位置しています。

ガイドラインを用いた点検を経て、L社のサプライチェーンリスク対策は強化されました。