CI/CD パイプラインは、内部で正確に何が行われているかが不透明であることで知られています。たとえ YAML 構成ファイル (命令のパイプライン リスト) を作成したのはあなただったとしても、すべてが記述どおりに正確に行われることをどうやって確認できるでしょうか?さらに悪いことに、ほとんどのパイプラインは完全に一時的なものであるため、何か悪いことが起こったとしても、その後は痕跡が残りません。
簡単に言えば、パイプラインは、ソフトウェア、アプリ、またはアーティファクトをテスト、構築、公開するための自動化された方法です。このようなパイプラインはますます一般的になり、常に複雑になってきています。パイプラインは、チームの作業を高速化して、ソフトウェア アーティファクトを作成する際に、より一貫性のある予測可能な結果を提供するのに最適です。大企業では相互に依存する何百もの調整されたパイプラインを持っている可能性があるため、すべてがスムーズかつ確実に実行されることが重要であることを考えると、これらのプロセスを自動化することの重要性がさらに明確になります。
開発者と最終ユーザーまたはクライアントの間の開発プロセスの最後のリンクとして、そのような自動化されたプロセスが潜在的な攻撃ベクトルとしてどのように使用される可能性があるかについて十分に焦点が当てられていないと感じます。ビルド パイプラインにアクセスすると、悪意のある攻撃者が制作会社のシステムに侵入するだけでなく、将来のすべてのユーザーに影響を与えるような方法で結果として得られるアーティファクトを潜在的に変更して、しばしば「爆発」と表現される巨大な爆発範囲を生み出す可能性があります。 ソフトウェアサプライチェーン攻撃.
前回の記事では、あなたを導くべき原則について説明しました。 CI/CD パイプラインの保護. この記事では、CI/CD パイプラインの一般的な潜在的な弱点をいくつか取り上げ、いくつかの修復オプションを提供します。私たちの目的にとって、どの自動化ツールやシステムを使用しているかは問題ではありません。セキュリティ原則は引き続き有効です。必要なのは、パイプラインのそのセクションを保護する仕事に適したツールを見つけることだけです。
CI/CD の技術をマスターする: 無視できない重要な要素
パイプラインが異なれば、要素も異なり、使用するツールも異なります。私が注目することにした要素は、ほぼすべてのパイプラインに関連するため、SCM、ツール、既存のセキュリティ設定に関係なく、これらの要素を保護することがベスト プラクティスと考えられます。
秘密の管理 – シークレットは通常、ソフトウェアまたはパイプラインを他のリソースに接続するために使用される文字列またはトークンです。一般的な例は、コードを S3 バケットなどの AWS リソースに接続するために使用される API キーです。ほとんどの人は、これらの秘密を非表示にし、オープン リポジトリにプレーン テキストとして含めるべきではないことをすでに知っています。 CI/CD パイプライン内では状況が少し複雑になります。通常、パイプラインは、それらが表すリソースと情報にアクセスするために、これらのシークレットにアクセスする必要があります。つまり、パイプライン内で何が起こっているかにアクセスできる人は誰でも、あなたのシークレットを閲覧してコピーできる可能性があります。パイプライン内であってもシークレットを安全に保つ XNUMX つの方法は、次のようなシークレット管理ツールを使用することです。 ハシコープの保管庫。このようなツールを使用すると、パイプライン内であってもシークレットを難読化できるだけでなく、シークレットのローテーションがはるかに簡単になり、定期的にシークレットを変更できるため、パイプラインからシークレットを盗むことが無価値になります。使用するシークレット管理ツールに関係なく、シークレットを定期的にローテーションすることは、セキュリティ上の良い習慣であると考えられます。
有害なパイプライン実行 (PPE) – ポイズニングされたパイプライン実行 (PPE) は、脅威アクターが CI パイプラインを「ポイズン」できるようにする手法です。つまり、パイプライン命令ファイルで定義されているように、パイプラインのステップや順序を変更することになります。この手法では、ソース コード管理 (SCM) リポジトリの権限を悪用してビルド プロセスを操作します。これにより、悪意のあるコードやコマンドをビルド パイプライン構成に挿入し、パイプラインを汚染してビルド プロセス中に悪意のあるコードを実行することが可能になります。 各ビルドの前にパイプライン命令ファイルを検証しない限り、ビルドが指定どおりに実行されなくなっているという事実については、おそらくわからないでしょう。あるライブラリを別のライブラリよりも呼び出すなどの小さな変更であっても、最終製品にバックドアや暗号通貨マイナーが組み込まれるなど、広範囲に影響を与える可能性があります。
PPE を回避する方法の 1 つは、パイプライン命令ファイルが変更されていないことを確認することです。ファイルに暗号署名を付け、すべてのパイプラインの最初のステップとして署名検証を追加できます。ファイルの署名と検証に使用できるツールは次のとおりです。 ヴァリント、Scribe Securityによって公開されたツール。最終的にどのような署名検証ツールを使用するにせよ、目的は、命令ファイルの整合性が損なわれていないことを確認することです。
キャッシュ/依存関係ポイズニング – CI/CD パイプライン ワークフローは、実行する必要がある特定のアクションを指定するために頻繁に使用されます。各ワークフローは、一連のアクションとして特徴付けられる、一連の 1 つ以上のジョブで構成されています。ワークフローの大部分は、セキュリティ上の理由からリソースを共有しません。ただし、リソースを共有する必要がある場合には回避策があります。すべてのワークフローが平等にアクセスできるキャッシュは、そのような回避策の 1 つです。キャッシュは複数のワークフローで共有されるため、キャッシュを変更する権限を持つワークフローで 1 回の違反を行うだけで、その後のすべてのワークフローの使用に対してキャッシュが有害になります。独身者 毒されたキャッシュ キャッシュはダウンロードする新しいアーティファクトまたはパッケージがある場合にのみ更新されるため、非常に長期間アクティブになる可能性があり、そのパイプラインで実行されているソフトウェア ビルドの無数の反復に影響します。
パイプライン命令ファイルの検証と同様に、次を使用できます。 ヴァリント パイプラインに必要なすべての事前承認された依存関係を含むキャッシュまたはフォルダーに署名し、後で検証します。あなたが偏執的なタイプの場合、パイプラインが独立してインターネットに接続し、必要と判断されるライブラリをダウンロードできるようにすることが、最終ビルドにさらに多くの脆弱性や悪用の可能性を取り込む確実な方法です。
SSHキー – SSH キーは、SSH (セキュア シェル) ネットワーク プロトコルのアクセス資格情報です。このネットワーク プロトコルは、コンピュータ上のマシン間のリモート通信に使用されます。 安全でないオープンネットワーク。 SSH は、リモート ファイル転送、ネットワーク管理、およびリモート オペレーティング システム アクセスに使用されます。たとえば、SSH キーを使用すると、訪問するたびにユーザー名と個人アクセス トークンを入力しなくても、GitHub に接続できます。 SSH キーを使用してコミットに署名することもできます。同様に、次のような SSH キーを使用して他のアプリケーションを GitHub に接続できます。 BitBucket & GitLab.
アカウントのセキュリティを維持するには、SSH キーのリストを定期的に確認し、無効なキーや侵害されたキーをすべて取り消すか削除する必要があります。 GitHub の場合、SSH キーのリストは次のページで確認できます。
アクセス 設定 > SSHおよびGPGキー
SSH キーを常に最新の状態に保つのに役立つツールの 1 つは、オープンソースのセキュリティ体制レポートです。 ギットガット。 GitGat レポートは、構成された SSH キーのいずれかが期限切れになっているか、無効である場合に警告を発します。 GitHub は、キーを注意深く監視し、頻繁にローテーションすることに加えて、見慣れない SSH キーを見つけた場合はすぐに削除し、連絡してくださいと警告しています。 GitHub サポート さらに助けが必要です。未確認の公開キーは、セキュリティ侵害の可能性を示している可能性があります。
不変パイプライン ログとしての SLSA 来歴 – SLSA Supply Chain Levels for Software Artifacts の略で、ソフトウェア サプライ チェーンのセキュリティと整合性の向上を支援するために、Google とその他の業界パートナーによって開発されたフレームワークです。
SLSA は 4 つのレベルのセットを定義しており、各レベルはソフトウェア サプライ チェーンにおけるより高いレベルの信頼と保証を表します。各レベルでは、セキュリティ要件が段階的に増加します。重要な要件の 1 つは、ファイルの来歴の必要性です。 SLSA フレームワークの場合、
来歴とは、何かがどこで、いつ、どのように作成されたかを説明するソフトウェア成果物に関する検証可能な情報です。 CI/CD パイプラインの目的のほとんどは何か (通常はビルド) を生成することであるため、どのファイルが入ったのか、それらに何が起こったのかを正確に追跡できることは、パイプラインの一種の改ざん不可能なマシン ログとなります。この目的のためには、SLSA 来歴がどのユーザーからも独立して作成されることが重要です。ユーザーが中断または変更できるものはすべて、整合性が疑わしい可能性があります。
さまざまな SCM システムのパイプラインに SLSA 来歴を作成できるツールの 1 つが次のとおりです。 ヴァリント (そう、Scribe の同じツールです。非常に多用途なツールです)。このリンクでは、Valint を GitHub パイプラインに接続して、そのパイプラインで実行される各ビルドの SLSA 来歴を生成する方法を示します。後で各来歴ファイルにアクセスして、何か不都合なことが起こったか、または予期せぬことが起こったかどうかを確認することができます。以下は、そのような出所ファイルの抜粋です。
来歴ファイルは単なる JSON ファイルですが、来歴ファイルを読み取る自動化ツールが (まだ) ないため、ファイルを読み取って解釈する作業はユーザーの責任になります。
最終結果を確保する – 最近のソフトウェア サプライ チェーン侵害の中で最もよく知られているのは、次のようなものです。 SolarWindsインシデント。その中でハッカーは、会社からリリースされる各ビルドに秘密のバックドアが含まれるように、ビルド サーバー内のコードを変更しました。最終結果を破損するもう 2020 つの有名なケースは、XNUMX 年に発生したベトナム政府認証局 (VGCA) のハッキングで見られます。 サインサイト作戦。侵入者は VGCA Web サイトに侵入し、ダウンロード リンクをマルウェアを混入した独自のバージョンのソフトウェアにリダイレクトしました。どちらの場合も、エンド ユーザーは、入手したソフトウェアが制作会社がリリースしようとしていたソフトウェアであることを確認する方法がありませんでした。
より単純な攻撃は、パイプラインの最後に構築された最終イメージを悪意のあるイメージに置き換え、その悪いイメージを必要な場所にアップロードすることです。このような攻撃のほとんどでは、画像は制作会社から送信されていると考えられるため、たとえその会社が有効な証明書によって保護されていたとしても、それだけでは十分ではありません。そうすれば偽物の信憑性がさらに高まるだけだ。
もう一度言いますが、解決策は、パイプラインによって生成される最終成果物が何であれ、暗号的に署名し、エンドユーザーがその署名を検証できるようにすることです。
すでに述べたので ヴァリント オープンソースの使用を提案します Sigstore のコサイン。 Cosign は、主要なインフラストラクチャの必要性を排除することで、署名を容易にすることを目指しています。これにより、ユーザーはオンラインで検証された ID (Google、GitHub、Microsoft、AWS など) をキーとして使用できるようになります。 Cosign を使用すると、イメージの署名と検証の両方に使用できるため、パイプラインの最終構築イメージの署名とその後の検証に最適です。
Valint を使用するか Cosign を使用するかに関係なく、ユーザーが最終アーティファクトの暗号署名を検証して、意図したものを正確に取得していることを確認できるようにすることは、ほとんどのエンド ユーザーが高く評価すると確信しています。
将来のパイプラインのセキュリティ
もちろん、ビルド パイプラインには、セキュリティの強化によって恩恵を受ける可能性のある他の要素も含まれています。この記事では、より明白なパイプライン要素とより脆弱なパイプライン要素のいくつかを取り上げることにしました。
使用しているパイプライン ツールやインフラストラクチャが何であれ、侵害の可能性に常に目を光らせてください。完全に安全であるというシステムを盲目的に信用しないでください。
個人情報の盗難、スピア フィッシング、その他の正当なアクセスを偽造する脅威の増大を考慮すると、署名検証メカニズムはデジタル ツールボックスに含めるべき優れた多用途ツールであると考えています。
画像、ファイル、フォルダーに署名する必要がある場合でも、そのようなニーズに対応するワンストップ ショップ ツールとして Scribe Security の Valint を詳しく調べてみることをお勧めします。
このコンテンツは、エンドツーエンドのソフトウェア サプライ チェーン セキュリティ ソリューションの大手プロバイダーである Scribe Security によって提供されており、ソフトウェア サプライ チェーン全体のコード成果物とコード開発および配信プロセスに最先端のセキュリティを提供しています。 もっと詳しく知る。
関連記事
