プロアクティブな防御: コード パイプラインと CI / CD インフラストラクチャの強化

※この投稿は米国時間 2026 年 9 月 25 日に、Google Cloud blog に投稿されたものの抄訳です。

はじめに

ソフトウェア サプライ チェーン セキュリティを取り巻く状況は大きく変化しています。最近の攻撃キャンペーンでは、高度な脅威アクターが、信頼できるセキュリティ ツールやプログラミング ツールを侵害することで、エンジニアリング ライフサイクルを体系的に標的にしていることが示されています。

このような侵入から、以下の 3 つの主な戦術が明らかになっています。

• 攻撃者は、信頼できるセキュリティ スキャナ、ユーティリティ ライブラリ、AI 開発者のツールを標的にして、ビルド パイプライン内でこれらのシステムに付与された高い権限を悪用しようとします。

• 攻撃者は、高度にカスタマイズされたソーシャル エンジニアリング、悪意のある拡張機能、タイポスクワットしたローカル依存関係などを介し、開発者ワークステーションや統合開発環境（IDE）を標的にして、秘密暗号鍵、API トークン、アクティブなセッション認証情報をローカル エンジニアリング環境から直接窃取します。

• 攻撃者は、侵害した静的認証情報のみを利用するのではなく、GitHub Actions のキャッシュ ポイズニング、OpenID Connect（OIDC）トークンの抽出、変更可能なアクションタグの改ざんといった高度なパイプライン操作手法へと手を広げ、暗号学的に検証された正当な来歴を保持したまま、侵害したパッケージを公開しています。

このブログ記事では、以前のガイダンス（こちらとこちら）を基に、ソフトウェア開発ライフサイクル（SDLC）全体にわたり、活発に悪用されている脅威ベクトル、サードパーティ リスク、アーキテクチャの脆弱性からソフトウェア サプライ チェーンを保護するように設計された、ソフトウェアおよびプラットフォーム アーキテクト向けの実用的な行動指針を説明します。

継続的インテグレーションと継続的デリバリー / デプロイ（CI / CD）の安全保護対策の確立、開発者のワークフローの強化、堅牢なエンドツーエンドの多層防御の構築を実現する方法の詳細をぜひお読みください。

多層的なアプローチ

このような多層攻撃はビルド パイプライン全体に及ぶ脆弱性を標的にするため、パイプラインの各ステージを独立したセキュリティ ドメインとして扱うだけではもはや不十分です。こうした持続的な脅威から防御するには、図 1 で示している、ソフトウェア開発ライフサイクルの 5 つの主要な柱にわたる徹底した多層防御アプローチが必要です。

エンドポイント

開発者のワークステーションは、リポジトリ、パイプライン、クラウド環境に直接、特権アクセスができるため、攻撃者にとって価値の高い標的となります。脅威アクターは IDE を標的にして、モニタリングされていないローカル アクセスを悪用し、個人用アクセス トークン（PAT）、SSH 認証鍵、独自コードを収集することがよくあります。組織は、すべてのローカル ホストマシンとクラウドベースの開発環境全体に一貫したセキュリティ ポスチャーを適用する、統合セキュリティ レイヤを確立する必要があります。

ローカル シークレット スキャン

組織は、リポジトリの commit 前にシークレットを検出してブロックするために、pre-commit フックと IDE 統合スキャンツールをデプロイする必要があります。ローカルの pre-commit テンプレートを標準化することで、変更が中央サーバーに push される前に git ツリーが完全に検証されるようになります。潜在的な漏洩の影響を最小限に抑えるために、組織は従来のクラシックな PAT から、上限の短い有効期間（TTL）と環境固有の最小限の権限で制約される、きめ細かな PAT に移行する必要があります。

エンドポイント セキュリティ管理

組織は、エンドポイント検知対応（EDR）ソリューションを構成して、開発者のソフトウェアのインテグレーションをモニタリングし、継続的なデバイス ポスチャー チェックを適用する必要があります。また、EDR エージェントでは、信頼できる IDE プロセスツリーをモニタリングして、異常なファイル アクセス、予期しないプロセス生成、不正なアウトバウンド ネットワーク接続がないかを確認する必要があります。

完全な整合性を確保するには、これらの EDR コンプライアンス シグナルを統合エンドポイント管理（UEM）システムに直接統合し、デバイスがコンプライアンスに違反した場合は、ソースコード管理（SCM）システムへのアクセス、パイプライン タスクの実行、コードの公開などを行うユーザー権限を自動的に制限または取り消す必要があります。必要なコマンドライン インターフェース（CLI）プロセスの除外は、企業のエンドポイント全体に広く適用するのではなく、指定および隔離された開発環境に厳密に制限する必要があります。

IDE の標準化

組織は、IDE、ブラウザ統合、サードパーティ拡張機能の特定のバージョンを審査して承認する必要があります。IDE やブラウザのマーケットプレイスは、検証済みのアプリケーションのみを許可して、未検証の拡張機能を明示的にブロックするよう制限する必要があります。すべての連携ツールは、許可リストに登録する前に、正式なサードパーティ リスク管理審査を受ける必要があります。組織は、新たに発見された脅威を阻止するため、厳格なバージョン固定と一元化された緊急ブロック機能を組み合わせた、アクティブなソフトウェア アセット インベントリを維持する必要があります。

AI を活用したセキュリティ

エンジニアリング チームは、承認済みの大規模言語モデル（LLM）と AI エージェントのみを、マージ前の脆弱性分析とアプリケーション セキュリティ テストに使用する必要があります。脅威アクターがオープンソースの Model Context Protocol（MCP）パッケージに悪意のあるコードを積極的に挿入し、AI コーディング エージェントを騙し始めているため、この境界は非常に重要です（詳細は付随するブログ記事をご覧ください）。

コンテキスト ポイズニングやデータ引き出しなどのリスクを軽減するため、セキュリティ チームはコンテキスト保護ツールをデプロイし、ランタイム実行前に入力を検証する必要があります。開発者は、機密性の高い認証情報がモデルのコンテキスト ウィンドウに入らないよう、プラットフォーム固有の除外設定を使用して、可能な限りローカル環境（.env）ファイルをワークスペースから除外する必要があります。組織は、すべての AI 生成コードをリポジトリに書き込む前に検証するための、人間参加型制御モデルを維持する必要があります。

隔離された開発環境のサンドボックス

ホストレベルの侵害を防ぐため、組織は可能な限り、コンテナ化された開発環境または専用の仮想マシン（VM）の使用を義務付ける必要があります。サンドボックス化することで、悪意のあるポストインストール スクリプトや依存関係ポイズニング攻撃がローカル ファイルシステムを探索することを防ぎます。

侵害された依存関係がホスト権限で実行されないようにするには、機密性の高いホストパスのワークスペース コンテナへのマウントを制限する必要があります。開発者のゲスト VM は、一元化および堅牢化されたゴールデン イメージからインスタンス化し、稼働中の本番環境からネットワークを隔離する必要があります。すべてのサンドボックス実行とネットワーク アクティビティは、一元化された社内のログ管理システムに統合する必要があります。

コード リポジトリ

ソースコード リポジトリは、組織の独自ソフトウェアと知的財産に関する、最も信頼できる情報源として機能します。このレイヤを強化するには、ユーザー ID の管理、厳格なブランチ ガバナンス、コード履歴の継続的な検証により、不正な変更がライフサイクルに侵入しないようにする必要があります。

ユニバーサル ID

リポジトリを保護するには、ユーザー ID を厳格に管理する必要があります。企業管理ユーザー（CMU）モデルを実装すると、組織は外部の共同編集者を含むすべてのアカウントの完全な所有権を保持できるうえ、FIDO2 準拠の物理的なセキュリティ キーやデジタル パスキーなど、フィッシング耐性のある多要素認証（MFA）を適用できます。

ただし、CMU アカウントは、外部のオープンソース リポジトリへのコントリビューションが禁止される場合があります。この制限があるため、一般公開プロジェクトやオープンソース プロジェクトの公開、および非公開での共同編集に携わるチームには、MFA を適用したシングル サインオン（SSO）連携を備えた標準的なユーザーモデルの利用が引き続き推奨されます。

選択したアカウント モデルに関係なく、ID 検証は継続的に行う必要があります。組織は、アクセスを許可する前に、デバイス ポスチャーを検証する条件付きアクセス ポリシーをデプロイするとともに、ユーザーの API アクティビティをモニタリングし、侵害されたセッションを迅速に検知する必要があります。

ブランチの保護

組織は、main ブランチへの直接 commit を禁止するポリシーを実装し、すべての変更において、マージの前にピアレビューを受け、自動化された CI チェックに合格することを必須とする、隔離された機能ブランチを通過するようにする必要があります。管理バイパス ポリシーは無効にする必要があります。ファイルシステム レベルでは、強制 push アクティビティを制限してモニタリングする必要があります。セキュリティ チームは、監査履歴を継続的に分析して時系列上の矛盾を見つけ出し、タイムラインの改ざんを特定するとともに、コードの引き出しに使用される不正なデッドドロップ リポジトリを検出しなければなりません。

認証情報のライフサイクル

長期にわたる持続的な侵入を防ぐため、組織は認証情報のローテーションを自動化し、ジャストインタイムの取得メカニズムを実装して、トークンの TTL を厳格に設定する必要があります。開発者のアクセスについては、組織は PAT の使用を廃止する必要があります。ホストに保存される静的なパスワードとして本質的に機能する PAT は、ローカルの情報窃取型マルウェアに対して脆弱です。代わりに、ハードウェア セキュリティ キー（FIDO2 / YubiKey や macOS Secure Enclave など）を基盤とする、暗号学的に検証された SSH ベースの認証に移行します。

自動化された CI / CD パイプラインやサードパーティ統合の場合、組織はサービス アカウントの PAT の代わりに GitHub アプリの使用を義務付け、1 時間後に自動的に失効する、有効期間が短く、アクセス範囲が厳格に制限されたアクセス トークンを活用する必要があります。シークレットは環境変数に保存しないでください。ローカル環境ファイル（.env）は .gitignore で除外し、ランタイム インジェクションにはネイティブ プラットフォームのシークレット機能を使用してください。

依存関係のセキュリティ

セマンティック バージョニング（SemVer）を利用するアプリケーション マニフェストでは、解決時に依存関係のドリフトを引き起こす動的なバージョン範囲（キャレット ^、チルダ ~、ワイルドカード * 演算子など）を禁止する必要があります。代わりに、厳格に適用され、暗号学的に検証されたロックファイルによって裏付けられた、厳密な SemVer 固定（例: 1.4.2）を設定で義務付ける必要があります。

未検証の実行ベクトル（「curl to bash」のようなブラインド スクリプトなど）はブロックし、明示的な SHA-256 ダイジェストを介して呼び出される、ベンダーが直接提供するコンテナを優先する必要があります。組織は、ソフトウェア構成分析（SCA）と到達可能性分析を組み合わせて実施し、アプリケーション パス内で実際に実行される脆弱性へのパッチ適用を優先する必要があります。ビルドでは、ソフトウェア部品構成表（SBOM）を生成し、ソフトウェア アーティファクトのためのサプライ チェーン レベル（SLSA）レベル 2 以上の来歴チェックを適用する必要があります。

アーティファクト管理

アーティファクト レイヤを防御するには、信頼できるビルド環境の境界を越えて入ってくるものを制御する必要があります。ポイントインタイムのスキャンではもはや不十分です。組織は、アップストリームのコンポーネントがダウンストリームに伝播する前に、継続的に検査および検証する必要があります。

依存関係のクールダウン

組織は、新たに公開されたパブリック パッケージ バージョンがインストール可能になるまで、リリース後少なくとも 7 日間のクールダウン期間を義務付ける必要があります。コミュニティによる検出により、悪意のあるオープンソース パッケージが公開後すぐに特定され、排除されることがよくあるからです。

7 日間の厳格なバッファを設けることで、オープンソース エコシステムは、ポイズニングされたリリースが内部ビルドに到達する前に、それを検出して排除する時間を確保できます。この遅延は、一元化されたレジストリまたはローカル構成で適用する必要があります。具体的な構成パラメータ（npm の minimumReleaseAge クールダウンやセキュアな Python pip インデックスの指定など）については、付随するブログ記事で詳述されている技術実装手順をご覧ください。

プロキシと隔離

外部パッケージとコンテナ イメージはすべて、各コンポーネントをキャッシュ保存、検査、ゲート処理する一元化された内部プロキシを、可能な限り経由する必要があります。組織は、Google Artifact Registry を使用して、非公開リポジトリのホスト、仮想アップストリーム リポジトリの構成、公開レジストリへのビルドランナーの直接アクセスの制限を行うことで、このセキュアな境界を管理できます。プロキシ経由で到達する新しいコンポーネントは、隔離状態を保持してスクリーニングし、セキュリティ判定に失敗した場合はビルドを自動的にブロックする必要があります。依存関係の混乱を狙った攻撃を防ぐため、内部リポジトリは公開レジストリとは区別して管理する必要があります。また、信頼できるレジストリへの昇格は、ポリシーに基づく慎重な承認プロセスに従う必要があります。

脆弱性スキャン

コンテナ イメージとサードパーティの依存関係については、レジストリ レイヤとランタイムで自動スキャンを実行する必要があります。保存されたアーティファクトは、新たな脆弱性が見つかるたびに継続的に再評価する必要があります。アラート件数を管理するには、到達可能性分析や、CISA の悪用が確認されている既知の脆弱性（KEV）カタログといった実際の悪用シグナルを使用して、検出結果の優先順位を決定します。また、Vulnerability Exploitability eXchange（VEX）ステートメントを使用して、該当しない検出結果を抑制し、ノイズを減らします。

イメージの来歴

アーティファクトが信頼できるソースから取得されたものであると検証することは、既知の脆弱性がないことを確認することと同じくらい重要です。来歴は、内部で生成されたすべてのコンテナ イメージとパッケージに暗号署名し、それぞれを特定の構築ワークフローと、それらを生成したソース commit にバインドすることで、この信頼を確立します。最新の署名ツールを使用すると、有効期間の長い署名鍵を管理する負担を負うことなく、各署名イベントをビルド ID に関連付け、公開の透明性ログに記録することで、これを実用的なものにすることができます。署名は検証されて初めて意味を持つため、アドミッション制御時に検証を強制する必要があります。この検証は、期待される厳密なビルド ID に限定し、変更可能なタグではなくアーティファクトの不変のダイジェストに対して行う必要があります。

この原則は、アーティファクトを公開する認証情報にも当てはまります。有効期間の長いレジストリ公開トークンは、繰り返しサプライ チェーン インシデントの根本原因となっています。盗んだトークンがあれば、攻撃者はポイズニングされたバージョンを信頼できる名前で公開できるからです。可能な場合は、これらの静的なトークンを、リリース時に特定の構築ワークフローに対して発行される、有効期間が短く、ID にバインドされた公開トークンに置き換えます。ファーストパーティ ビルドの場合、広く認められた来歴標準を採用することにより、ソフトウェアがどこでどのように構築されたかについて、一貫した基準を確立できます。

SHA の参照

コンテナ イメージのタグとアクション参照はデフォルトで変更可能であるため、アップストリームのアクターは、信頼できる名前の背後にあるコンテンツをいつでも密かに置き換えることができます。不変の暗号ダイジェストに固定することで、この抜け穴をふさぐことができます。ダイジェストはコンテンツ ハッシュであり、基盤となるアーティファクトに変更が加えられると、別の識別子が生成されるからです。これにより、パイプラインがすでに信頼している名前で悪意のあるコンテンツにすり替えられるのを防ぎ、代わりに参照を切断できます。

イメージはダイジェストで固定する必要があります。また、サードパーティのアクションは、再設定可能なバージョンではなく、完全な commit ハッシュに固定する必要があります。このルールは、メインのアプリケーション イメージだけでなく、ビルドが関与するすべてのイメージに適用する必要があります。変更可能なタグのままにしておくと、ベースイメージ、サイドカー、初期コンテナも同様にインジェクション ポイントとして利用される可能性があるからです。また、本番環境で再起動するたびに変更可能なタグを再解決するような構成も避ける必要があります。

CI / CD

CI / CD インフラストラクチャ内の自動化されたパイプラインを強化することは、ソフトウェア開発ライフサイクル全体を保護するための重要な要件です。これらの環境は、特権統合された広範なネットワークに依存してソース リポジトリ、サードパーティのレジストリ、クラウド インフラストラクチャにアクセスしているため、攻撃者にとって格好の標的となります。このような構築システムとデリバリー システムを保護するには、最小権限の原則を厳密に適用し、ネットワーク境界を厳格に運用して、信頼できるすべてのソフトウェア コンポーネントを継続的に検証する必要があります。

ランナーとビルドサーバー

これらのパイプラインはコード リポジトリ、依存関係レジストリ、クラウド環境へのアクセスを必要とするため、CI / CD インフラストラクチャの強化は極めて重要なタスクです。これらのインテグレーションを保護するための主な防御目標は、ランナーの永続性を排除することです。組織は、短命な単回使用のランナーを使用し、完了時に自動的に破棄される、隔離された新しい環境ですべてのジョブが実行されるようにする必要があります。このクリーンな状態から始めるアプローチにより、ジョブ間の汚染を防ぎ、攻撃者が永続的な足場を築くことを阻止します。セルフホスト環境の場合、この隔離をネットワーク層まで拡張し、ランナーのアウトバウンド トラフィックを、事前承認されたレジストリとリポジトリ API のみに制限して、データの引き出しを防ぐ必要があります。さらに、Poisoned Pipeline Execution（PPE）を軽減するため、実行エンジンは管理者が手動で承認するまで、pull リクエストに含まれる未検証のコードがシークレットにアクセスしたり、デプロイ グレードのランナーをトリガーしたりするのをブロックする必要があります。

また、パイプラインでは、共有ビルド キャッシュが改ざんされないよう保護する必要があります。ビルド キャッシュは、ビルドを高速化するためにブランチ間で頻繁に共有されるため、悪意のある pull リクエストによって、破損した依存関係が共有キャッシュに直接挿入される可能性があります。これを放置すると、その後の本番環境ビルドでこのポイズニングされたキャッシュが取得され、信頼できる環境で悪意のあるコードが実行されてしまいます。パイプラインの設定では、ブランチの権限によってキャッシュ アクセスを厳密に隔離し、認証されていないフォークからのキャッシュ書き込みを拒否する必要があります。

最小権限の CI / CD

• フェデレーテッド エフェメラル ID: ワークフロー内での永続的な自動化シークレットの使用を禁止し、OIDC を利用してパイプライン ID を有効期間の短いトークンと交換するようにします。

• ゼロトラスト実行スコープ: デフォルトで読み取り専用または権限なしのランナー ID を発行し、実行可能な最小限の権限を明示的にリクエストするようコンポーネントに義務付けます。

• 共有状態のパラメータ化: ダウンストリーム テンプレートやネストされたワークフロー間で認証情報を自動継承することを禁止し、機密性の高い変数を隔離します。

• ランタイム ガバナンス: 未承認のサードパーティ プラグインやマーケットプレイスのアクションを制限します。また、セキュリティ チームは、パッケージ インストールのライフサイクル スクリプトをサンドボックス化または無効化して（ignore-scripts=true などの構成を使用。詳細は付随するブログ記事をご覧ください）、侵害された依存関係が構築環境で任意のコマンドを実行することを防ぐ必要もあります。

• 環境の分離: ネットワークと IAM の境界をセグメント化し、初期段階の検証タスクや lint チェックタスクを、リリース権限を持つシステムから完全に切り離して動作させるようにします。

• 変更不可のブランチ履歴: 履歴の書き換え機能とカノニカル ブランチでの強制 push を無効にして、追加専用の監査証跡を維持します。

• IaC の検証: デプロイ前に Infrastructure as Code（IaC）をスキャンし、過剰な権限を持つ鍵、引用符で囲まれていないユーザー パラメータの挿入、暗号化されていない Webhook、ランナーの RBAC 構成ミスをブロックします。

スキャンゲートと証明書

CI / CD のスキャンゲートは、デプロイ プロセス内で自動化された品質検証として機能します。設定されたセキュリティ基準に照らしてコードを評価し、定義された基準を満たさない場合はデプロイを自動的に停止します。スキャンゲートをプロセスのできるだけ早い段階に配置することで、潜在的な脆弱性が本番環境に到達する前に開発者に警告できます。

シークレット スキャン（開発者の commit / PR ゲート）: ハードコードされた API キー、パスワード、SSH 認証鍵が含まれている場合は開発者の push をブロックするよう、pre-commit フックと SCM レベルのスキャナを構成します。これにより、シークレットがリポジトリの永続的な履歴に保存されるのを防ぐことができます。

SAST - 静的アプリケーション セキュリティ テスト（pull リクエスト / ピアレビュー ゲート）: SAST を継続的インテグレーション（CI）テストに統合し、ドラフト コードを main ブランチにマージする前に分析します。これにより、開発中に構造上の欠陥、ロジックの脆弱性、危険な関数（エスケープされていないユーザー入力など）が自動的に検出されます。

SCA - ソフトウェア構成分析（構築フェーズ中）: ビルド環境が依存関係を解決する際に SCA スキャンをトリガーします。パッケージ ロックファイル（package-lock.json や requirements.txt など）をスキャンして Google OSV などのデータベースと照合することで、アクティブな既知の CVE が存在するライブラリをインポートしようとするビルドを自動的に失敗させることができます。

コンテナ / イメージ スキャン（レジストリ / push ゲート）: 自動スキャナをコンテナ レジストリ パイプラインに直接組み込みます。新しく構築されたコンテナ イメージを本番環境用に許可リストに登録する前に、レジストリ スキャナでそのベース OS パッケージを検査し、重大な OS レベルの脆弱性やデフォルトでの root アクセスが含まれているイメージを拒否するようにします。

DAST - 動的アプリケーション セキュリティ テスト（ステージング / デプロイ前）: デプロイの手順として、実行中のアプリケーションの、隔離された一時的なステージング インスタンスを作成します。自動化された DAST テストを実行し、エンドポイントに対する実際の攻撃（SQL インジェクションやクロスサイト スクリプティングなど）をシミュレートして、アクティブなランタイム防御構成が機能しているかどうかを検証します。

CSPM - クラウド セキュリティ ポスチャー管理（デプロイ前の IaC スキャンおよびデプロイ後）: 変更を適用する前に、Policy as Code ツールを使用して Infrastructure as Code（IaC）テンプレート（Terraform や Kubernetes マニフェストなど）をスキャンします。これにより、過剰な権限を持つ IAM ロールや、SSH（ポート 22）がインターネットに公開されているセキュリティ グループなど、構成ミスのあるクラウド環境のプロビジョニングが自動的にブロックされます。

SBOM の生成と証明書

SBOM は、ビルドに含まれるすべてのコンポーネントの完全かつ検証可能なインベントリです。構築の一環として SBOM を生成して署名すると、このインベントリは、事後に再構築されたものではなく、改ざん検出が可能な証明書として生成されます。

実際には、これは構築ステップとして、CycloneDX や SPDX のような広く認識された形式で SBOM を生成することを意味します。生成された SBOM は、アーティファクトのダイジェストに関連付けられた証明書として署名され、変更を防止します。署名付きの SBOM は、フリート内のすべてのイメージを再スキャンすることなく、影響を受けるアーティファクトにマッピングし直す必要があります。モニタリングを有効に保つには、VEX ステートメントを使用して、コードに適用されない検出結果にフラグを立て、インベントリが実用的なトリアージ ツールとして機能し続けるようにする必要があります。

デプロイ

ランタイム フェーズを保護することで、攻撃者がパイプラインの初期の防御策をうまくすり抜けたとしても、ワークロードは保護されたままになります。この運用レイヤは、コードがビルド パイプラインからアクティブな本番環境に移行する際の最終的な品質ゲートとして機能します。

ワークロードの保護とランタイムの強化

ワークロードの保護は、実行中のアプリケーションとコンテナ インスタンスに直接適用し、実行フットプリントを制限して、アクティブなエクスプロイトをブロックする必要があります。

• デプロイのガードレール: 本番環境の入り口に自動セキュリティ チェックを設置し、有効な暗号署名のないコンテナ、不要な root 権限を要求するコンテナ、信頼できない公開レジストリから取得されたコンテナをブロックします。

• ワークロード ポスチャー: 強化されたベースイメージからワークロードを構築し、読み取り専用のルート ファイル システムと削除された SSH 機能を備えた不変のインフラストラクチャで実行して、脆弱性の悪用後のファイル作成や横方向のディレクトリ トラバーサルを防止します。

• アクティブなアプリケーション保護: ランタイム アプリケーション自己保護（RASP）をデプロイし、SQL インジェクションのような実行レベルでのエクスプロイトを阻止します。Google Model Armor といったランタイム ガードレールを使用して、プロンプト インジェクションやジェイルブレイクから AI ワークロードを保護します。

• ジャストインタイム アクセス: 常時有効な管理者権限を排除し、有効期限が設定され、アクセスがタスクの範囲に限定された認証情報を採用します。この認証情報は自動的に期限切れとなり、必要な場合にのみ実行時に特権認証情報が挿入されます。

稼働中のインフラストラクチャの保護

周辺ネットワークとクラウド コントロール プレーンを保護することで、デプロイ済みのアプリケーションを外部の脅威から守り、ラテラル ムーブメントをブロックして、クラウド構成の完全性を維持できます。

• ウェブ アプリケーション ファイアウォール（WAF）: エッジ ファイアウォールをデプロイし、受信するアプリケーション レイヤのトラフィックを検査することで、悪意のあるペイロードをフィルタし、クロスサイト スクリプティングや OWASP Top 10 の脆弱性といった一般的なウェブ エクスプロイトを、バックエンド サービスに到達する前にブロックします。

• API ゲートウェイとロードバランサ: エッジ認証を一元化し、レート制限を適用して、リクエストの署名を検証することで、アプリケーション バックエンドが直接公開されることを防ぎます。

• マイクロセグメンテーション: ID 認識型のきめ細かなネットワーク ポリシーを適用してワークロードを隔離し、事前承認されたサービス間通信パスのみにトラフィックを制限することにより、デフォルトでネットワークのラテラル ムーブメントをブロックします。

• 構成の整合性: Policy as Code ツールをデプロイし、バージョン管理された IaC の信頼できる情報源と照らし合わせて稼働環境を継続的に検証し、コード外での変更を自動的に元に戻すことで、不正な変更を防止します。

• アクティブなポスチャー スキャン: クラウド セキュリティ ポスチャー管理（CSPM）とクラウドネイティブ アプリケーション保護プラットフォーム（CNAPP）を実行し、クラウドの構成ミス、制限が過度に緩い IAM、公開されたストレージを継続的にスキャンします。

• 継続的なモニタリング: ログ、システム指標、監査イベントを収集することですべてのシステムを完全に可視化し、ライブ セキュリティ イベントを迅速に検出、追跡して対応します。

まとめ

最近のソフトウェア サプライ チェーンへの攻撃キャンペーンは、開発インフラストラクチャ、ビルド パイプライン、開発者のユーティリティが重要な脅威ベクトルであり、主要な侵害ポイントであることを示しています。従来のアクセス制御やポイントインタイムのセキュリティ スキャンでは、高度な侵入からこれらの環境を保護するには不十分です。開発ライフサイクルを強化するには、すべての段階で継続的な自動検証を実装し、開発者のエンドポイント、コード リポジトリ、パッケージ レジストリ、ビルドランナー、デプロイ ガードレールにわたるセキュリティ ポスチャーを、包括的な防御フレームワークに統合する必要があります。

最終的に、パイプライン セキュリティの目的は、侵入を隔離して封じ込めることができる、復元力のあるアーキテクチャを構築することです。コードの最初の commit から本番環境への最終的なデプロイに至るまで暗号学的検証とポリシー適用を自動化することで、組織は全体的な攻撃対象領域を大幅に縮小し、ダウンストリームの消費者を保護するとともに、個々の侵害が拡大する前に迅速に隔離して解決できます。

謝辞

このガイダンスの作成にあたり、多大なるご協力をいただいた Arafat Ismail 氏、Bhavesh Dhake 氏、Brentyn Muir 氏、Brian Meyer 氏、Emilio Oropeza 氏、Eyad Mahmoud 氏、Franklin Ramos 氏、Gursev Singh 氏、Omar ElAhdan 氏、Sara Takhim 氏、Stuart Carrera 氏、Stuart Munro 氏、Will Silverstone 氏、ならびに Mandiant セキュリティ トランスフォーメーション サービス チームの皆様に、深く感謝いたします。

 - Mandiant