サプライチェーン攻撃対策のCI/CD｜SLSA・署名・改ざん検知を解説

2025年12月23日作成

コラム

CI/CD（継続的インテグレーション/継続的デリバリー）パイプラインは、ソフトウェアサプライチェーン攻撃の主要な標的です。SolarWinds事件では、ビルドシステムが侵害され、正規のアップデートにマルウェアが混入されました。このような攻撃を防ぐため、Googleを中心に開発されたSLSA（Supply-chain Levels for Software Artifacts）フレームワークが注目されています。この記事では、CI/CDパイプラインのセキュリティ強化を詳しく解説します。SLSAの各レベルと要件、ビルド成果物の署名、改ざん検知の実装まで、開発パイプラインを守る方法を紹介します。

CI/CDがサプライチェーン攻撃の標的になる理由

CI/CD（継続的インテグレーション/継続的デリバリー）パイプラインは、現代のソフトウェア開発に不可欠なインフラストラクチャです。しかし同時に、サプライチェーン攻撃の主要な標的でもあります。

なぜビルドパイプラインが狙われるのでしょうか。攻撃者の視点で考えると、その理由は明確です。ビルドシステムに1回侵入するだけで、そのソフトウェアを利用するすべてのユーザーに悪意あるコードを配布できるからです。これは、エンドユーザーを個別に攻撃するよりも遥かに効率的です。

SolarWinds事件（2020年）: IT管理ソフトウェアOrionのビルドシステムが侵害され、SUNBURSTバックドアが混入。18,000以上の組織に配布され、米国政府機関を含む重要インフラが影響を受けた。攻撃者は約9か月間検知されなかった。
Codecov事件（2021年）: コードカバレッジツールCodecovのBashスクリプトが改ざんされ、CI/CD環境から環境変数（認証情報含む）が流出。29,000以上の顧客が影響を受けた可能性。
3CX事件（2023年）: VoIPソフトウェア3CXのビルドパイプラインにトロイの木馬が混入。60万以上の顧客企業に影響。北朝鮮関連のAPTグループの関与が指摘された。

これらの事件に共通するのは、正規の署名が施された「信頼された」ソフトウェアを経由して攻撃が行われた点です。ファイアウォールやウイルス対策ソフトは、正規のアップデートチャネルを通じて配布されるソフトウェアを信頼するため、検知が極めて困難でした。

ソフトウェアサプライチェーン攻撃の詳細については、リンク先のページをご参照ください。

SLSAフレームワークとは

SLSA（Supply-chain Levels for Software Artifacts、発音は「サルサ」）は、ソフトウェアアーティファクト（成果物）のサプライチェーン完全性を保証するためのフレームワークです。Googleを中心に開発され、OpenSSF（Open Source Security Foundation）のプロジェクトとして公開されています。

項目	内容
正式名称	Supply-chain Levels for Software Artifacts
開発主体	Google、OpenSSF
目的	ソフトウェアサプライチェーンの完全性保証
構成	4つのセキュリティレベル（L1〜L4）

SLSAの目的は、「このソフトウェアは、本当に正規のソースコードから、改ざんなく、正規のビルド環境で作成されたものか」を検証可能にすることです。

SLSAは、ソフトウェアサプライチェーンに対する攻撃（ソースコードの改ざん、ビルドシステムの侵害、パッケージの改ざん等）から保護するための共通フレームワークを提供します。
— 出典：SLSA公式ドキュメント

SLSAは段階的なアプローチを採用しており、組織の成熟度に応じてL1からL4まで徐々にセキュリティレベルを向上させることができます。

SLSAの各レベルと要件

SLSAは4つのレベルで構成されており、レベルが上がるほどサプライチェーン攻撃に対する保護が強化されます。

レベル	要件概要	保護される脅威
SLSA L1	ビルドプロセスの文書化	偶発的な変更
SLSA L2	ホストされたビルドサービス、来歴生成	ビルド後の改ざん
SLSA L3	隔離されたビルド環境、署名付き来歴	ビルド中の改ざん
SLSA L4	二者検証、再現可能ビルド	高度な攻撃

SLSA Level 1

L1は、SLSAの最初のレベルであり、ビルドプロセスの文書化が要件です。

要件: ビルドプロセスが文書化されており、自動化されたビルドスクリプトが存在すること。
達成方法: Makefile、Dockerfile、CI/CD設定ファイル（.github/workflows等）の整備。ビルド手順書の作成。
効果: 偶発的な変更（手動ビルドによるミス等）を防止。再現性のあるビルドの第一歩。

SLSA Level 2

L2では、ホストされたビルドサービスの利用と、来歴（Provenance）の生成が要件となります。

要件: ビルドがホストされたサービス（GitHub Actions、GitLab CI等）で実行され、ビルドの来歴（何から、どのように作成されたか）が自動生成されること。
達成方法: GitHub Actions、GitLab CI、Google Cloud Build等のマネージドCI/CDサービスの利用。来歴ファイルの自動生成。
効果: ビルド後の成果物改ざんを検知可能。ビルドの出所を追跡可能。

SLSA Level 3

L3では、隔離されたビルド環境と署名付きの来歴が要件です。

要件: ビルドが隔離された環境で実行され、他のビルドやユーザーの影響を受けないこと。来歴に電子署名が施され、改ざんを検知できること。
達成方法: エフェメラル（一時的）なビルド環境の使用。Sigstore/cosignによる来歴への署名。
効果: ビルド中の改ざん攻撃を防止。来歴の信頼性を保証。

SLSA Level 4

L4は最高レベルであり、二者による検証と再現可能なビルドが要件です。

要件: 2つの独立したビルドシステムで同一の成果物が生成されることを検証。ビルドが完全に再現可能であること。
達成方法: 複数のCI/CDプラットフォームでの並行ビルド。決定論的なビルド設定。ハッシュ値の一致確認。
効果: 単一のビルドシステム侵害では攻撃が成立しない。最高レベルの保証。

多くの組織では、まずL2を目標として取り組み、段階的にL3を目指すことが現実的です。

ビルド成果物の署名

ビルド成果物（コンテナイメージ、バイナリ、パッケージ等）に電子署名を施すことで、改ざんを検知し、出所を証明できます。

なぜ署名が必要か

署名がない場合、ビルド成果物が「本当に正規のビルドシステムで作成されたものか」を検証する手段がありません。攻撃者がビルド成果物を差し替えても、気づくことができません。

改ざん検知：署名後に成果物が変更されると、署名検証が失敗する
出所証明：誰（どのシステム）が署名したかを確認できる
否認防止：署名者は「署名していない」と否認できない

不正アクセスや認証情報の窃取によりビルドシステムが侵害された場合でも、署名検証により異常を検知できる可能性があります。

Sigstoreとcosign

Sigstoreは、ソフトウェアアーティファクトの署名と検証を簡素化するオープンソースプロジェクトです。特にcosignは、コンテナイメージへの署名を簡単に行えるツールとして広く使われています。

Sigstoreの特徴: キーレス署名により、秘密鍵の管理負担を軽減。一時的な鍵を生成し、署名の証拠を公開透明性ログ（Rekor）に記録。
cosignの機能: コンテナイメージ、Blob（任意のファイル）、SBOMへの署名と検証。OCI（Open Container Initiative）レジストリと統合。
Fulcioの役割: 一時的なコード署名証明書を発行するCA（認証局）。OpenID Connect（OIDC）で本人確認を行い、短命の証明書を発行。
Rekorの役割: 署名の証拠を記録する公開透明性ログ。改ざん不可能な形で署名イベントを記録し、後から検証可能。

Sigstoreを使用することで、従来の課題であった秘密鍵の長期管理から解放されます。

署名検証の自動化

署名を行うだけでなく、デプロイ時に署名を検証することが重要です。検証を自動化することで、署名のない、または無効な署名を持つ成果物がデプロイされることを防げます。

アドミッションコントローラー：Kubernetes環境では、Kyverno、OPA Gatekeeper、Connaisseurなどを使用して、署名済みイメージのみをデプロイ許可
CI/CDパイプラインでの検証：デプロイステージで署名検証を実行し、失敗した場合はデプロイを中止
ポリシー強制：特定の署名者（組織の公式鍵等）による署名のみを許可するポリシーを設定

改ざん検知の実装

署名に加えて、改ざん検知の仕組みを実装することで、サプライチェーン攻撃への耐性を高められます。

ハッシュ検証

最も基本的な改ざん検知は、ハッシュ値（ダイジェスト）の検証です。

SHA-256ハッシュ: ファイルやコンテナイメージの内容から計算される固定長の値。内容が1ビットでも変わればハッシュ値も変化する。
ダイジェスト固定: コンテナイメージをタグ（latest等）ではなく、ダイジェスト（sha256:abc123...）で指定することで、意図しないバージョン変更を防止。

来歴（Provenance）の確認

来歴（Provenance）は、ビルド成果物が「何から」「どのように」「どこで」作成されたかを記録した情報です。

来歴に含まれる情報	説明
ソースリポジトリ	どのリポジトリ、どのコミットから作成されたか
ビルダー	どのビルドシステム（GitHub Actions等）で作成されたか
ビルドパラメータ	どのような設定でビルドが実行されたか
依存関係	ビルド時に使用された依存パッケージ
タイムスタンプ	いつビルドが実行されたか

来歴を検証することで、「このバイナリは本当に公式リポジトリのコードから作成されたか」を確認できます。

in-totoによるサプライチェーン検証

in-totoは、ソフトウェアサプライチェーン全体の完全性を検証するためのフレームワークです。各ステップ（ソースコード取得、ビルド、テスト、パッケージング等）を定義し、それぞれのステップが正しく実行されたことを検証します。

レイアウト: サプライチェーンの各ステップと、それを実行する権限を持つ者を定義。
リンク: 各ステップの実行結果（入力、出力、実行者の署名）を記録。
検証: 最終成果物を受け取った際に、レイアウトに基づきすべてのリンクを検証。

in-totoはSBOMと組み合わせることで、より包括的なサプライチェーン保護を実現できます。

CI/CDセキュリティのベストプラクティス

SLSAと署名に加えて、CI/CDパイプラインを保護するためのベストプラクティスを紹介します。

シークレット管理: 認証情報、APIキー、署名鍵などのシークレットを安全に管理する。HashiCorp Vault、AWS Secrets Manager、Google Secret Managerなどの専用サービスを利用。シークレットをソースコードにハードコードしない。環境変数への直接設定も避け、シークレット管理サービスから動的に取得する。
権限最小化（最小権限の原則）: CI/CDパイプラインに付与する権限は必要最小限に制限する。本番環境へのデプロイ権限は厳格に管理。ブランチ保護ルールを設定し、直接プッシュを禁止。プルリクエストのレビューを必須化。
監査ログ（ビルド履歴の保持）: すべてのビルド実行ログを長期保存する。誰が、いつ、どのような変更をデプロイしたかを追跡可能にする。インシデント対応時の調査に活用。
パイプラインのコード化（Pipeline as Code）: CI/CD設定をコードとしてリポジトリで管理する。設定変更の履歴を追跡可能にする。レビュープロセスを設定変更にも適用する。
依存関係のロック: ビルド時に使用する依存パッケージのバージョンを固定する。ロックファイル（package-lock.json、Pipfile.lock等）をコミットする。予期しない依存関係の変更を防止する。

フィッシング詐欺やソーシャルエンジニアリングにより開発者の認証情報が窃取されるケースもあるため、多要素認証の導入も重要です。

主要CI/CDプラットフォームでの実装

主要なCI/CDプラットフォームでは、SLSAやセキュリティ機能がサポートされています。

プラットフォーム	SLSA対応	主なセキュリティ機能
GitHub Actions	L3まで対応可能	OIDC連携、シークレット管理、Dependabot
GitLab CI	L2まで対応可能	SAST/DAST統合、シークレット検出
Google Cloud Build	L3まで対応可能	Binary Authorization、来歴生成
Jenkins	プラグインで対応	カスタマイズ性が高い、自己管理が必要

GitHub Actions: SLSA 3レベルの来歴生成をサポート。slsa-github-generatorを使用して署名付き来歴を自動生成可能。OpenID Connect（OIDC）によるキーレス認証にも対応。
GitLab CI: シークレット検出、依存関係スキャン、コンテナスキャンなどのセキュリティ機能を統合。来歴生成は外部ツールとの連携が必要。
Google Cloud Build: Binary Authorizationと連携し、署名済みイメージのみをデプロイ許可。ビルド来歴の自動生成とArtifact Registryへの保存をサポート。
Jenkins: 高いカスタマイズ性を持つが、セキュリティ設定は自己責任。プラグインを組み合わせてSLSA対応を実現可能。定期的なアップデートとセキュリティ設定の見直しが必要。

攻撃手法	CI/CDへの影響
ソフトウェアサプライチェーン攻撃	ビルドパイプラインへの悪意あるコード混入
認証情報の窃取	CI/CD環境の認証情報を窃取しアクセス
不正アクセス	ビルドシステムへの不正侵入
シークレット漏洩	APIキー、署名鍵などの流出
CI/CD資格情報の流出	パイプライン設定からの認証情報漏洩
標的型攻撃（APT）	長期間潜伏してビルドシステムを侵害
内部不正	開発者による悪意あるコード混入

よくある質問

Q: SLSAはどのレベルを目指すべきですか？: A: 組織の成熟度とリソースに応じて段階的に取り組むことをお勧めします。まずはL1（ビルドプロセスの文書化）から始め、L2（ホストされたビルドサービス、来歴生成）を次の目標とするのが現実的です。L3（署名付き来歴、隔離されたビルド環境）は、セキュリティ要件が高い組織や、広く配布されるソフトウェアを開発する組織で目指すべきレベルです。L4は現時点では達成が困難なケースが多いです。
Q: 既存のCI/CDパイプラインにSLSAを適用できますか？: A: はい、可能です。GitHub ActionsやGitLab CIなど主要なプラットフォームはSLSA対応を進めており、既存のパイプラインに来歴生成や署名機能を追加できます。slsa-github-generatorなどのツールを使用することで、比較的少ない変更でSLSA L2〜L3に対応できます。ただし、既存のワークフローの見直しや、シークレット管理の改善が必要になることがあります。
Q: 署名の鍵はどのように管理すべきですか？: A: 従来の長期鍵管理は負担が大きく、鍵の漏洩リスクもあります。Sigstoreのキーレス署名を採用することで、秘密鍵の管理負担を大幅に軽減できます。長期鍵を使用する場合は、HSM（Hardware Security Module）やクラウドプロバイダーのKMS（Key Management Service）を利用し、鍵へのアクセスを厳格に制御してください。
Q: 小規模なプロジェクトでも必要ですか？: A: プロジェクトの規模に関わらず、基本的なCI/CDセキュリティは重要です。特に、他の組織や一般ユーザーに配布されるソフトウェアの場合は、SLSA L2以上を目指すことをお勧めします。小規模プロジェクトでも、GitHub Actionsとslsa-github-generatorを使用すれば、追加コストなくSLSA L3の来歴生成が可能です。
Q: SLSAとSBOMの関係は？: A: SLSAとSBOMは補完的な関係にあります。SBOMは「ソフトウェアが何で構成されているか」を示し、SLSAの来歴は「ソフトウェアがどのように作成されたか」を示します。両方を組み合わせることで、ソフトウェアサプライチェーンの透明性と完全性を高められます。SBOMの詳細はSBOM解説ページをご参照ください。

まとめ

本記事では、サプライチェーン攻撃対策としてのCI/CDセキュリティについて解説しました。主なポイントは以下の通りです。

CI/CDパイプラインはサプライチェーン攻撃の主要な標的であり、SolarWinds、Codecov、3CX事件がその危険性を示している
SLSAフレームワークは、L1〜L4の4段階でビルドの完全性を保証する仕組みを提供
ビルド成果物の署名により、改ざん検知と出所証明が可能。Sigstore/cosignでキーレス署名を実現
来歴（Provenance）により、ソフトウェアが「何から」「どのように」作成されたかを検証可能
シークレット管理、権限最小化、監査ログなどのベストプラクティスも併せて実装が必要
GitHub Actions、GitLab CI、Google Cloud Buildなど主要プラットフォームがSLSA対応を進めている

次のステップとして、OSSの安全な利用方法を解説したOSS時代のサプライチェーン攻撃対策｜依存パッケージ・供給元管理をご参照ください。

技術者向けカテゴリの全体像については、サプライチェーン攻撃の技術対策｜SBOM・CI/CD・OSS・EDIをご覧ください。

サプライチェーン攻撃の総合的な理解には、サプライチェーン攻撃とは｜仕組み・事例・対策を初心者にもわかりやすく解説もあわせてご参照ください。

重要なお知らせ

本記事は一般的な情報提供を目的としており、個別の状況に対する助言ではありません。
実際にサイバー攻撃の被害に遭われた場合は、警察（#9110）やIPA（03-5978-7509）などの公的機関にご相談ください。
法的な対応が必要な場合は、弁護士などの専門家にご相談ください。
記載内容は作成時点の情報であり、攻撃手法は日々進化している可能性があります。

サプライチェーン攻撃対策のCI/CD｜SLSA・署名・改ざん検知を解説