サプライチェーン攻撃対策の完全ガイド｜SBOM導入とCI/CDセキュリティ強化

サプライチェーン攻撃とは｜基礎知識から最新動向まで

近年、ソフトウェアの開発は外部ライブラリやオープンソースコンポーネントへの依存なしには成り立たない時代です。しかし、この依存関係の深まりは同時に、新たなセキュリティリスクを生み出しています。それが「サプライチェーン攻撃」です。

サプライチェーン攻撃とは、ソフトウェアの供給チェーン（開発・配信・更新の流れ）のうち、直接的には攻撃対象とならない下流の組織やユーザーを、間接的に攻撃するために使われる手法を指します。具体的には、開発ツールやライブラリ、パッケージリポジトリ、CI/CDパイプライン、さらには更新メカニズムそのものに悪意のあるコードを注入することで、信頼された経路を通じてマルウェアを拡散します。

最近の主要なサプライチェーン攻撃事例

SolarWinds Orion事件（2020年） 同社のネットワーク管理ソフトウェア「Orion」のビルドプロセスに攻撃者が侵入し、更新パッケージにバックドアを埋め込みました。約18,000組織が感染し、米国政府機関も被害を受けました。この事件はサプライチェーン攻撃の恐ろしさを世界に知らしめる転機となりました。

Codecov Bash Uploader事件（2021年） コードカバレッジツール「Codecov」のシェルスクリプトが改ざんされ、CI/CD環境の環境変数や認証情報が攻撃者に送信される状態が約2ヶ月間続きました。多くの開発組織の秘密情報が漏洩しました。

log4shell（2021年12月） Apache Log4jの脆弱性が発見され、Javaエコシステム全体に衝撃を与えました。広く使われるコンポーネントの脆弱性が、膨大な数のシステムに波及する「コンポーネント依存リスク」の典型例です。

xz Utils後門事件（2024年） xz Utilsに悪意のあるコードが意図的に投入され、sshdに影響を与える深刻な後門が仕込まれました。長期にわたる信頼関係の構築による「社会的エンジニアリング」型のサプライチェーン攻撃として注目されました。

これらの事例から分かるように、サプライチェーン攻撃は技術的な脆弱性だけでなく、人的な信頼関係やプロセスの不備を突く高度な手法です。

SBOM（ソフトウェア材料表）の導入実践ガイド

SBOMとは何か

SBOM（Software Bill of Materials）は、ソフトウェアに含まれるすべてのコンポーネント、ライブラリ、依存関係を一覧化した「材料表」です。食品の原材料表示や製造業の部品表と同じ考え方で、ソフトウェアの構成要素を可視化します。

2021年5月、米国大統領令により連邦政府調達におけるSBOM提供が義務化され、日本でも2024年以降、政府調達でのSBOMの取り扱いが本格的に検討されています。欧州のCyber Resilience Act（CRA）でもSBOMが要求事項に含まれており、世界的な潮流となっています。

SBOMに含まれるべき情報

適切なSBOMには、以下の情報が含まれるべきです。

コンポーネント名とバージョン：使用しているすべてのライブラリとその正確なバージョン番号。依存関係ツリー：コンポーネント間の親子関係や相互依存関係。ライセンス情報：各コンポーネントの使用ライセンス。脆弱性情報：既知のCVE（Common Vulnerabilities and Exposures）との照合結果。ユニーク識別子：コンポーネントを一意に特定できる識別情報。

主要なSBOMフォーマット

現在、主流となっているSBOMフォーマットは2つです。

SPDX（Software Package Data Exchange） Linux Foundationが主導する国際標準フォーマットです。ISO/IEC 5962:2021として国際標準化されており、ライセンス情報の扱いに強みがあります。ツールのサポートが広く、業界での採用率が高いのが特徴です。

CycloneDX OWASP（Open Web Application Security Project）が開発したフォーマットです。セキュリティ情報に重点を置いており、脆弱性情報やSBOM関連のメタデータを豊富に含むことができます。バージョニングやコンポーネントの脆弱性照合との連携が容易です。

どちらのフォーマットを選ぶかは組織の要件によりますが、近年のトレンドとしてはCycloneDXの採用が増加傾向にあります。

SBOM生成ツールの選定と導入手順

SBOMを生成するための主要ツールを紹介します。

Syft（Anchore） コンテナイメージやファイルシステムからSBOMを自動生成するOSSツールです。SPDXとCycloneDXの両フォーマットに対応し、多言語対応が充実しています。CLIツールとして手軽に導入でき、CI/CDパイプラインへの組み込みも容易です。

Trivy（Aqua Security） 脆弱性スキャナーとして広く知られていますが、SBOM生成機能も備えています。コンテナイメージ、ファイルシステム、Gitリポジトリをスキャンでき、脆弱性検出とSBOM生成を一気通貫で行えるのが強みです。

Microsoft SBOM Tool Microsoftが公開したOSSツールで、Windows/Linux/macOSの各環境で動作します。SPDX形式のSBOMを生成し、GitHub Actionsとの連携もサポートしています。

Tern コンテナイメージのSBOM生成に特化したツールです。Dockerfileの意図を理解した上でコンポーネントを特定するため、より詳細な分析が可能です。

導入の実践的なステップとして、まず自組織の技術スタックに合ったツールを1つ選定し、テスト環境でSBOM生成を試行します。次に、生成されたSBOMの内容を確認し、既知のコンポーネントが正しく認識されているか検証します。最終的にCI/CDパイプラインに組み込み、ビルド時に自動生成されるように設定します。

SBOM運用のポイント

SBOMを「作ること」自体が目的ではありません。重要なのは、SBOMを活用して脆弱性管理を効率化することです。生成したSBOMを定期的に既知の脆弱性データベースと照合し、影響を受けるコンポーネントを早期に特定する仕組みを作りましょう。さらに、SBOMをリリース成果物として納品物に含めることで、ユーザー側でも脆弱性の影響範囲を把握できるようになります。

CI/CDパイプラインのセキュリティ強化

CI/CDパイプラインが狙われる理由

CI/CDパイプラインは、コードの変更から本番環境へのデプロイまでの一連の流れを自動化する仕組みです。このパイプラインが攻撃を受けると、攻撃者は本番環境に直接アクセスできる権限を取得したり、悪意のあるコードを正規のデプロイ経路に乗せて配信したりすることが可能になります。

CI/CDパイプラインには通常、レポジトリのアクセス権、コンテナレジストリの認証情報、クラウドサービスのAPIキー、デプロイ先のアクセス権限などが集約されています。つまり、パイプラインを制御することは、開発インフラ全体を制御することにほかなりません。

パイプラインセキュリティの多層防御戦略

CI/CDパイプラインのセキュリティは、単一の対策ではなく、複数の層で防御を構築することが重要です。

第一層：ソースコードの保護

ソースコードリポジトリへのアクセスは最小限の権限で行い、ブランチプロテクションルールを適用します。メインブランチへの直接プッシュを禁止し、プルリクエストによるコードレビューを必須とします。署名付きコミットを導入し、コードの改ざんを検出できるようにしましょう。さらに、リポジトリの操作ログを記録・監視し、異常なアクセスを早期に検知します。

第二層：依存関係の管理

外部ライブラリのバージョンを固定し、意図しないアップデートによる脆弱性の導入を防ぎます。パッケージの整合性を検証するため、ハッシュ値の確認やパッケージ署名の検証を自動化します。プライベートパッケージレジストリを運用し、社内で承認されたパッケージのみを使用するポリシーを導入するのも効果的です。

第三層：ビルド環境の分離とセキュリティ

ビルド環境は本番環境と完全に分離し、ビルドエージェントには最小限の権限のみ付与します。コンテナベースのビルド環境を使用し、ビルドごとにクリーンな環境を確保します。ビルドツール自体の脆弱性も定期的に確認し、最新のセキュリティパッチを適用しましょう。

第四層：セキュリティテストの自動化

SAST（静的アプリケーションセキュリティテスト）をパイプラインに組み込み、コードレベルの脆弱性を早期に検出します。DAST（動的アプリケーションセキュリティテスト）で実行時の脆弱性も確認します。SCA（Software Composition Analysis）ツールで依存コンポーネントの脆弱性をスキャンします。さらに、コンテナイメージのスキャンをデプロイ前に実行し、既知の脆弱性や設定ミスを検出します。

第五層：アクセス制御とシークレット管理

CI/CDパイプラインで使用する認証情報やシークレットは、ハードコードや環境変数に平文で保存せず、専用のシークレット管理ツールを使用します。VaultやAWS Secrets Manager、GitHub Secretsなどのソリューションを活用し、シークレットへのアクセスを厳密に制御します。パイプラインの各ステップで異なる権限を付与し、万が一の漏洩時の影響を最小限に留めます。

主要なCI/CDセキュリティツール

GitHub Advanced Security GitHubのネイティブセキュリティ機能です。CodeQLによるSAST、Dependabotによる依存関係の脆弱性検出と自動更新、シークレット検出機能を提供します。GitHub ActionsをCI/CDに使用している組織には、統合性の高さが大きなメリットです。

GitLab SAST/DAST GitLab CI/CDに統合されたセキュリティスキャン機能です。SAST、DAST、コンテナスキャン、依存関係スキャンをパイプライン内で一括で実行でき、脆弱性レポートをダッシュボードで確認できます。

Snyk 開発者向けセキュリティプラットフォームとして高い評価を得ています。コード、コンテナ、インフラストラクチャ、IaC（Infrastructure as Code）の脆弱性を網羅的に検出します。IDE統合により、開発者がコーディング中に脆弱性を確認できるのも特徴です。

Aqua Security / Prisma Cloud コンテナとクラウド環境のセキュリティに強みを持ちます。CI/CDパイプラインから本番環境まで、一貫したセキュリティポリシーの適用が可能です。

開発プロセス全体をセキュアにするDevSecOpsの実践

DevSecOpsとは

DevSecOpsとは、開発（Dev）、運用（Ops）、セキュリティ（Sec）を融合し、セキュリティを開発プロセスの初期段階から組み込む文化と実践です。従来の「開発後にセキュリティレビューを行う」モデルから脱却し、セキュリティを「すべての人の責任」として開発ライフサイクル全体に埋め込みます。

DevSecOpsの実践ステップ

ステップ1：現状の可視化 まず、自組織の開発プロセスにおけるセキュリティの現状を把握します。どの段階でセキュリティチェックが行われているか、脆弱性の検出から修正までにどれくらいの時間がかかるか、過去のインシデントの傾向は何かを分析します。

ステップ2：セキュリティガートの段階的導入 すべてを一度に導入しようとせず、影響度と実装コストを考慮して優先順位を付けます。まずはSASTと依存関係スキャンから始め、段階的にDAST、コンテナスキャン、IaCスキャンを追加します。各ガートで検出された問題を修正してから次のステップに進むという「フェイルファスト」の原則を適用します。

ステップ3：開発者の教育とエンパワーメント セキュリティツールを導入するだけでなく、開発者がセキュリティを理解し、自ら対応できるようにすることが重要です。セキュリティコーディングガイドラインの策定、脆弱性対応のトレーニング、セキュリティチャンピオン制度の導入など、組織全体のセキュリティ意識を高める取り組みを並行して進めます。

ステップ4：メトリクスと継続的改善 脆弱性の検出数、修正期間（MTTR）、リリースごとの脆弱性傾向などのメトリクスを定義し、定期的にレビューします。セキュリティの状態を数値で把握することで、改善効果の測定と優先順位の見直しを行います。

オープンソースコンポーネントのリスク管理

オープンソース依存の現実

現代のソフトウェア開発において、オープンソースコンポーネントなしでプロダクションレベルの製品を開発することは事実上不可能です。調査によると、企業のアプリケーションコードの70〜90%はオープンソースで構成されています。このことは、適切に管理されなければ、膨大な数の潜在的な脆弱性を抱え込むことを意味します。

実効的なリスク管理のアプローチ

コンポーネントカタログの維持 使用しているすべてのオープンソースコンポーネントとそのバージョンを正確に記録します。SBOMの生成と定期的な更新により、常に最新のコンポーネント一覧を保持しましょう。

脆弱性の継続的モニタリング NVD（National Vulnerability Database）やGitHub Advisory Databaseなどの脆弱性データベースと連携し、使用コンポーネントに影響する新規脆弱性をリアルタイムに検知します。DependabotやRenovateなどの自動更新ツールを活用し、セキュリティパッチの適用を自動化します。

ライセンスコンプライアンス GPLやAGPLなど、コピーレフトライセンスのコンポーネントを無自覚に導入すると、自社コードの公開義務が発生するリスクがあります。SBOMのライセンス情報を活用し、ライセンスポリシーに違反するコンポーネントを早期に検出します。

フォークとミラーの検討 頻繁に使用する重要なコンポーネントについては、自社でフォークやミラーを保持することで、アップストリームの変更や消失リスクに備えることができます。ただし、フォークしたコンポーネントのセキュリティパッチ適用は自社の責任となるため、運用体制と併せて検討する必要があります。

導入チェックリスト｜今日から始められる対策

最後に、サプライチェーン攻撃対策を組織に導入するための実践的なチェックリストをまとめます。

短期対策（1〜3ヶ月）として、CI/CDパイプラインへのセキュリティスキャンツールの導入、依存関係の自動更新ツールの設定、シークレット管理の改善、ブランチプロテクションルールの適用があります。

中期対策（3〜6ヶ月）として、SBOM生成プロセスの構築、DevSecOps文化の推進開始、セキュリティコーディングガイドラインの策定、インシデント対応プレイブックの作成があります。

長期対策（6ヶ月以上）として、SBOMの外部提供体制の構築、脆弱性管理のKPI設定と継続的改善、サードパーティベンダーのセキュリティ評価プロセスの構築、組織全体のセキュリティ意識向上プログラムの実施があります。

サプライチェーン攻撃対策は、一度導入して終わりというものではありません。技術環境の進化に合わせて、継続的に見直しと改善を繰り返すことが重要です。本記事で紹介した知見を参考に、自組織の状況に合った対策を段階的に進めていきましょう。