CI/CD Security

CI/CDセキュリティとは、継続的インテグレーション（CI）と継続的デリバリー/デプロイ（CD）のパイプラインにおけるセキュリティリスクを特定・軽減し、ソフトウェアのビルド・テスト・デプロイプロセス全体の完全性を確保するための取り組みです。CI/CDパイプラインはソースコードから本番環境への自動化された経路であり、攻撃者にとってはサプライチェーン攻撃の格好の標的となります。

CI/CDパイプラインには、ソースコードリポジトリ、ビルドサーバー、テスト環境、アーティファクトレジストリ、デプロイ先環境といった多数のコンポーネントが関与します。各コンポーネント間の接続にはシークレット（APIキー、トークン、認証情報）が使用されるため、これらの適切な管理が不可欠です。シークレットがソースコードやログに漏洩した場合、攻撃者は本番環境への不正アクセスが可能になります。

近年では、SLSA（Supply-chain Levels for Software Artifacts）フレームワークが注目されています。SLSAはGoogleが提唱したソフトウェアサプライチェーンの完全性を段階的に保証するフレームワークで、ビルドプロセスの来歴（Provenance）記録、ビルド環境の分離、ソースコードの改ざん防止など、CI/CDセキュリティのベストプラクティスを体系化しています。

パイプラインにおけるシークレット管理

CI/CDパイプラインでは、クラウドプロバイダーの認証情報、データベース接続文字列、APIキー、デプロイ用のSSH鍵など、多数のシークレットが使用されます。これらのシークレットを安全に管理するためには、HashiCorp Vault、AWS Secrets Manager、Azure Key Vaultなどの専用シークレット管理サービスを活用し、環境変数やCI/CDプラットフォームのシークレットストアを通じてパイプラインに注入する必要があります。

絶対に避けるべきは、シークレットをソースコードにハードコードしたり、設定ファイルにプレーンテキストで記載したりすることです。また、CIログにシークレットが出力されないよう、マスキング設定を適切に行い、フォークされたリポジトリからのプルリクエストにシークレットが漏洩しないよう制限を設ける必要があります。

ビルド完全性とSLSAフレームワーク

SLSA（Supply-chain Levels for Software Artifacts）は、ソフトウェアアーティファクトが改ざんされていないことを保証するためのフレームワークです。レベル0（無保証）からレベル4（最高保証）まで段階的に定義されており、各レベルで求められるセキュリティ要件が異なります。

SLSA Level 1ではビルドプロセスの文書化と来歴情報（Provenance）の生成が求められ、Level 2ではホスティングされたビルドサービスの利用と来歴の改ざん防止が求められます。Level 3ではビルド環境の完全な分離と来歴の暗号署名が必要となり、Level 4では密閉的（Hermetic）ビルドとすべての依存関係の完全なロックダウンが求められます。

GitHub Actionsのセキュリティリスク

GitHub Actionsは広く利用されるCI/CDプラットフォームですが、固有のセキュリティリスクが存在します。サードパーティのアクションを利用する際、タグ（v1など）ではなくコミットSHAでピン留めすることが推奨されます。タグは上書き可能であり、悪意のあるアクション作成者がタグを変更して悪意のあるコードを注入する可能性があります。

また、pull_request_targetイベントは、フォークされたリポジトリからのプルリクエストにもリポジトリのシークレットへのアクセスを許可するため、悪意のある外部コントリビューターにシークレットが漏洩するリスクがあります。ワークフローファイル内でのスクリプトインジェクション（PRタイトルやブランチ名を未サニタイズで使用）にも注意が必要です。

Jenkinsのセキュリティ強化

Jenkinsは柔軟性の高いCI/CDツールですが、その柔軟性ゆえにセキュリティリスクも伴います。Jenkinsのマスターノードは高い権限を持つため、ビルドジョブはエージェントノードで実行し、マスターノードへのアクセスを最小限に制限すべきです。プラグインの脆弱性も大きなリスク要因であり、使用するプラグインを最小限に保ち、定期的にアップデートすることが不可欠です。

Jenkinsfile（パイプライン定義）はソースコードリポジトリに格納し、レビュープロセスを経ることで、パイプラインの改ざんを防止できます。共有ライブラリの使用時にも、信頼できるソースからのみロードするよう制限し、@Library注釈で特定のバージョンをピン留めすることが推奨されます。

サプライチェーン攻撃の脅威

CI/CDパイプラインを標的とするサプライチェーン攻撃は急増しています。攻撃者はビルドプロセスに介入してマルウェアを注入したり、依存関係を差し替えたり、ビルドスクリプトを改ざんしたりすることで、正規のソフトウェアアップデートを通じて大量のシステムに攻撃を展開します。

防御策として、ビルドアーティファクトの暗号署名と検証、ビルド環境のエフェメラル（一時的）化、ビルドログとメタデータの改ざん防止保管、コードレビューの必須化、マージ前のセキュリティスキャン統合などが有効です。Sigstoreプロジェクトが提供するCosign、Rekor、Fulcioなどのツールは、ソフトウェアアーティファクトの署名と検証を容易にします。

• 01
  シークレットの安全な管理と最小権限の原則：HashiCorp VaultやAWS Secrets Managerなどの専用ツールを使用してシークレットを管理し、各ジョブに必要最小限の権限のみを付与してください。シークレットをソースコードやログに含めず、定期的なローテーションを実施しましょう。
• 02
  サードパーティアクション・プラグインのピン留めと監査：GitHub ActionsではサードパーティアクションをコミットSHAでピン留めし、Jenkinsでは使用プラグインを最小限に保ってください。定期的にアクション・プラグインの脆弱性情報を確認し、不要なものは削除しましょう。
• 03
  ビルド環境の分離とエフェメラル化：ビルドごとにクリーンなコンテナやVMを使用し、前回のビルドの残留物による汚染を防止してください。ビルド環境を一時的（エフェメラル）にすることで、永続的な侵害を防ぎます。SLSAフレームワークに準拠したビルドプロセスの導入を検討しましょう。
• 04
  ビルドアーティファクトの署名と来歴（Provenance）記録：ビルドアーティファクトにデジタル署名を施し、SLSAの来歴情報を生成・保管してください。Sigstore（Cosign）などのツールを活用し、デプロイ時に署名検証を行うことで、改ざんされたアーティファクトの実行を防止しましょう。
• 05
  パイプライン定義のコードレビューと保護：Jenkinsfile、.github/workflows/配下のYAMLファイルなどのパイプライン定義ファイルは、アプリケーションコードと同様にコードレビューを必須化してください。ブランチ保護ルールを設定し、パイプライン定義の無断変更を防止しましょう。
• 06
  パイプラインの監査ログと異常検知：すべてのパイプライン実行の詳細なログを保管し、異常なビルドパターン（深夜の実行、通常と異なるブランチからのデプロイ、シークレットへの異常なアクセスなど）を検知するアラートを設定してください。定期的な監査により、不審な活動を早期に発見しましょう。