情報処理安全確保支援士試験では、近年サプライチェーン攻撃に関する出題が増加しています。自社システムを堅牢に守っていても、信頼している開発ツールやライブラリに脆弱性があれば、攻撃者はそこを突いて侵入してきます。
本記事では、サプライチェーン攻撃の仕組みから実際の被害事例、そしてOSS（オープンソースソフトウェア)の脆弱性管理やSBOM（ソフトウェア部品表）を活用した最新の防御策まで、試験対策に必要な知識を体系的に解説します。
サプライチェーン攻撃とは何か
サプライチェーン攻撃とは、攻撃者が直接ターゲット企業を狙うのではなく、その企業が信頼している供給網（サプライチェーン）を経由して侵入する攻撃手法です。
従来、サプライチェーンは製造業や物流分野で使われる用語でしたが、ITセキュリティにおいては「ソフトウェアやハードウェアが開発され、ユーザーの手元に届き、運用されるまでの一連のプロセス」を指します。
攻撃者は、セキュリティ対策が強固な本丸を避け、以下のような信頼関係を悪用します。
- ソフトウェアベンダーの開発環境
- クラウドサービス事業者のインフラ
- システム保守業者のアクセス権限
- OSSコミュニティが管理するライブラリ
正門を厳重に守っていても、信頼している宅配業者の荷物に時限爆弾が仕込まれていれば防ぎようがありません。これがサプライチェーン攻撃の本質です。
ソフトウェアサプライチェーンの3つの攻撃ポイント
ソフトウェア開発のライフサイクルには、攻撃者が狙う主要なポイントが3つ存在します。
1. 開発環境・ソースコードリポジトリへの侵入
攻撃者は開発者のPCをマルウェアに感染させたり、GitHubなどのリポジトリ認証情報を窃取して、正規のソースコードにバックドアを埋め込みます。
開発段階での混入は発見が困難で、正規の開発プロセスを経てリリースされるため、検知されにくい特徴があります。
2. ビルドプロセスの乗っ取り
CI/CD（継続的インテグレーション/継続的デリバリー）パイプラインやビルドサーバーを侵害し、コンパイル時に不正なコードを注入する手法です。
ソースコードは正常でも、ビルド過程で悪意あるコードが追加されるため、ソースレビューだけでは防げません。
3. アップデート配信経路の改ざん
完成したソフトウェアを配布するサーバーをハッキングし、正規のアップデートファイルに見せかけたマルウェアを配布します。
ユーザーは信頼している公式サイトから「正規の更新」として悪意あるファイルをダウンロードしてしまいます。
実際に起きた重大インシデント
試験対策として、実際の攻撃事例を理解しておくことは重要です。具体的な手口を知ることで、対策の必要性が明確になります。
SolarWinds事件（2020年）
ネットワーク管理ソフト「Orion」の正規アップデートに、攻撃者がバックドア「Sunburst」を混入させた事件です。
このソフトは米国政府機関や大企業で広く使用されていたため、正規の更新プロセスを通じて世界中の組織が感染しました。重要なのは、正規のデジタル署名が付与されていた点です。そのため、セキュリティソフトでも検知が極めて困難でした。
Codecov事件（2021年）
コードカバレッジ測定ツール「Codecov」のアップローダースクリプトが改ざんされた事件です。
利用者のCI/CD環境から、AWSのアクセスキーやデータベースパスワードなどの環境変数が外部に送信されるコードが埋め込まれました。多くの企業の機密情報が流出の危機に直面しました。
これらの事例に共通するのは、信頼していた正規ツールやプロセスが悪用されたという点です。従来の境界防御では防げない攻撃であり、「信頼するが検証する」あるいは「決して信頼せず常に検証する(Zero Trust)」のアプローチが必要になります。
OSSの脆弱性管理が重要な理由
現代のソフトウェア開発では、全てのコードを自社で書くことはほぼありません。Webフレームワーク、暗号化ライブラリ、ログ出力ツールなど、多くの機能がOSS(オープンソースソフトウェア)に依存しています。
一説には、現代アプリケーションコードの80〜90%がOSSで構成されているとも言われます。この恩恵の裏側に、深刻なリスクが潜んでいます。
推移的依存関係(Transitive Dependencies)の問題
OSSを利用する際、そのOSS自体が別のOSSを利用していることが一般的です。これが「推移的依存関係」と呼ばれる構造です。
- アプリケーションAは、ライブラリBを利用
- ライブラリBは、ライブラリCを利用
- ライブラリCは、ライブラリDを利用
開発者はライブラリBしか意識していなくても、ライブラリDに脆弱性が見つかれば、アプリケーションA全体が危険に晒されます。
Log4Shellの衝撃
2021年末に発覚したJavaのログ出力ライブラリ「Apache Log4j」の脆弱性(Log4Shell)は、このリスクを世界中に知らしめました。
Log4jはあまりに基本的かつ広範に使われていたため、影響範囲は計り知れませんでした。多くの企業が「自社システムでLog4jを使っているか?」という問いに即答できず、調査に膨大な時間を要しました。
「直接は使っていないが、利用しているミドルウェアに埋め込まれていた」というケースが多発したのです。
OSSを狙う攻撃手法
脆弱性の発見だけでなく、攻撃者が意図的にOSSエコシステムを汚染する攻撃も増加しています。
タイポスクワッティング(Typosquatting)
人気ライブラリ名に酷似した名前で悪意あるパッケージを登録し、開発者の入力ミスを待ち構える手法です。
例えば、reactに対してrceact、requestsに対してrequestなど、一文字違いや複数形・単数形の違いを利用します。開発者が誤ってインストールすると、マルウェアが実行されます。
依存関係混乱(Dependency Confusion)
企業が内部で使用しているプライベートパッケージと同名のパッケージを、公開リポジトリ(npmやPyPIなど)に登録する攻撃です。
攻撃者はバージョン番号を極端に高く設定します。パッケージマネージャの設定によっては、バージョンの高い公開パッケージを優先的にダウンロードしてしまい、社内システムにマルウェアを引き込んでしまいます。
依存関係混乱の具体的なメカニズム
この攻撃の恐ろしい点は、高度なエクスプロイトコードを必要とせず、設定ミスや仕様の穴を突く点にあります。
- 企業は社内専用ライブラリ(例:
internal-auth-lib)をプライベートリポジトリで管理 - 攻撃者がこのライブラリ名を何らかの方法で特定(誤って公開された
package.jsonなど) - 同名パッケージをパブリックリポジトリに登録し、バージョン番号を極端に高く設定(例:
99.9.9) - 開発者が
npm installを実行すると、「より新しいバージョン」が優先され、悪意あるパッケージがインストールされる
対策として以下が有効です。
- スコープ付きパッケージの使用:
@mycompany/internal-libのように名前空間を区切る - プライベートリポジトリの優先設定:外部リポジトリへのフォールバックを無効化
- パッケージマネージャの設定見直し:明示的に内部リポジトリのみを参照
SBOM(ソフトウェア部品表)による可視化
「何が使われているか分からない」状況を打破するために導入が進んでいるのが、**SBOM(Software Bill of Materials:ソフトウェア部品表)**です。
SBOMとは
SBOMは、ソフトウェアに含まれる全てのコンポーネント(ライブラリ、モジュール、ミドルウェアなど)のリストです。食品パッケージ裏の「原材料名・アレルギー表示」に例えられます。
SBOMに含まれる情報:
- コンポーネント名(例:Apache Struts)
- バージョン(例:2.3.5)
- ライセンス情報(MIT、GPLなど)
- 依存関係(どのコンポーネントが何に依存しているか)
- 発行者・供給者情報
- ハッシュ値(改ざん検知用)
SBOMのメリット
新たな脆弱性が発見された際、自社のどのシステムのどこに該当ライブラリが含まれているかを即座に特定できます。これにより、迅速なパッチ適用や回避策の実施が可能になります。
Log4Shell発覚時、SBOMを整備していた組織は数時間で影響範囲を特定できましたが、未整備の組織は数週間を要しました。この差が事業継続に直結します。
代表的なSBOMフォーマット
試験対策として覚えておくべきSBOM標準フォーマットは主に2つです。
SPDX(Software Package Data Exchange)
Linux Foundation傘下のプロジェクトで策定され、ISO/IEC 5962として国際標準化されています。
ライセンス管理に強みを持ちますが、セキュリティ情報の記述も充実しています。歴史が長く、多くのツールがサポートしています。
CycloneDX
OWASP(Open Web Application Security Project)が主導するフォーマットです。
アプリケーションセキュリティやサプライチェーンコンポーネント分析に特化しており、軽量で自動化処理に向いています。セキュリティ用途では特に人気が高まっています。
どちらが優れているということはなく、ツールや取引先の要件に合わせて選択します。重要なのは「SBOMを作成・管理する体制」であり、フォーマット選択は二次的な問題です。
サプライチェーン攻撃への具体的対策
サプライチェーン攻撃への対策は多層的なアプローチが必要です。単一の対策では不十分であり、技術的対策と組織的対策を組み合わせます。
1. SLSA(Supply-chain Levels for Software Artifacts)
Googleが提唱したSLSA(サルサ)は、ソフトウェア供給源の完全性を保護するためのセキュリティレベルを定義したフレームワークです。
SLSAが確認する主要項目:
- ソースコードの変更履歴が改ざん不可能な状態で保存されているか
- ビルドプロセスが自動化され、人間の不正な介入がないか
- ビルド環境が外部ネットワークから隔離されているか
- ビルド時に使用した全ての依存関係が記録されているか
これらをチェックし、ソフトウェアが「正しい手順で、正しいコードから作られたこと」を証明します。SLSAはレベル1からレベル4まで段階的に定義されており、組織は自社の成熟度に応じて実装を進めます。
2. SCA(Software Composition Analysis)ツール
SBOMを作成するだけでは不十分です。SBOMと脆弱性データベース(NVDやJVN)を自動的に突き合わせる仕組みが必要であり、これをSCAツールが提供します。
SCAツールの機能:
- 依存ライブラリの自動検出とSBOM生成
- 既知脆弱性データベースとの照合
- ライセンスコンプライアンスチェック
- リスクスコアリングと優先順位付け
SCAツールをCI/CDパイプラインに組み込むことで、ビルドのたびに依存ライブラリをスキャンし、既知の脆弱性が含まれていればビルドを停止できます。これにより、脆弱なコードが本番環境に到達する前に阻止できます。
3. デジタル署名と検証
ソフトウェア配布元は、バイナリファイルにコードサイニング証明書でデジタル署名を行います。利用者はインストール前に署名を検証し、改ざんされていないこと、正しい発行元であることを確認します。
ただし、SolarWinds事件のように「署名プロセスそのもの」が乗っ取られるリスクもあります。そのため、署名に使用する秘密鍵の管理が最重要課題です。
秘密鍵管理のベストプラクティス:
- HSM(Hardware Security Module)の使用:秘密鍵を専用ハードウェア内で保護
- アクセス制御の厳格化:複数人承認制の導入
- 鍵の定期ローテーション:侵害時の影響範囲を限定
4. 最小権限の原則とネットワーク分離
万が一、悪意あるライブラリを取り込んでしまった場合に備え、被害を最小化する仕組みを用意します。
実装すべき対策:
- ビルドサーバーからのインターネットアクセス制限:ホワイトリスト方式で必要最小限の通信のみ許可
- サーバーの最小権限運用:必要最小限の権限(Least Privilege)で動作させる
- ネットワークセグメンテーション:開発環境と本番環境を分離
- 異常通信の監視:C&Cサーバーへの通信を検知
これにより、外部への情報流出や横展開(ラテラルムーブメント)を阻止できる可能性が高まります。
情報処理安全確保支援士試験での出題ポイント
サプライチェーン攻撃は、午前IIの知識問題だけでなく、午後試験の長文問題として出題されやすいテーマです。
午前II試験の重要キーワード
- SBOM、SPDX、CycloneDX:各用語の定義と違い
- サプライチェーン攻撃:標的そのものではなく供給網を狙う攻撃
- 水飲み場型攻撃との違い:水飲み場はWebサイト改ざん、サプライチェーンは製品・部品の汚染
- NVD(National Vulnerability Database):米国NISTが管理する脆弱性データベース
- CVSS(Common Vulnerability Scoring System):脆弱性の深刻度を0.0〜10.0で評価する共通基準
- SLSA:ソフトウェアサプライチェーンのセキュリティレベルを定義
午後試験の記述対策
午後試験では、以下のようなシチュエーションが想定されます。
シナリオ1: インシデント発生時の初動対応
問題例:「Apache Strutsの脆弱性が公開された。自社システムへの影響範囲をどう調査するか」
従来の解答:設計書を確認する、サーバー内のファイルを検索する
今後の模範解答:整備されたSBOMを参照し、該当バージョンの利用有無を即座に特定する。SBOMが未整備の場合は、SCAツールで緊急スキャンを実施し、依存関係を洗い出す。
シナリオ2: 開発環境のセキュリティ
問題例:「外部リポジトリからライブラリを取得する際のリスクと対策を述べよ」
模範解答:
- 社内にプロキシリポジトリ(アーティファクトリポジトリ)を設置
- 脆弱性検査済みのライブラリのみを開発者に提供
- ダウンロード時にハッシュ値を検証し、改ざんを検知
- 依存関係混乱攻撃への対策として、プライベートパッケージにはスコープを付与
シナリオ3: 委託先管理
問題例:「ソフトウェア開発を外部委託する際の契約上の留意点を述べよ」
模範解答:
- 脆弱性対応の責任範囲を明確化(発覚後◯日以内のパッチ提供など)
- 納品時のSBOM提出を義務化
- セキュアコーディング規約の遵守を要求
- 定期的な脆弱性診断の実施
- インシデント発生時の報告体制の確立
補足:重要な関連用語
試験対策として、記事中で詳しく触れられなかった重要キーワードを整理します。
NVD(National Vulnerability Database)
米国国立標準技術研究所(NIST)が管理する脆弱性データベースです。CVE(Common Vulnerabilities and Exposures)識別子に基づいて脆弱性の詳細情報を管理しています。
日本のJVN(Japan Vulnerability Notes)と連携しており、グローバルな脆弱性情報の集約拠点となっています。
CVSS(Common Vulnerability Scoring System)
脆弱性の深刻度を評価する共通基準です。以下の3つの基準でスコアリングされます。
- 基本値(Base Score):脆弱性固有の特性(攻撃の複雑さ、必要な権限など)
- 現状値(Temporal Score):時間経過による変化(攻撃コードの有無、パッチの有無など)
- 環境値(Environmental Score):各組織の環境における影響度
特に基本値はベンダーやNVDが算出し、0.0〜10.0のスコアで表現されます。一般に7.0以上が「重大(High)」、9.0以上が「緊急(Critical)」とされます。
Zero Trust Architecture
「境界防御」の限界に対し、すべてのアクセスを信頼せず、常に認証・認可を行うセキュリティモデルです。
サプライチェーン対策においても、内部ネットワークや開発ツールを無条件に信頼しないという考え方が適用されます。「内部からのアクセスだから安全」という前提を捨て、全ての通信を検証します。
DevSecOps
開発(Dev)と運用(Ops)にセキュリティ(Sec)を統合し、開発の初期段階からセキュリティ対策を組み込む手法です。
「シフトレフト(Shift Left)」と呼ばれる、セキュリティ対策を開発プロセスの早期に組み込むアプローチが特徴です。SCAツールのCIパイプラインへの統合は、DevSecOpsの代表的な実践例です。
SBOM導入の現実的な課題と対策
「SBOMを導入すれば全て解決」と考えがちですが、実務上はいくつかの課題があります。試験では理想的な対策を答えることが求められますが、現場感覚を持つことも支援士として重要です。
精度の問題
ツールによって検出できるコンポーネントに差があります。特に以下のケースで検出漏れが発生しやすくなります。
- 動的に読み込まれるライブラリ(プラグイン機構など)
- コンテナイメージ内に埋め込まれたバイナリ
- ネイティブライブラリ(C/C++で書かれた依存ライブラリ)
管理コストの問題
毎日ビルドされるたびに生成される膨大なSBOMをどう保管し、検索可能にするかという課題があります。
大規模開発では、1日に数百〜数千のビルドが実行されます。全てのSBOMを保管すると、ストレージコストと検索時間が問題になります。
現実的なアプローチ
以下の段階的導入が推奨されます。
- 重要システムから優先適用:全社一斉導入ではなく、顧客情報を扱うシステムなどリスクの高いものから開始
- リリースビルドのみSBOM生成:開発中の全てのビルドではなく、本番リリース時のみSBOMを生成・保管
- 自動化と統合:手動運用は破綻するため、CI/CDパイプラインへの統合を前提とする
支援士として、クライアントや上司に提案する際は、こうした運用のリアリティも踏まえた助言が期待されます。
理解度チェック：OSSセキュリティとサプライチェーン 練習問題
記事の内容を振り返り、重要なポイントが頭に入っているかを確認しましょう。ここでは、実際の試験で狙われやすい「攻撃の手口」や「各セキュリティ対策（SCA、SLSAなど）の役割」を中心に、練習問題を10問用意しました。 各選択肢には「なぜ正解なのか」「なぜ間違いなのか」という詳しい解説を付けています。間違えた問題は解説を読み込み、知識の穴を埋めておきましょう。
まとめ:信頼を可視化し検証し続ける
サプライチェーン攻撃は、私たちが築き上げてきた「デジタルの信頼」を逆手に取った攻撃です。オープンソースの恩恵を享受し、高速な開発サイクルを維持するためには、もはや性善説で外部コードを利用することはできません。
本記事で解説した重要ポイント
攻撃手法の理解
- 開発環境、ビルドプロセス、更新機能がすべて攻撃対象
- 正規のデジタル署名があっても安心できない
- 依存関係混乱など、設定ミスを突く攻撃も存在
OSSの適切な管理
- SCAツールやSBOMで、何を使っているか(資産)を正確に把握
- 推移的依存関係まで含めた可視化が必須
- 脆弱性データベースとの自動照合で迅速な対応
多層防御の実装
- 侵入されることを前提に、権限分離や監視を強化
- ビルド環境の隔離とネットワーク制限
- SLSA準拠による開発プロセスの健全性確保
試験対策として押さえるべきこと
情報処理安全確保支援士試験では、技術的な知識だけでなく、これらを組織としてどう管理・運用するかというマネジメントの視点も問われます。
「自社で作ったコード」だけでなく、「自社が持ち込んだ全てのコード」に責任を持つ。この認識が、現代のセキュリティ担当者に求められています。
サプライチェーン攻撃への対策は、一度実施すれば終わりではありません。新しい脆弱性は日々発見され、攻撃手法も進化し続けます。継続的な監視と改善のサイクルを回し続けることが、真の意味での「セキュアなサプライチェーン」を実現する唯一の道です。
本記事で紹介したSBOM、SLSA、SCAツールなどのキーワードを整理し、午前II試験での正確な知識定着と、午後試験での応用的な記述力の両方を磨いてください。