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

はじめに

ソフトウェアサプライチェーンセキュリティを取り巻く状況は、大きな転換点を迎えています。最近確認された一連の攻撃キャンペーンは、高度な脅威アクターが信頼されたセキュリティツールやプログラミングツールを侵害することで、エンジニアリングのライフサイクル全体を組織的に狙っていることを示しています。

これらの侵入事例からは、3つの主要な手口が浮かび上がってきます。

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

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

• 攻撃者は、単に窃取した静的な認証情報に依存するだけでなく、GitHub Actionsのキャッシュポイズニング、OpenID Connect(OIDC)トークンの抽出、変更可能なアクションタグの乗っ取りといった高度なパイプライン操作手法へとエスカレートし、正規の暗号的な出自証明を保持したまま侵害されたパッケージを公開しています。

本ブログは、以前公開したガイダンス(こちら、およびこちら)を踏まえ、ソフトウェアやプラットフォームのアーキテクトに向けて、ソフトウェア開発ライフサイクル(SDLC)全体にわたり、実際に悪用されている脅威ベクトル、サードパーティリスク、アーキテクチャ上の脆弱性からソフトウェアサプライチェーンを守るための実践的な指針を提供するものです。  

継続的インテグレーション/継続的デリバリー・デプロイメント(CI/CD)の安全対策の確立方法、開発者ワークフローの強化方法、そしてエンドツーエンドで堅牢な多層防御の構築方法について、以下で詳しく解説します。 

多層的なアプローチ

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

エンドポイント 

開発者のワークステーションは、リポジトリ、パイプライン、クラウド環境への直接的かつ特権的なアクセス権を持つため、価値の高い標的となります。脅威アクターは頻繁にIDEを狙い、監視されていないローカルアクセスを悪用してパーソナルアクセストークン(PAT)、SSH鍵、独自コードを収集します。組織は、すべてのローカルホストマシンとクラウドベースの開発環境全体で一貫したセキュリティ体制を強制する、統一されたセキュリティ層を確立する必要があります。

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

組織は、リポジトリへのコミット前にシークレットを検出しブロックするために、pre-commitフックとIDE統合型のスキャンツールを導入する必要があります。ローカルのpre-commitテンプレートを標準化することで、変更が中央サーバーへプッシュされる前に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ブランチへの直接プッシュを一切禁止する方針を導入し、すべての変更が分離されたフィーチャーブランチを経由し、マージ前にピアレビューと自動化されたCIチェックを通過することを求めるべきです。管理者による回避ポリシーは無効化すべきです。ファイルシステムレベルでは、force-push操作を制限し監視すべきです。セキュリティチームは、タイムラインの改ざんを見抜き、コード窃取に使われる不正なデッドドロップ(受け渡し用)リポジトリを検知するため、監査履歴の時系列の矛盾を継続的に分析する必要があります。

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

長期的な永続化を防ぐため、組織は認証情報のローテーションを自動化し、ジャストインタイムでの取得メカニズムを実装し、厳格なトークンTTLを設定すべきです。開発者アクセスについては、実質的にホストに保存された静的パスワードとして機能し、ローカルのinfostealer型マルウェアに対して脆弱なPATを廃止し、ハードウェアセキュリティキー(FIDO2/YubiKeyやmacOSのSecure Enclaveなど)に裏付けられた暗号的に検証されたSSHベースの認証へ移行すべきです。

自動化されたCI/CDパイプラインやサードパーティ統合については、組織はサービスアカウントのPATに代わってGitHub Appsの使用を義務付け、1時間後に自動的に失効する、短命かつスコープの厳格に絞られたアクセストークンを活用すべきです。シークレットは環境変数に保存すべきではありません。ローカル環境ファイル(.env)は.gitignoreで除外し、実行時の注入にはプラットフォームネイティブのシークレット機能を利用すべきです。

依存関係のセキュリティ

セマンティックバージョニング(SemVer)を利用しているアプリケーションマニフェストについては、依存関係解決時にドリフトを引き起こす動的なバージョン範囲指定(キャレット^、チルダ~、ワイルドカード*演算子など)を禁止すべきです。代わりに、厳格に検証されたロックファイルによって支えられた、正確なSemVer固定(例:1.4.2)を設定で義務付けるべきです。

盲目的な「curlしてbashに渡す」スクリプトのような未検証の実行経路はブロックし、明示的なSHA-256ダイジェストで呼び出す正規ベンダーのコンテナを利用すべきです。組織は、アプリケーションのパス内で実際に実行される脆弱性の修正を優先するため、到達可能性分析と組み合わせたソフトウェア構成分析(SCA)を実施すべきです。ビルドではソフトウェア部品表(SBOM)を生成し、Supply-chain Levels for Software Artifacts(SLSA)レベル2以上の出自証明チェックを強制すべきです。

アーティファクト管理 

アーティファクト層を防御するには、信頼されたビルド環境の境界を越えて入ってくるものを管理する必要があります。もはや時点的なスキャンだけでは不十分であり、組織はアップストリームのコンポーネントが下流に伝播する前に、継続的に検査・検証すべきです。

依存関係のクールダウン期間

組織は、新たに公開された公開パッケージのバージョンがインストール可能になるまでに、最低7日間のリリース経過期間によるクールダウンを義務付けるべきです。コミュニティによる検知は、公開直後に悪意のあるオープンソースパッケージを発見し削除することが多くあります。

厳格な7日間のバッファを設けることで、汚染されたリリースが社内ビルドに到達する前に、オープンソースエコシステムがそれを検知して排除する時間を確保できます。この遅延は、集中管理されたレジストリまたはローカル設定で強制すべきです。具体的な設定パラメータ(npmのminimumReleaseAgeクールダウン設定や、安全なPython pipインデックス設定など)については、併せて公開しているブログで詳しく説明している技術的な実装手順をご参照ください。

プロキシと検疫

外部パッケージやコンテナイメージはすべて、可能な限り、各コンポーネントをキャッシュ・検査・審査する集中管理された社内プロキシを経由させるべきです。組織は、この安全な境界を管理するためにGoogle Artifact Registryを利用し、プライベートリポジトリをホストし、バーチャルなアップストリームリポジトリを設定し、ビルドランナーから公開レジストリへの直接アクセスを制限できます。プロキシを通過してきた新しいコンポーネントは検疫状態で保持・審査し、セキュリティ判定に失敗した場合はビルドを自動的にブロックすべきです。依存関係の混同攻撃を防ぐため、社内リポジトリは公開レジストリと明確に分離し、信頼されたレジストリへの昇格は、意図的でポリシーに基づいた承認フローに従うべきです。

脆弱性スキャン

コンテナイメージとサードパーティの依存関係は、レジストリ層と実行時の両方で自動スキャンを受けるべきです。保存されているアーティファクトは、新たな脆弱性が発見されるたびに継続的に再評価すべきです。アラート量を管理するため、結果は到達可能性分析や、CISAの既知の悪用済み脆弱性(KEV)カタログのような実際の悪用を示す信号を用いて優先順位付けすべきです。該当しない検出結果を抑制しノイズを減らすには、Vulnerability Exploitability eXchange(VEX)ステートメントを活用すべきです。

イメージの出自証明

アーティファクトが既知の脆弱性を含んでいないことを確認するのと同じくらい、それが信頼できる出所から来たことを検証することも重要です。出自証明は、社内で生成されたすべてのコンテナイメージとパッケージに暗号署名を施し、それを作成した具体的なビルドワークフローとソースコミットに結び付けることで、この信頼を確立します。最新の署名ツールは、長期間有効な署名鍵を管理する負担を負わずにこれを実現できるようになっており、代わりに各署名イベントをビルドIDに結び付け、公開の透明性ログに記録します。署名は検証されて初めて意味を持つため、検証は取り込み時に強制し、想定される正確なビルドIDに限定し、変更可能なタグではなくアーティファクトの不変のダイジェストに対して行うべきです。

同じ原則は、アーティファクトを公開する際の認証情報にも適用されます。長期間有効なレジストリ公開用トークンは、サプライチェーンインシデントの根本原因として繰り返し確認されており、トークンが盗まれると、攻撃者が信頼された名前のもとで汚染されたバージョンを公開できてしまいます。可能な限り、これらの静的トークンは、リリースの瞬間に特定のビルドワークフローに対して発行される、短命でIDに紐づいた公開用トークンに置き換えるべきです。自社製のビルドについては、認知された出自証明の標準を採用することで、ソフトウェアがどのように、どこでビルドされたかについて一貫した基準を得られます。

SHA参照

コンテナイメージのタグやアクション参照は、デフォルトでは変更可能であるため、アップストリームの何者かが信頼された名前の背後にあるコンテンツをいつでも密かに置き換えられてしまいます。不変の暗号ダイジェストに固定することで、この隙をなくせます。ダイジェストはコンテンツのハッシュ値であるため、基盤となるアーティファクトに変更が加われば別の識別子が生成され、パイプラインが既に信頼している名前のもとで悪意あるコンテンツに差し替えられるのではなく、参照そのものが破損する形になります。

イメージはダイジェストで固定し、サードパーティのアクションは再設定可能なバージョンではなく、完全なコミットハッシュに固定すべきです。この規律は、主要なアプリケーションイメージだけでなく、ビルドが触れるすべてのイメージに適用すべきです。ベースイメージ、サイドカー、initコンテナも、変更可能なタグのままにしておけば同様に有効な侵入口となるためです。チームは、本番環境で再起動ごとに変更可能なタグを再解決してしまう設定も避けるべきです。

CI/CD

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

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

これらのパイプラインはコードリポジトリ、依存関係のレジストリ、クラウド環境へのアクセスを必要とするため、CI/CDインフラの強化は極めて重要な作業です。これらの統合機能を保護するための主要な防御目標は、ランナーの永続性を排除することです。組織は、使い捨ての一時的なランナーを使用し、すべてのジョブが新しい隔離された環境で実行され、完了時に自動的に破棄されるようにすべきです。このクリーンスレート方式により、ジョブ間の汚染が防止され、攻撃者が永続的な足掛かりを得ることを阻止できます。自己ホスト型の環境では、この分離をネットワーク層にも拡張し、データ窃取を防ぐためにランナーからの外向き通信を事前承認済みのレジストリとリポジトリAPIのみに限定すべきです。さらに、Poisoned Pipeline Execution(PPE)を軽減するため、実行エンジンは、管理者が手動承認を与えるまで、プルリクエストからの未審査コードがシークレットへアクセスしたりデプロイ用ランナーを起動したりできないようブロックすべきです。

加えて、パイプラインは共有ビルドキャッシュを改ざんから保護すべきです。ビルドキャッシュはビルドを高速化するためブランチ間で共有されることが多いため、悪意のあるプルリクエストが破損した依存関係を共有キャッシュへ直接注入できてしまう可能性があります。制限しないままにしておくと、後続の本番ビルドがこの汚染されたキャッシュを取得し、信頼された環境内で悪意あるコードを実行してしまいます。パイプラインの構成は、ブランチの権限によってキャッシュへのアクセスを厳格に分離し、認証されていないフォークからのキャッシュ書き込みを拒否すべきです。

最小権限のCI/CD

• フェデレーテッドな一時的ID:ワークフロー内での永続的な自動化用シークレットを禁止し、OIDCを活用してパイプラインのIDを短命なトークンに交換します。

• ゼロトラストな実行スコープ:デフォルトでは読み取り専用または権限なしのランナーIDを発行し、コンポーネントに必要最小限の権限を明示的に要求させます。

• 共有状態のパラメータ化:機密性の高い変数を分離するため、下流のテンプレートやネストされたワークフローへの認証情報の自動継承を禁止します。

• 実行時のガバナンス: 承認されていないサードパーティのプラグインやマーケットプレイスのアクションを制限します。セキュリティチームは、侵害された依存関係がビルド環境内で任意のコマンドを実行するのを防ぐため、パッケージインストールのライフサイクルスクリプト(併せて公開しているブログで詳述しているignore-scripts=trueなどの設定を利用)をサンドボックス化または無効化すべきです。

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

• 不変のブランチ履歴:追記専用の監査証跡を維持するため、正規のブランチにおける履歴の書き換え機能とforce-pushを無効化します。

• IaCの検証:過剰な権限を持つキー、クォート処理されていないユーザーパラメータの注入、暗号化されていないWebhook、ランナーのRBAC設定ミスをブロックするため、デプロイ前にInfrastructure as Code(IaC)をスキャンします。

スキャンゲートとアテステーション

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

シークレットスキャン (開発者のコミット/PRゲートにおいて): ハードコードされたAPIキー、パスワード、SSH鍵が含まれている場合、開発者のプッシュをブロックするようpre-commitフックとSCMレベルのスキャナーを設定します。これにより、シークレットがリポジトリの永続的な履歴に入り込むことを未然に防げます。

SAST(静的アプリケーションセキュリティテスト) (プルリクエスト/ピアレビューゲートにおいて): 継続的インテグレーション(CI)テストにSASTを組み込み、mainブランチへマージされる前の草稿コードを分析します。これにより、構造的な欠陥、ロジック上の脆弱性、危険な関数(エスケープされていないユーザー入力など)を、開発が進行している段階で自動的に検出できます。

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

コンテナ/イメージスキャン (レジストリ/プッシュゲートにおいて):自動スキャナーをコンテナレジストリのパイプラインに直接組み込みます。新しくビルドされたコンテナイメージを本番環境向けの許可リストに登録する前に、レジストリスキャナーがそのベースOSパッケージを検査し、重大なOSレベルの脆弱性やデフォルトのroot権限アクセスを含むイメージを拒否すべきです。

DAST(動的アプリケーションセキュリティテスト) (ステージング環境/デプロイ前において):デプロイの1ステップとして、稼働中のアプリケーションの一時的で隔離されたステージングインスタンスを作成します。SQLインジェクションやクロスサイトスクリプティングなど、実際の攻撃を模した自動DASTテストをエンドポイントに対して実行し、実行時の防御設定が正しく機能していることを検証します。

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

SBOMの生成とアテステーション

SBOMとは、あるビルドに含まれるすべてのコンポーネントを検証可能な形で完全に記録した目録です。ビルドの一部としてSBOMを生成・署名することで、事後的な再構築ではなく、改ざん検知可能なアテステーションとしてこの目録を作成できます。

実務上は、CycloneDXやSPDXといった認知された形式で、ビルドの一手順としてSBOMを生成することを意味します。生成されたSBOMは、アーティファクトのダイジェストに結び付けたアテステーションとして署名し、改変を防ぐべきです。署名済みのSBOMは、その後、艦隊内のすべてのイメージを再スキャンすることなく、影響を受けるアーティファクトへマッピングし直すべきです。監視を有用な状態に保つため、コードに該当しない検出結果にフラグを立てるVEXステートメントを利用し、目録が実用的なトリアージツールとして機能する状態を維持すべきです。

デプロイメント

実行時フェーズを保護することで、攻撃者がパイプラインの初期段階の防御を突破したとしても、ワークロードが保護された状態を維持できます。この運用層は、コードがビルドパイプラインから実際の本番環境へ移行する際の最終的な品質ゲートとして機能します。

ワークロード保護と実行時の強化

ワークロード保護は、実行中のアプリケーションやコンテナインスタンスに対して直接強制し、その実行範囲を制限し、進行中の悪用を阻止すべきです。

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

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

• アクティブなアプリケーション保護: SQLインジェクションのような実行レベルの悪用試行をブロックするため、ランタイムアプリケーションセルフプロテクション(RASP)を導入します。Google Model Armorのような実行時ガードレールを用いて、AIワークロードをプロンプトインジェクションやジェイルブレイクから保護します。

• ジャストインタイムアクセス: 常設の管理者権限を排除し、必要な場合のみ実行時に特権的な認証情報を注入する、時間制限付きでタスクにスコープを絞ったアクセス認証情報へ切り替え、期限が来ると自動的に失効させます。

稼働中インフラの保護

周辺のネットワークとクラウドコントロールプレーンを保護することで、デプロイ済みのアプリケーションを外部の脅威から守り、横方向の移動をブロックし、クラウド設定の絶対的な整合性を維持できます。

• Webアプリケーションファイアウォール(WAF): エッジファイアウォールを導入して受信するアプリケーション層のトラフィックを検査し、悪意のあるペイロードをフィルタリングして、クロスサイトスクリプティングやOWASP Top 10の脆弱性など、一般的なWeb攻撃をバックエンドサービスに到達する前にブロックします。

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

• マイクロセグメンテーション: きめ細かくIDを意識したネットワークポリシーを強制してワークロードを分離し、トラフィックを事前承認済みのサービス間通信経路のみに限定することで、デフォルトで横方向のネットワーク移動をブロックします。

• 設定の整合性: Policy as Codeツールを導入して、稼働中の環境をバージョン管理されたIaCの信頼できる情報源と継続的に照合し、範囲外の変更が加えられた場合は不正な変更を防ぐため自動的に元に戻します。

• アクティブな状態スキャン: クラウドの設定ミス、過剰に許可されたIAM、公開状態のストレージを継続的にスキャンするため、クラウドセキュリティポスチャー管理(CSPM)およびクラウドネイティブアプリケーション保護プラットフォーム(CNAPP)を実行します。

• 継続的な監視: ログ、システムメトリクス、監査イベントを収集し、すべてのシステムにわたる完全な可視性を維持することで、実際のセキュリティイベントを迅速に検知・追跡し、対応できるようにします。

まとめ 

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

最終的に、パイプラインセキュリティの目的は、侵入を分離・封じ込められる強靭なアーキテクチャを構築することにあります。最初のコードコミットから最終的な本番デプロイに至るまで、暗号的な検証とポリシー適用を自動化することで、組織は全体的な攻撃対象領域を大幅に縮小し、下流の利用者を守り、個々の侵害が拡大する前に迅速に隔離・解決される状態を実現できます。

謝辞

本ガイダンスは、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 Security Transformation Servicesチームの協力なしには成立しませんでした。