2024年6月21日

NECサイバーセキュリティ戦略統括部セキュリティ技術センターの浦川です。
今回のブログでは、CI/CDパイプラインのセキュリティについて考えるためにOWASP Top 10 CI/CD Security Risksを紹介します。

目次

CI/CDパイプラインとは

最初にCI/CDパイプラインについて簡単な説明をします。
CI/CDパイプラインはDevOpsやDevSecOpsを実現するための1つの要素で、利用することで迅速なアプリケーションのリリースの実現や高い品質保証などの様々な利点があります。
CI/CDパイプラインの流れを図1に示します。

CI/CDパイプラインは継続的インテグレーション（CI：Continuous Integration）と継続的デリバリー（CD：Continuous Delivery）の2つの部分で構成されています。継続的インテグレーションでは、開発フェーズでコードに変更があるたびもしくは定期的にビルドとテストを行います。継続的デリバリーでは、継続的インテグレーションでビルドされた成果物を保存し、本番環境へデプロイ可能な状態にします。また、継続的デリバリー内で検証環境へのデプロイまでを実施する場合もあります。

CI/CDパイプラインのセキュリティの必要性

ひと昔前までは、パイプラインの大部分を外部からアクセスができないオンプレミスで構築していることにより、パイプラインの外部からの脅威に対するセキュリティについて考える必要は少なかったかもしれません。しかし、昨今は開発やCI/CDの高速化、パイプラインの構築、運用コストの削減を目的にコードリポジトリにGitHub[1]、パイプラインにAWS CodePipeline[2]やAzure Pipelines[3]などのパブリックサービスを使用することが一般的になってきています。パブリックサービスでは、適切な設定や管理が不足している場合に外部から簡単にアクセスされてしまうため、パイプラインのセキュリティの必要性が高まっています。
加えて、CI/CDパイプラインは本番環境のインフラストラクチャやアプリケーションのデプロイ、シークレットへのアクセスなどの広範囲かつ高い権限を持つことが多いです。そのため、侵害された際の影響が非常に大きくなるといった点もパイプラインのセキュリティが必要であるという理由の1つに挙げられます。非常に大きな影響を与えたCI/CDパイプラインへの攻撃として2020年に発覚したSolarWindsのサプライチェーン攻撃[4]があります。この攻撃の結果、18,000以上の顧客へ悪意のあるコードを含んだアップデートが拡散されるという大きな被害をもたらしました。

また、CI/CDパイプラインのセキュリティに関するガイドラインが国内外で発行されています。
2023年6月には米国のCISA（Cybersecurity and Infrastructure Security Agency）とNSA（National Security Agency）から「Defending Continuous Integration/Continuous Delivery (CI/CD) Environments」[5]が発行されました。本ガイドラインでは、CI/CDセキュリティの脅威や認証とアクセス、開発環境、開発プロセスにおける軽減策や保護するためのベストプラクティスについて説明されています。
2024年3月には日本のデジタル庁から「CI/CD パイプラインにおけるセキュリティの留意点に関する技術レポート」[6]が発行されました。本ガイドラインでは、CI/CDパイプラインにおけるフェーズごとの対策について説明されています。
国内外でガイドラインが発行されていることからも、CI/CDパイプラインのセキュリティの必要性が高まっていることが分かります。

OWASP Top 10 CI/CD Security Risks

本章では実際のCI/CDパイプラインの脅威と対策を考えるためにOWASP Top 10 CI/CD Security Risks[7]を紹介します。
本プロジェクトでは、CI/CDパイプラインのリスクのトップ10がまとめられており、それぞれのリスクに対する影響と対策のための推奨事項が説明されています。
OWASP Top 10 CI/CD Security Risksのリスクの一覧と概要について表1に示します。

CI/CDのパイプラインの特有の脅威は当然ありますが、対策の考え方や推奨事項については特別なものは多くありません。対策の推奨事項としては、一般的なセキュリティ対策をCI/CDパイプライン全体もしくは各構成要素に適用することになります。
トップ10の内、以下5つのリスクについては影響対象がCI/CDパイプライン全体もしくはその構成要素ですが、対策はアプリケーションやユーザ管理の一般的なセキュリティ対策と類似したものと考えることができます。

他のリスクと比べて対策は一般的なセキュリティ対策と類似すると考える5つのリスクとその対策を表2に示します。

本ブログでは、CI/CDパイプラインのリスクのトップ10の中でパイプラインのリスクとして他と比べて特に特徴的であると考える以下5つのリスクについて詳しく見ていこうと思います。

CICD-SEC-1：不十分なフロー制御メカニズム

本リスクの概要を図2に示します。

本リスクは、コードや成果物を追加する際に承認やレビューを強制するメカニズムがないことにより、何らかの方法でシステムのアクセス許可を得た攻撃者が悪意のあるコードや成果物をリポジトリやパイプライン内に挿入できてしまうといったリスクです。本リスクを悪用されると、悪意のあるコードや成果物が本番環境にデプロイされてしまいます。
本リスクの特徴的な点として、以下のような開発フェーズでの対策が挙げられています。

1点目の対策については、適切なワークフローで承認を得たうえでリポジトリにコードをマージするというものになります。例として、GitHubのブランチ保護ルールで設定できる本リスクの対策に有効な項目の一部を以下に示します。具体的な設定方法やその他の設定項目の詳細については[8]を参照してください。

2点目の対策については、レビュー（承認）なしのプッシュでは自動でパイプラインを実行しないように設定すべきというものになります。基本的にはブランチ保護ルールで他者の承認がない場合はプッシュできないようにすべきですが、何らかの理由で例外を設ける場合は本番環境に承認されていない変更が反映されないように適切なトリガーを設定することが重要です。

CICD-SEC-3：依存関係チェーンの悪用

本リスクの概要を図3に示します。

本リスクは、コードの依存関係の欠陥を悪用して悪意のあるパッケージを取得、利用してしまうといったリスクです。本リスクを悪用されると、悪意のあるパッケージを利用した環境のシークレットの盗難や本番環境への悪意のあるパッケージの挿入につながります。
実際にPythonのPyPIやNode.jsのnpmといったリポジトリ内に悪意のあるパッケージを配置するといった本リスクを悪用した攻撃が実施されています。[9][10]
本リスクについては、開発フェーズやビルドフェーズでの依存する外部パッケージの取得方法や外部パッケージそのものに対して注意をしなければならないといったこと自体が特徴的であると考えます。
挙げられている対策の一部を以下に示します。

また、本リスクに関連するガイドラインとして、2024年2月にNIST（National Institute of Standards and Technology）からCI/CDパイプラインのソフトウェアサプライチェーン（SSC）セキュリティに関するガイドラインの最終版である「SP 800-204D Strategies for the Integration of Software Supply Chain Security in DevSecOps CI/CD Pipelines」[11]が発行されました。本ガイドライン内でSSCセキュリティの一部として依存する悪意のある外部パッケージの脅威と緩和策について説明されています。

CICD-SEC-4：ポイズニングされたパイプライン実行 （PPE）

本リスクは、パイプラインにはアクセスできないがコードリポジトリにはアクセスできる攻撃者が、任意のコードやコマンドをコードリポジトリに挿入してパイプライン内で悪意のあるコードを実行できるといったリスクです。本リスクの概要は、図2と同様になります。本リスクを悪用されると、パイプライン内のシークレットの盗難やパイプライン内の様々な構成要素への水平展開につながります。
本リスクの特徴的な点は、「CICD-SEC-1：不十分なフロー制御メカニズム」と同様で開発フェーズでの対策が挙げられていることになります。開発フェーズの対策としては同様で、パイプラインをトリガーするブランチに適切なブランチ保護ルールを設定して、承認されていない変更がプッシュされないようにすることが挙げられています。
その他の対策は比較的一般的でパイプラインやユーザへの最小権限の原則の適用や機密度の異なる環境の分離などがあります。

CICD-SEC-6：不十分な資格情報の衛生管理

本リスクの概要を図4に示します。

本リスクは、資格情報のアクセス制御や管理の欠如により、パイプライン内で使用する様々なシークレットやトークンなどを攻撃者が取得できるといったリスクです。CI/CDパイプライン内では様々な処理で複数の資格情報を使用しています。そのため、適切に資格情報を扱わないと意図しない場所に資格情報が含まれてしまうといったことが生じてしまいます。
挙げられている推奨事項の内、特徴的な対策を以下に示します。

1点目については、開発フェーズでシークレットがコードリポジトリにプッシュされてしまった場合の対応です。プッシュされないようにGitフックのpre-commitフックでシークレットをコミットできないようにするという事前対策を取れば定期的なスキャンは不要なのではないかと思われるかもしれません。しかし、-nまたは--no-verifyオプションを付けてコミットすればpre-commitフックを無視してコミットすることが簡単にできてしまうことと、悪意を持ってシークレットをコミットされる場合もあるため、定期的なスキャンも合わせて実施することが効果的です。また、スキャンでシークレットが存在していることが分かった場合は、すぐに当該資格情報をローテーションして悪用の履歴がないか確認することが重要です。
2点目については、パイプライン実行時のコンソール出力にシークレットが出力されてしまうことに対する対策です。コンソール出力にシークレットが出力されてしまうと、ビルド結果にアクセス可能なユーザが全員シークレットを閲覧できてしまい、シークレットの悪用や責任追跡性の喪失につながります。適切な設定をしてコンソール出力やログ内にシークレットが含まれないようにすることが重要です。
3点目は、ビルド後の成果物からシークレットが漏洩することに対する対策です。シークレットが含まれた成果物を本番環境にデプロイしてしまうことやシークレットを含んだレイヤーを持つイメージをDocker Hubの公開リポジトリにアップロードしてしまうことなどで生じる漏洩を防ぐために重要な対策です。
その他の対策は比較的一般的でパイプラインへの最小権限の原則の適用や資格情報の共有の禁止、一時的な資格情報の使用、定期的な資格情報のローテーションなどがあります。

CICD-SEC-9：不適切な成果物の整合性検証

本リスクの概要を図5に示します。

本リスクは、コードと成果物の検証の欠如により、CI/CDパイプライン内のいずれかのシステムにアクセスできる攻撃者が悪意のあるコードや成果物をパイプラインに挿入できるといったリスクになります。本リスクを悪用されると、悪意のある成果物をビルドしてしまい、パイプライン内や本番環境上での悪意のあるコード実行につながります。
コードや生成された成果物に対して適切な署名や検証を行うことにより、確実に整合性検証を行い、正しいものであることであることを確認することが対策として重要になります。加えて、パイプライン内で取得されるサードパーティのコードやパッケージなどについても同様に検証を行うことが重要です。

まとめ

今回は、CI/CDパイプラインのセキュリティについて考えるために、OWASP Top 10 CI/CD Security Risksを紹介しました。また、その中でもCI/CDパイプラインのリスクとして特に特徴的であると考える5つのリスクについて詳しく見てきました。また、5つのリスクの対策の内、以下の重要性について詳細に見てきました。

本番環境のアプリケーションのセキュリティは十分に考慮しているが、CI/CDパイプラインについてはあまり考慮できていない場合は、ぜひ一度自身の環境を見直してチェックしていただければと思います。

参考文献

執筆者の他の記事を読む