サプライチェーン攻撃対策：SLSAフレームワークに基づくCI/CDパイプラインのセキュリティ強化
はじめに
現代のソフトウェア開発において、CI/CDパイプラインは開発からデプロイメントまでのプロセスを自動化し、効率を大幅に向上させる基盤として不可欠な存在です。しかし、この自動化されたプロセスは、同時に新たなセキュリティリスク、特にソフトウェアサプライチェーン攻撃の主要なターゲットとなり得ます。従来のアプリケーションレイヤーの脆弱性対策に加え、開発環境からデプロイメントに至るまで、サプライチェーン全体の信頼性を確保することが喫緊の課題となっています。
本稿では、Googleが提唱するSLSA (Supply-chain Levels for Software Artifacts) フレームワークを起点とし、CI/CDパイプラインにおけるソフトウェアサプライチェーン攻撃の脅威と、それに対する実践的な防御戦略について詳細に解説します。SLSAの各レベルの要求事項を理解し、具体的な実装パターンを通じて、セキュアな開発エコシステムの構築を目指します。
ソフトウェアサプライチェーン攻撃の脅威の深層
ソフトウェアサプライチェーン攻撃は、標的となるソフトウェアの設計、開発、テスト、配布、アップデートのいずれかの段階に不正なコードや脆弱性を挿入し、最終的にエンドユーザーに悪影響を及ぼす攻撃手法です。これは単一のアプリケーションの脆弱性を突くものとは異なり、開発プロセス全体にわたる多角的な攻撃ベクトルを有しています。
具体的な攻撃パターンとしては、以下のものが挙げられます。
- オープンソースコンポーネントの悪用: 開発者が依存するOSSライブラリやパッケージに悪意のあるコードが挿入されるケースです。タイポスクワッティング（Typo-squatting）や、正規のパッケージの脆弱性が公開される前のゼロデイ攻撃などが該当します。
- ビルドプロセスの改ざん: CI/CDパイプライン上のビルド環境やスクリプトが侵害され、ビルド成果物に不正な変更が加えられるケースです。これにより、意図しないバックドアやマルウェアが組み込まれる可能性があります。
- ソースコードリポジトリの乗っ取り: バージョン管理システム（例: Gitリポジトリ）が侵害され、不正なコミットが挿入される、あるいは正規のコードが改ざんされるケースです。開発者の認証情報漏洩や、VCSサーバーの脆弱性が悪用されることで発生します。
- パッケージレジストリの侵害: ソフトウェアが公開されるパッケージレジストリ（例: npm, PyPI, Docker Hub）が侵害され、正規のパッケージが悪意のあるバージョンに置き換えられたり、不正なパッケージが公開されたりするケースです。
これらの攻撃は、一度成功すると多数のユーザーに影響を及ぼす可能性があり、その検出と復旧は極めて困難です。SolarWindsのサプライチェーン攻撃事件は、この種の攻撃がもたらす広範な影響を如実に示しました。
SLSA（Supply-chain Levels for Software Artifacts）フレームワークの概要
SLSAは、ソフトウェアサプライチェーンの整合性とセキュリティを保証するためのフレームワークであり、ソフトウェア成果物の信頼性を段階的に向上させることを目的としています。これは、ソフトウェアの出所（Provenance）を検証し、その整合性を確保するための具体的な要件を定義しています。SLSAは、ソフトウェアのビルドプロセスから最終成果物に至るまでの各段階において、改ざん防止と検証可能性を高めるためのチェックリストと考えることができます。
SLSAはレベル1からレベル4までの4段階で構成されており、各レベルは前のレベルの要件を満たしつつ、さらに厳格なセキュリティ保証を提供します。
- SLSA Level 1: ビルドプロセスがスクリプト化されており、成果物の出所が記録されている状態。手動ビルドの排除と基本的な出所情報の提供が求められます。
- SLSA Level 2: ビルドシステムがバージョン管理されており、改ざん防止策が講じられている状態。ビルドシステムの信頼性が向上し、より確実な出所情報が提供されます。
- SLSA Level 3: ビルドが隔離された環境で実行され、高いレベルの改ざん防止策が講じられている状態。一時的なビルド環境の使用や、ビルド成果物に対する署名が求められます。
- SLSA Level 4: SLSA Level 3の要件に加え、複数の独立したレビューと厳格なポリシー適用により、サプライチェーン全体の信頼性が最大化された状態。これには、再現可能なビルドや二者承認などの要件が含まれます。
SLSAは、SBOM (Software Bill of Materials) とも密接に関連します。SBOMは、ソフトウェアに含まれるすべてのコンポーネントとその依存関係を一覧化したものであり、SLSAによって生成された信頼できる出所情報と組み合わせることで、ソフトウェアの透明性とセキュリティ監査の精度を大幅に向上させることが可能です。
SLSAに基づくCI/CDパイプラインのセキュリティ強化戦略
SLSAの各レベルの要件を達成するためには、CI/CDパイプラインの設計と運用において、多層的なセキュリティ対策を講じる必要があります。以下に、主要な戦略と対策を詳述します。
1. ソースコードの信頼性確保
サプライチェーンの出発点であるソースコードリポジトリのセキュリティは極めて重要です。
- 強力な認証と認可:
- 開発者アカウントにおける多要素認証（MFA）の強制適用。
- 最小権限の原則に基づいたリポジトリへのアクセス制御。
- シークレット管理には、専用のシークレット管理ソリューション（HashiCorp Vault, AWS Secrets Managerなど）を導入し、CI/CDパイプラインに直接ハードコードしない設計とします。
- コミットの信頼性:
- GPGやSSHキーを用いた署名付きコミットの強制により、コミット作成者の身元と内容の完全性を保証します。
- すべてのプルリクエストに対して、コードレビューと承認プロセスを義務付けます。
- 静的解析と依存関係スキャン:
- SAST（Static Application Security Testing）ツールをCI/CDパイプラインに組み込み、コミットごとにコードベースの潜在的な脆弱性を自動検出します。
- SCA（Software Composition Analysis）ツールを使用して、プロジェクトが依存するオープンソースライブラリの既知の脆弱性を継続的にスキャンし、リスクのある依存関係を特定して対処します。
2. ビルドプロセスの隔離と検証
ビルドプロセス自体が攻撃対象となることを防ぎ、生成される成果物の信頼性を保証します。
- 使い捨てビルド環境（Ephemeral Builders）:
- ビルドごとにクリーンな、一時的な環境をプロビジョニングし、ビルド完了後に破棄します。これにより、ビルド環境に恒久的なマルウェアが潜伏するリスクを排除します。
- コンテナ技術（Docker, Kubernetes）は、このコンセプトを実現するための強力なツールとなります。
- ビルドプロセスの再現性（Reproducible Builds）:
- 同じソースコードとビルド設定から、常にバイトレベルで同一のビルド成果物が生成されるようにします。これにより、ビルドプロセスへの改ざんがあった場合に検出が容易になります。
- すべての依存関係のバージョンをピン留めし、ビルドツールチェーンのバージョンも固定することが重要です。
- ビルドアーティファクトの署名（Attestation）:
- ビルド成果物（バイナリ、コンテナイメージなど）に対して、ビルドシステム自身が署名を行います。この署名には、成果物のハッシュ値、ビルドを実行した環境、ビルドに使用されたソースコードのリビジョンなどの出所情報（Provenance）が含まれます。
- SigstoreプロジェクトのCosignやin-totoは、この目的のためのオープンソースツールです。OIDC（OpenID Connect）と連携することで、秘密鍵の管理なしに短寿命の証明書を発行し、署名プロセスを簡素化できます。
- ビルドプロセスのポリシー適用:
- Open Policy Agent (OPA) やKyvernoのようなポリシーエンジンを用いて、CI/CDパイプラインの構成やビルドプロセス自体が定義されたセキュリティポリシーに準拠していることを検証します。
3. 依存関係管理の厳格化
外部依存関係はサプライチェーン攻撃の主要な侵入経路であるため、その管理を厳格に行う必要があります。
- 信頼できるレジストリの使用:
- 公式かつ信頼できるパッケージレジストリのみを使用し、必要に応じてプロキシレジストリやプライベートレジストリを構築して、外部への依存を制御します。
- レジストリからのダウンロード時に、ハッシュ値や署名による整合性チェックを必ず行います。
- 依存関係のピン留めとハッシュチェック:
- すべての依存関係について、特定のバージョンをロックし、可能であればハッシュ値（SRI: Subresource Integrityなど）も指定して、意図しない変更を防止します。
- 自動化された依存関係更新ツール（Dependabotなど）を活用しつつ、更新時に自動脆弱性スキャンとテストを実行します。
- 定期的な脆弱性スキャン:
- SCAツールやDockerイメージスキャナー（Trivy, Clairなど）をCI/CDパイプラインに組み込み、依存関係とビルド成果物の脆弱性を継続的に監視します。
4. デプロイメントの安全確保
ビルドされた成果物が安全に本番環境にデプロイされることを保証します。
- 不変インフラストラクチャ（Immutable Infrastructure）の原則:
- 一度デプロイされたインスタンスやコンテナは変更せず、アップデートが必要な場合は新しいイメージで再デプロイします。これにより、デプロイ後の環境改ざんリスクを低減します。
- デプロイ承認プロセスとロールバック戦略:
- 本番環境へのデプロイには、複数の関係者による承認プロセスを導入します。
- 万が一の事態に備え、迅速かつ確実に以前の安定バージョンにロールバックできる戦略を策定し、テストします。
- SLSA出所情報の検証:
- デプロイメントパイプラインにおいて、デプロイ対象の成果物がSLSA要件に準拠した出所情報を持つことを検証します。例えば、成果物の署名が信頼できる鍵で発行されているかを確認します。
実践的な実装パターンとツール
ここでは、GitHub Actionsを用いたSLSA準拠の一例として、Cosignによるビルドアーティファクトの署名プロセスを紹介します。これはSLSA Level 3/4の要件の一部を満たすものです。
name: Sign Artifact with Cosign for SLSA Provenance
on:
push:
branches:
- main
workflow_dispatch: # Manual trigger for demonstration
jobs:
build-and-sign:
runs-on: ubuntu-latest
permissions:
contents: read
id-token: write # Required for OIDC authentication with Sigstore Fulcio
steps:
- name: Checkout repository
uses: actions/checkout@v4
- name: Build artifact (example: a simple text file representing a build output)
run: |
echo "This is a sample build artifact from ${{ github.repository }}@${{ github.sha }}" > build-artifact.txt
cat build-artifact.txt
- name: Set up Cosign
uses: sigstore/cosign-installer@v3.4.0
with:
cosign-release: 'v2.2.0' # Specify a stable, production-ready Cosign version
- name: Generate Fulcio certificate and OIDC token
uses: sigstore/gh-action-oidc-auth@v1.6.0
id: sigstore_auth
with:
token-lifetime: 3600 # OIDC token valid for 1 hour
- name: Sign artifact.txt with Cosign and generate SLSA provenance
run: |
# COSIGN_EXPERIMENTAL is often needed for features like signing arbitrary blobs or specific provenance types.
# For a more robust SLSA Provenance generation, typically in-toto attestations are used.
# This example demonstrates signing a simple file using the workflow's OIDC identity.
COSIGN_EXPERIMENTAL=true cosign sign-blob \
--certificate-oidc-issuer=${{ steps.sigstore_auth.outputs.issuer }} \
--certificate-identity=${{ steps.sigstore_auth.outputs.subject }} \
--output-signature build-artifact.sig \
--output-certificate build-artifact.pem \
build-artifact.txt
echo "Artifact signed successfully. Signature (build-artifact.sig) and Certificate (build-artifact.pem) generated."
# Optional: Verify the signature
echo "Verifying signature..."
COSIGN_EXPERIMENTAL=true cosign verify-blob \
--certificate build-artifact.pem \
--signature build-artifact.sig \
build-artifact.txt
- name: Upload signature and certificate as workflow artifacts
uses: actions/upload-artifact@v4
with:
name: build-attestation
path: |
build-artifact.sig
build-artifact.pem
上記のワークフローでは、GitHub ActionsのOIDC機能を利用してSigstore Fulcioから一時的な証明書を取得し、Cosignを用いてbuild-artifact.txtに署名しています。生成された署名と証明書は、その成果物がこの特定のCI/CDパイプラインによって生成されたことを証明する出所情報として機能します。
SLSAのより高度なレベル（L3/L4）を達成するためには、in-totoなどのツールと連携し、より詳細なプロベナンス（ビルドステップ、入力、出力など）をAttestationとして記録し、検証する必要があります。Sigstoreはこれらのプロセスを簡素化するためのエコシステムを提供しています。
将来の展望と継続的な改善
ソフトウェアサプライチェーン攻撃は進化し続ける脅威であり、一度対策を講じれば完了というものではありません。継続的な改善と最新動向への追従が不可欠です。
- 脅威インテリジェンスの活用: 最新のサプライチェーン攻撃事例や脆弱性情報を常に監視し、自社のCI/CDパイプラインや依存関係に潜在するリスクを早期に特定します。
- DevSecOps文化の醸成: 開発、運用、セキュリティのチームが密接に連携し、セキュリティを開発ライフサイクルの早期段階から組み込むDevSecOpsのアプローチを推進します。セキュリティ専門家だけでなく、すべてのエンジニアがサプライチェーンセキュリティの重要性を理解し、責任を持つことが重要です。
- 関連フレームワークへの展開: SLSA以外にも、NIST SSDF (Secure Software Development Framework) やOWASP Software Component Verification Standard (SCVS) など、サプライチェーンセキュリティに関連する多様なフレームワークが存在します。SLSAは成果物の出所とビルドプロセスの信頼性に焦点を当てますが、これらのフレームワークと組み合わせることで、より包括的なセキュリティ体制を構築できます。
まとめ
ソフトウェアサプライチェーン攻撃は、現代のデジタル環境における最も深刻な脅威の一つであり、その対策は単なるベストプラクティスを超え、組織全体のレジリエンスを決定する要素となっています。SLSAフレームワークは、CI/CDパイプラインを起点としたサプライチェーンの信頼性を段階的に向上させるための明確なロードマップを提供します。
本稿で解説したソースコードの信頼性確保、ビルドプロセスの隔離と検証、依存関係管理の厳格化、そしてデプロイメントの安全確保といった戦略を体系的に導入することで、開発者はよりセキュアなソフトウェアを構築し、配布することが可能となります。SLSAの導入は一度に達成できるものではなく、組織の成熟度に応じて段階的にレベルアップを図る継続的なプロセスです。この取り組みを通じて、デジタルライフの安全性を高める堅牢な基盤を築き上げていくことが期待されます。