CI/CD パイプライン内で何が起こっているかの詳細は、悪名高いほど不透明です。命令のパイプライン リストである YAML 構成ファイルを作成したにもかかわらず、すべてが記述どおりに正確に行われることをどうやって確認できるのでしょうか?さらに悪いことに、パイプラインの大部分は完全に一時的なものであるため、誤動作が発生した場合でも、ログに記録された内容以外に、問題の詳細が含まれる場合と含まれない場合がある証拠がほとんどありません。
自動化された継続的インテグレーション/継続的デリバリー (CI/CD) パイプラインの使用により、迅速な開発が実現します。コードを自動的にコンパイル、ビルド、テスト、出荷するトリガーやスケジュールを設定できるのは素晴らしいことです。ただし、ほとんどのパイプラインはセキュリティを念頭に置いて構築されておらず、速度と使いやすさを重視して設計されています。通常、パイプラインは依存関係やファイルをダウンロードするためにインターネットへのアクセスを必要とするため、パイプラインが侵害されると、攻撃者は操作を妨害したり、情報や機密を漏洩したりするためのさまざまなオプションを利用できるようになります。
この記事では、CI/CD パイプラインを保護するために導入できるベスト プラクティスのいくつかについて説明します。私たちの目的にとって、どの自動化ツールやシステムを使用しているかは関係ありません。セキュリティ原則は依然として有効です。必要なのは、パイプラインのそのセクションを保護する作業に適したツールを見つけることだけです。
CI/CD (継続的インテグレーション/継続的デリバリー) パイプラインとは何ですか?
CI/CD パイプラインは、ソフトウェア、アプリケーション、またはアーティファクトを構築、テスト、公開するための自動プロセスです。これらのパイプラインはますます一般的かつ複雑になってきています。パイプラインは、チームの生産性を向上させ、ソフトウェア成果物をより一貫して予測どおりに作成するための優れたツールです。これらの手順を自動化することの重要性は、大企業では相互接続され、振り付けられたパイプラインが数百本あり、そのすべてが相互に依存して適切に機能する可能性があることを考慮すると、より明らかになります。
新しい最終製品へのコード変更を自動的かつ定期的に構築およびテストすることは、継続的インテグレーション (CI) として知られています。コーディングの変更は、継続的デリバリーおよび/またはデプロイメント (CD) と呼ばれる 2 段階のプロセスの一部として配信、テスト、統合されます。継続的デプロイメントでは、更新が実稼働環境に自動的に配信されますが、継続的配信は、実稼働環境への自動デプロイメントの直前に停止します。パイプラインでどちらを使用するかは、環境と成果物のセットアップ方法によって完全に決まります。
ソフトウェア サプライ チェーンにおける CI/CD セキュリティの重要性
ほとんどの企業が依存しているのは、 CI / CDツール パイプラインを自動化するために。つまり、他の多くの人と同様に、 ソフトウェアサプライチェーン攻撃、悪者が必要とするのは、単一のターゲットを突破して広大な爆発範囲を獲得することだけです。主要な弱点の 1 つは、パイプラインが依存関係をダウンロードして最終製品または成果物に統合する必要があることです。不適切な依存関係が 1 つでもあると、パイプライン内で不要な要素に足がかりを与えるのに十分です。パイプラインはソース コードやインフラストラクチャのその他のさまざまな要素に (必要に応じて) アクセスできるため、権限昇格により、その特定のパイプラインで作成された製品のほぼすべての部分にアクセスし、後で変更または漏洩する可能性があります。
簡単な例は、 キャッシュまたは依存関係のポイズニング.
ここ数年、いくつかの大企業が、CI/CD パイプラインを発信源とするソフトウェア サプライ チェーン攻撃の被害を受けてきました。たとえば、次のように見ることができます CircleCI の侵害 2023 年 XNUMX 月に、 Argo CD の妥協点 2022 年 XNUMX 月に、 コードコーブ侵害 4月の2021。
このような攻撃の潜在的な影響は深刻であるため、パイプラインができる限り安全であることを確認するためにできる限りのことを行うのは理にかなっています。
CI/CD セキュリティのベスト プラクティス
使用している CI/CD プラットフォームやツールが何であっても、セキュリティを強化し、万が一敵対的な攻撃者がパイプラインやネットワークにアクセスした場合の潜在的な被害を軽減するためにできることがいくつかあります。
監視と警告 – フィッシングやその他のソーシャル エンジニアリング詐欺に注意するようにエンジニアをトレーニングしていても、侵害が発生する可能性があります。パイプライン環境の大部分は一時的なものであるため、作業が完了すると、積極的にログを記録しない限り、多くの痕跡は残りません。各 PR、マージ、ビルド、テストの作業を行うときは、環境または構成ファイルに加えられた変更がログに記録されていることを確認してください。問題が発生した場合に調査できるよう、ユーザー データも他のすべてのデータとともに記録する必要があります。ここでの目的は、侵害を再構築し、何が問題で、どのように問題が発生したかを特定できるようにすることです。事前にアラートをトリガーするイベントを選択し、適切な関係者に通知するようにしてください。無意味な警告や過度に敏感な警告で個人を圧倒しないように注意してください。これはアラート疲労につながる可能性があり、単にアラートを無視したり、賢明よりもはるかに遅れて反応したりするだけです。
最小特権と組み合わせた RBAC 原則を使用する – 組織内のユーザーの指定された役割または職務に基づいてシステム リソースへのアクセスを提供することは、役割ベースのアクセス制御 (RBAC) の基礎です。ユーザーには、ファイル、フォルダー、プログラムなどのさまざまなシステム リソースへのアクセス権とアクセス許可を指定するロールが RBAC で与えられます。一方、最小特権の概念は、職務を実行するために必要な最小限のアクセス権と特権をユーザーに与える慣行を指します。これは、ユーザーが割り当てられたジョブを完了するために必要なリソースのみを使用し、それ以上は使用しないことを意味します。最小特権と RBAC は、補完的なセキュリティ概念として組み合わせて適用されることがよくあります。最小特権の原則により、ユーザーは特定の職務を実行するために必要な最小限のリソースのみにアクセスできるようになり、RBAC はユーザーに職務の実行に必要なリソースへの適切な量のアクセスのみを提供する役割を割り当てます。 。これらのガイドラインを組み合わせると、適切に保守された比較的安全なシステムを維持するのに役立ちます。追加のセキュリティ層として、重要なシステム操作に対して複数のユーザー認証を要求するように構成できます。この戦略は、開発プロセスに大幅な遅延を引き起こす可能性があるため、慎重に使用する必要があります。
パイプラインの来歴を不変のログとして保存する – 何かがどこで、いつ、どのように作成されたかを説明するソフトウェア成果物に関する検証可能な情報は、来歴として知られています。パイプライン内でどのファイルが入力され、それらのファイルに何が起こったかを正確に知ることで、そのパイプラインの改ざん不可能なログを形成する出所ファイルとして生成できます。ユーザーが破壊したり変更したりできるものは完全に信頼できるものではないため、安全性を確保するには、来歴をユーザーとは独立して作成する必要があります。 スクライブのヴァリント あなたがすることができます 出所を確立する 幅広い SCM システムのパイプラインに組み込まれます。各来歴ファイル (JSON) は後でアクセスできるため、それを確認して、予期しないまたは望ましくないことが発生していないかどうかを判断できます。ちなみに、パイプライン全体からの出所ファイルの生成と管理は、 SLSA フレームワーク.
SBOMを最大限に活用する – 潜在的な用途をいくつか見逃した場合に備えて、パイプラインの最後に作成された SBOM は、使用されているすべてのオープンソース パッケージをリストするのに役立ちます。そのリストを既知の CVE と比較すると、最終製品にどのような潜在的な脆弱性が存在するかを知ることができます。このリストを使用して、古いバージョンのオープンソース パッケージをまだ使用しているかどうかを確認したり、次のようなものを使用したりすることもできます。 OpenSSF スコアカード 使用しているパッケージの「健全性」を確認します。新しい CVE は常に明らかになっているため、1 回限りの SAST とは異なり、既存のパッケージに新しい CVE が検出されたかどうかを知らせるサービスが必要です。 Scribe のサービスは、これらすべてを自動的に行うのに役立ちます。
ポリシーへの準拠を確認する – 各企業、場合によっては各パイプラインには、すべてが正常であることを確認するために必要なポリシーがあります。ポリシーの中には一般的なもの (2 人による検証プロセスがあることを確認するなど) もあれば、独自のもの (最新の変更を運用環境に出荷する前にマイクが承認していることを確認するなど) もあります。暗号化署名検証メカニズムと独自のポリシー ファイルを利用して、各パイプラインに必要なポリシーを含めて、それらが実行されたことを (自分自身に対しても他の人に対しても) 検証できるようになりました。これは人間の弱点であり、ストレスを感じると、期限を守るために一部の要件を無視したり、一部のルールを曲げたりする可能性があります。この措置を導入すると、人々はルールを曲げることができなくなり、内部と外部の両方の脅威からパイプラインのセキュリティを維持できるようになります。 Scribe は、そのようなポリシーを強制し、独自のポリシーを作成することもできる新しい方法を開発しました。それをチェックしてください こちら.
パイプラインの命令ファイルを保護する – 脅威アクターは、ポイズニングされたパイプライン実行 (PPE) として知られる手法を使用して CI パイプラインを「汚染」する可能性があります。これは基本的に、パイプライン命令ファイルで最初に指定されていたパイプライン ステージまたはそのシーケンスを変更します。このメソッドは、ソース コード管理 (SCM) リポジトリの権限を悪用してビルド プロセスを操作します。ビルド パイプライン設定に悪意のあるコードまたはコマンドを挿入すると、パイプラインが汚染され、ビルドの完了中に悪意のあるコードが実行される可能性があります。パイプライン命令ファイルを確認するまで、ビルドが意図したとおりに動作していないことはわかりません。パイプラインが意図したとおりに実行されていることを確認するには、各実行前に命令ファイルを確認する必要があります。暗号的には、ファイルに署名し、パイプラインの最初のステップとして署名検証を追加することが、そのセキュリティを実現する 1 つの方法です。スクライブのヴァリント 署名して確認する 関数は、新しいパイプラインの実行を開始する前に、命令ファイルが変更されていないことを確認する 1 つの方法です。
最終結果を確実に確保する – 最終製品を不正なバージョンに置き換える方がはるかに簡単であるにもかかわらず、攻撃者がパイプラインを妨害するためになぜ懸命に取り組む必要があるのでしょうか?この種の攻撃では、生成元の会社がイメージのソースであると思われるため、その会社がイメージを保護する有効な証明書を持っているだけでは不十分です。簡単に言うと、偽物の信頼性が高まるということです。解決策は、パイプラインによって生成される最終成果物が何であれ、暗号的に署名し、エンド ユーザーがその署名を検証できるようにすることです。 Scribe's Valint を使用すると、 署名して確認する さまざまなアーティファクトにより、ユーザーが意図したものを正確に取得できるという追加のセキュリティが提供されます。
未来を見据えて
作業を効率化するために CI/CD などの自動化技術の使用をやめる人はいません。それどころか、私たちが住んでいる世界では、ソフトウェア更新のイテレーションの高速化を常に推進しています。少なくとも、その過程で本番環境やソースコードを危険にさらさないように注意しながら、慎重にタスクに取り組む必要があります。
重要なことは、誰かがパイプライン、環境、またはソース コードに違法にアクセスした場合の潜在的な結果を考慮することです。それがどれほど危険であるか、パイプラインやネットワークが最も影響を受けやすい場所がわかれば、潜在的な漏洩を阻止または軽減するための適切な措置を講じることができると確信しています。
相互接続されたパイプラインはますます複雑になるため、パイプラインを保護するための最初のステップとして、環境全体のセキュリティ (セグメント化されたネットワーク、RBAC、ゼロトラストなど) を維持することが重要です。その後、確実で反証不可能な証拠を作成し、データの暗号化署名と検証を採用して、パイプラインまたはパイプラインのキャッシュを汚染する可能性のあるソフトウェア サプライ チェーン攻撃の可能性を可能な限り軽減するように努めます。常に警戒し、疑いを持ち続けることで、会社の計り知れない頭痛の種を軽減できる可能性があります。
このコンテンツは、エンドツーエンドのソフトウェア サプライ チェーン セキュリティ ソリューションの大手プロバイダーである Scribe Security によって提供されており、ソフトウェア サプライ チェーン全体のコード成果物とコード開発および配信プロセスに最先端のセキュリティを提供しています。 詳しくはこちら。
関連記事
