要約

  • CircleCI の公開インシデントレポートによると、不正な第三者が CircleCI のエンジニアのノート PC にマルウェアを使用し、有効な2FA 対応 SSO セッションを盗み、一部の本番システムに侵入し、環境変数、トークン、キーを含む顧客情報を流出させた。
  • 顧客シークレットの管理、従業員端末の侵害耐性、トークンの失効、環境変数の露出、顧客通知、ローテーションのガイダンス、そして CI 信頼境界がより回復力を持つようになったという証明を、誰が実際にコントロールしていたのか？
  • 説明責任の問題は、CI プラットフォームが、基礎となるアプリケーションコード、クラウドアカウント、ビジネスシステムが顧客に属している場合でも、デプロイメント認証情報に対する運用権限を持つことにある。
  • 開発者、プラットフォームチーム、企業、ダウンストリームユーザー、セキュリティチーム、監査人、クラウドリソース所有者は、顧客シークレットのローテーションが完全であり、再発露が抑制されたという証拠を必要としていた。
  • この記事では、CircleCI のインシデントレポート、セキュリティアラート、サポートガイダンス、製品ドキュメントを主要な公開記録として扱う。GitHub、AWS、Google Cloud、CISA、NIST、その他の技術文書は、制御設計の評価に使用され、それらの組織が CircleCI に対してインシデント固有の所見を述べたと主張するものではない。

このケースがリスクと説明責任ファイルに属する理由

CircleCI の2023年1月のインシデントがリスクと説明責任ファイルに属するのは、継続的インテグレーションがもはや周辺的な開発者の利便性ではないからだ。CI システムは多くの場合、ソースコード、パッケージレジストリ、クラウドアカウント、デプロイメントシステム、署名ツール、テスト環境、ステージングインフラ、プロダクションリリースパスの間に位置する。ビルドを実行するプラットフォームは、それらのビルドがプライベート依存関係を取得し、コンテナイメージをプッシュし、インフラをデプロイし、パッケージを公開し、クラウドロールを引き受け、内部サービスに接続できるようにする認証情報も保持する可能性がある。CI プロバイダーがすべての顧客にシークレットのローテーションを指示すると、インシデントはすでにベンダーセキュリティから顧客の運用リスクへと移行している。

公的な記録は、CircleCI のセキュリティアラート（https://circleci.com/blog/january-4-2023-security-alert/）とその後のインシデントレポート（https://circleci.com/blog/jan-4-2023-incident-report/）から始まる。CircleCI は2023年1月4日に顧客に警告し、CircleCI に保存されたシークレットをすべてローテーションするよう推奨したと述べている。インシデントレポートによると、攻撃者は CircleCI エンジニアのノート PC に展開されたマルウェアを悪用し、有効な2FA 対応 SSO セッションを盗み、従業員になりすまし、一部の本番システムへのアクセス権限を昇格させ、2022年12月22日に顧客情報を流出させた。CircleCI が説明したデータには、顧客の環境変数、トークン、サードパーティシステムのキーが含まれていた。

この表現は、説明責任の問題を具体的にしている。懸念事項は、単にベンダーの従業員エンドポイントが侵害されたということではなかった。懸念は、侵害された従業員経路が、CircleCI の外部で有用な顧客シークレットに到達する可能性があることだった。それらのシークレットは、クラウドプロバイダー、バージョン管理システム、パッケージレジストリ、デプロイメントターゲット、セルフホストランナー、API、データストア、または内部ビジネスシステムに属している可能性がある。CircleCI は一部のプラットフォーム発行トークンを失効させ、パートナーとの統合をローテーションできたが、すべての顧客のクラウド認証情報、アプリケーションシークレット、SSH キー、デプロイメントキー、レジストリトークン、サービス固有の API キーを一方的にローテーションすることはできなかった。そのため、顧客は大規模で分散した是正作業を余儀なくされた。

このケースは、開発者ツールの経済性も示している。CI 製品は、調整コストを削減し、ビルドワークフローを標準化し、チームの出荷を高速化するために採用される。同じ経済論理がシークレットの管理を集中させる。すべてのチームが独立したデプロイメントシステムを構築する代わりに、チームは共有 CI コントロールプレーン内に認証情報を配置し、プロバイダーが適切なタイミングでそれらの認証情報を注入することを信頼する。これは効率的だが、プロバイダーの内部アクセスモデルが失敗すると、効率性は共有爆発半径となる。多くの顧客は、CI ワークフローに埋め込まれた認証情報を見つけ、ローテーションし、検証するためにエンジニアリング作業を中断しなければならない。

弱い説明責任分析は、一人の従業員の感染したノート PC を非難して終わりにするだろう。CircleCI 自身のレポートはその狭い枠組みを否定し、セキュリティインシデントはシステム障害であり、組織の責任は攻撃ベクトル全体にわたって保護策を構築することだと述べている。その原則は中心的なものだ。攻撃者は侵入の責任を負う。CircleCI は従業員エンドポイントの保護、プロダクションアクセスの設計、セッション信頼、顧客シークレットの保存、トークン失効、インシデント開示、是正ツールを管理していた。顧客は、CircleCI に保存された認証情報を持つダウンストリームシステムを管理していた。GitHub、Bitbucket、GitLab、AWS、Google Cloud、その他のプロバイダーは、個別のトークンおよび監査システムを管理していた。インシデントは、それらすべての調整を必要とした。

インシデントにより、顧客シークレットは共有修復義務となった

CircleCI のインシデントレポートは、露出の顧客側について異常に率直だ。関連期間中にプラットフォームにシークレットを保存していた場合、それらのシークレットはアクセスされたと想定し、推奨される緩和手順を踏むべきだと述べている。また、顧客は2022年12月16日から CircleCI の1月4日の開示後にシークレットローテーションを完了した日までの間、自社のシステムで不審な活動がないか調査すべきだと述べている。これは強力な公開境界である。CircleCI は単に露出の可能性があると言っただけでなく、是正目的のために保存されたシークレットを露出したものとして扱うよう顧客に指示したのだ。

この違いは重要だ。CI シークレットは、CI プロバイダーにログインするためだけに使用されるパスワードとは異なる。別のシステムの有効な認証情報になる可能性がある。プロジェクト環境変数には、データベース URL、クラウドアクセスキー、プライベートパッケージトークン、ウェブフック署名シークレット、Terraform 変数、デプロイメント認証情報、API キーを含めることができる。コンテキスト変数は複数のプロジェクト間で共有できる。ランナートークンは、セルフホストの実行能力をプラットフォームに接続できる。OAuth トークンは CircleCI をバージョン管理プロバイダーに接続できる。SSH キーはリポジトリやサーバーへのアクセスを許可する。これらのシークレットが露出すると、ダウンストリームリスクはそれらを受け入れたすべてのシステムに分散される。

CircleCI 自身のドキュメントは、その理由を説明するのに役立つ。環境変数ガイド（https://circleci.com/docs/guides/security/env-vars/）は、環境変数をジョブを構成し、シークレット、秘密鍵、コンテキストを保持する方法として説明している。コンテキストドキュメント（https://circleci.com/docs/guides/security/contexts/）は、実行時にジョブに注入できる組織レベルの環境変数を説明している。1月4日のインシデントに関するサポート記事（https://support.circleci.com/hc/en-us/articles/11816211460891-Rotating-Secrets-for-January-4th-Incident）は、実際のローテーションカテゴリを列挙している：OAuth トークン、プロジェクト API トークン、プロジェクト環境変数、コンテキスト変数、ユーザーAPI トークン、プロジェクト SSH キー、ランナートークン。そのリストは、真のガバナンス対象を示している。顧客は単一のパスワードが露出したかどうかを尋ねる必要はなく、CI 信頼グラフを棚卸しする必要があった。

信頼グラフには複数の所有レイヤーがあった。CircleCI は指定された期限前に作成されたプロジェクトおよび個人用 API トークンを失効させることができた。GitHub や Atlassian と協力して、顧客に代わって OAuth トークンをローテーションできた。保存されたシークレットを特定するためのガイダンスとツールを公開できた。しかし、顧客の AWS アクセスキー、データベースパスワード、署名キー、Kubernetes トークン、サードパーティ SaaS API キーは、実際にそのキーを承認するシステムでローテーションする必要があった。CircleCI はすべてのダウンストリーム使用状況を確認できず、顧客は CircleCI の内部フォレンジックのすべてを確認できなかった。したがって、修復は共同で行われなければならなかった。CircleCI は十分に迅速に開示し、十分な詳細を提供する必要があった。顧客は自身のローテーションとログレビューを実行する必要があった。

これが、このケースが単なるベンダーの侵害に還元できない理由である。CircleCI のインシデントレポートによると、公開時点で、5社未満の顧客がインシデントの結果としてサードパーティシステムへの不正アクセスを CircleCI に報告していた。これは重要な制限であり、すべての顧客システムが侵害されたという裏付けのない主張に膨らませるべきではない。同時に、CircleCI は、流出したキーとトークンがすべての顧客のサードパーティシステムに対して使用されたかどうかを知ることはできないとも述べている。この不確実性こそが、シークレットローテーションを説明責任の試金石にした理由である。

盗まれた2FA 対応セッションがエンドポイントと ID の教訓を変えた

CircleCI の公開説明はマルウェアに焦点を当てており、単純なパスワード侵害ではないとしている。同社は、攻撃者がエンジニアのノート PC から有効な2FA 対応 SSO セッションを盗んだと述べている。この区別は重要である。なぜなら、これが古典的な「MFA を使用せよ」というアドバイスが不完全である理由を示すからだ。システムはログイン時に MFA を要求できるが、認証後にセッションクッキー、エンドポイントトークン、ブラウザ状態が盗まれると失敗する可能性がある。攻撃者が有効なセッションを取得すると、制御の問題はデバイスの状態、セッションのバインド、特権の段階的上昇、異常検知、プロダクションアクセスのセグメンテーション、異常なアクションが対応をトリガーする速度に移る。

CircleCI によると、標的となった従業員は通常の職務の一環としてプロダクションアクセストークンを生成する権限を持っていた。この事実は、従業員が過失行為をしたという証拠として読まれるべきではない。これは、プロダクションアクセスが一部のサポートまたはエンジニアリング機能にとって運用上必要であり、セッション盗難のリスクは実際の作業を中心にモデル化されなければならないという証拠として読まれるべきである。現代の CI プロバイダーは、すべての従業員アカウントがログイン後に無害であると想定できない。盗まれたセッションが、新たな証明、ハードウェアバインド認証、ジャストインタイム承認、別個の特権パス、デバイスと役割に矛盾する動作の監視なしに何ができるかを制限する必要がある。

インシデントレポートは、それらの制御に対応するいくつかの対応アクションを説明している。CircleCI は侵害された従業員のアクセスを停止し、ほぼすべての従業員のプロダクションアクセスを制限し、露出の可能性があるプロダクションホストをローテーションし、プロジェクトおよび個人用 API トークンを失効させ、パートナーと協力して OAuth トークンをローテーションし、MDM およびアンチウイルスツールを通じてマルウェア動作の検出とブロックを追加し、プロダクションアクセスを保持する従業員に対して段階的上昇認証を追加し、特定された動作パターンの監視と警告を実装した。これらの手順は、即時のベクトルが閉じられたという同社の主張を裏付けるが、一つの盗まれたセッションにいくつのレイヤーが関与していたかも示している。

より広範な標準環境は、その教訓を強化する。CISA のフィッシング耐性 MFA ファクトシート（https://www.cisa.gov/sites/default/files/2023-01/fact-sheet-implementing-phishing-resistant-mfa-508c.pdf）は、一部の認証方法が通常のワンタイムコードよりもフィッシングやベリファイアのなりすましに耐性がある理由を説明している。NIST のデジタル ID ガイダンス（https://pages.nist.gov/800-63-4/sp800-63b.html）は、より強力な認証子とセッション制御を、所有に関する弱い仮定から区別している。FIDO Alliance のパスキーと FIDO2 の資料（https://fidoalliance.org/passkeys/、https://fidoalliance.org/fido2/）は、フィッシング耐性認証の背後にある公開鍵モデルを説明している。これらの文書は CircleCI に対する所見ではない。これらは、2FA 対応セッションがなぜ段階的上昇とデバイスバインド保護を依然として必要とするかを理解するための制御語彙である。

エンドポイント侵害は開示の課題も生み出す。顧客が従業員のノート PC が感染したと聞くと、ダウンストリームの影響を過小評価する可能性がある。顧客シークレットを含むプロダクションデータストアが流出したと聞くと、統合されたすべてのシステムが悪用されたと想定して過剰修正する可能性がある。CircleCI のレポートは中間を提供しようとした。顧客シークレットの流出があり、顧客は保存されたシークレットがアクセスされたと想定すべきであり、CircleCI はすべてのダウンストリーム使用を判断できないため、顧客は自社のシステムを調査すべきである。この正確さは、公開関係の都合ではなく証拠に責任を合わせるため価値がある。

ローテーションは発見可能で、タイムスタンプ付きで、監査可能でなければならなかった

シークレットローテーションは言うのは簡単だが、証明するのは難しい。小規模なアプリケーションでは、チームは使用中の少数の認証情報を知っているかもしれない。大規模組織では、CI シークレットはプロジェクト、コンテキスト、ユーザー、ランナー、フォーク、名前変更されたリポジトリ、削除されたプロジェクト、レガシー統合、個人用トークン、デプロイキー、パッケージレジストリ、クラウドロール、ワークフロー固有の変数に分散している可能性がある。説明責任のある修復の問いは、顧客が CircleCI に保存されていた可能性のあるすべてのシークレットを見つけ、それを承認するシステムでローテーションし、すべての依存ジョブを更新し、古い認証情報がもはや機能しないことを検証できるかどうかである。

CircleCI の対応はこの実践的な問題を認識していた。セキュリティアラートは、顧客に CircleCI-Env-Inspector ツール（https://github.com/CircleCI-Public/CircleCI-Env-Inspector）を紹介し、保存されたシークレットを発見できるようにした。CircleCI は、顧客がコンテキスト変数のローテーション成功を検証できるように、Contexts API にupdated_atフィールドを追加したと述べている。チェックアウトキーに SHA-256 署名サポートを追加した。対応中に、無料および有料顧客が監査ログにアクセスできるようにした。API ドキュメント（https://circleci.com/docs/api/v2/）は、自動化に関連するコンテキストおよび環境変数操作を説明している。監査ログドキュメント（https://circleci.com/docs/guides/security/audit-logs/）は、組織が監査データを取得する方法を説明している。

これらは表面的な機能ではない。漠然とした指示を測定可能なワークフローに変換する。顧客は次のことを尋ねることができる：どのプロジェクトに環境変数があったか；どのコンテキストが存在したか；どの変数に最近の更新タイムスタンプがあるか；どのチェックアウトキーが存在するか；どのユーザーまたはジョブがシークレットに触れたか；どのランナートークンがアクティブか；露出ウィンドウ後にどのビルドが高リスクコンテキストを使用したか；ローテーション後にどのダウンストリームクラウドログが古い認証情報の使用を示しているか。発見可能性とタイムスタンプがなければ、ローテーションは主張にすぎない。それらがあれば、証拠になる。

問題は依然として難しい。なぜなら、すべてのシークレットが同じように見えるわけではないからだ。一部の値は意図的にマスクされているか、入力後に読み取れなくなる。これは良い保存慣行だが、顧客は実際の値ではなく名前、場所、メタデータしか見られないことを意味する。PROD_DEPLOY_KEYという名前のシークレットはローテーションの指針となるが、古いまたは誤解を招く名前はそれを複雑にする可能性がある。名前変更されたプロジェクトや削除されたリポジトリは、古い変数を隠す可能性がある。共有コンテキストは、一つのシークレットが多くのジョブに影響を与える可能性がある。セルフホストランナーは、トークンとローカル設定を変更する必要がある第二の場所を導入する。CircleCI のサポートガイダンスの2023年3月の更新では、発見ツールが UI で表示されないシークレットを見つけるように更新されたと述べており、最初の開示後も棚卸しの問題が続いていたことを示している。

顧客は CircleCI の外部でも監査する必要があった。CircleCI のインシデントレポートは、IP アドレス、VPN プロバイダー、悪意のあるファイル、repo.download_zipなどの GitHub 監査ログインジケータを列挙していた。この情報は、顧客が GitHub、クラウド、内部ログを検索するのに役立つ。GitHub の OAuth アプリドキュメント（https://docs.github.com/en/apps/oauth-apps/building-oauth-apps/authorizing-oauth-apps）は、広範な OAuth 権限が CI サービスをリポジトリアクセスに接続できるため関連する。GitHub の組織監査ログドキュメント（https://docs.github.com/organizations/keeping-your-organization-secure/managing-security-settings-for-your-organization/reviewing-the-audit-log-for-your-organization）は、リポジトリイベントをレビューするための語彙を提供する。したがって、顧客側の修復は CircleCI の設定だけでなく、システム横断的でなければならなかった。

CI プラットフォームはデプロイされているシステムを所有せずにデプロイ権限を集中させる

このインシデントの最も難しいガバナンス特性は、管理と結果の分割である。CircleCI は顧客ワークフローに属するシークレットを保持していたか、アクセスできたが、それらのシークレットが使用された場合の結果は多くの場合顧客のシステムで発生する。盗まれた AWS キーは AWS ログを生成する。盗まれたデータベース認証情報はデータベースログを生成する。盗まれたパッケージトークンはレジストリログを生成する。盗まれたウェブフックシークレットはアプリケーションに影響を与える可能性がある。CircleCI は自社側からの流出を見ることができたが、すべてのダウンストリーム環境での結果の動作を必ずしも見ることはできなかった。

これは古典的なクラウド依存関係の問題を生み出す。顧客は管理された CI プラットフォームを使用することを選択し、すべてのビルドインフラを自社で実行することを避けた。プラットフォームはその後、顧客のデプロイ権限にとってセキュリティ関連のサービスプロバイダーとなった。顧客は、どのシークレットを保存するか、静的認証情報と短期間のフェデレーションのどちらを使用するか、各コンテキストにアクセスできるジョブ、付与されるクラウド権限、ダウンストリームログを保持するかどうかを決定する責任を引き続き負った。しかし、プロバイダーはストレージレイヤー、内部プロダクションアクセス、従業員特権、インシデント検出、開示タイミングを管理していた。どちらの側も単独で完全なチェーンを修復できなかった。

だからこそ、CircleCI の OIDC ガイダンス（https://circleci.com/docs/guides/permissions-authentication/openid-connect-tokens/）が重要なのである。OIDC はジョブが短期間の ID トークンを受け取り、互換性のあるクラウドプロバイダーが一時的な認証情報と交換できるようにし、CircleCI に長期有効なクラウドシークレットを保存する必要性を減らす。AWS IAM の OIDC ID プロバイダードキュメント（https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_oidc.html）と Google Cloud のワークロード ID フェデレーションドキュメント（https://cloud.google.com/iam/docs/workload-identity-federation）は、このモデルのクラウドプロバイダー側を説明している。説明責任の教訓は、OIDC が2023年のインシデントのすべての経路を解決したであろうということではない。CI プラットフォームに保存された長期有効なシークレットが永続的な爆発半径を生み出す一方、フェデレーションされた短期間の認証情報は将来の露出の価値を低下させる可能性があるということである。

その他の CircleCI の制御も同じ原則にマッピングされる。IP 範囲（https://circleci.com/docs/guides/security/ip-ranges/）は、顧客が既知の CircleCI エグレス範囲へのインバウンドアクセスを制限するのに役立つ。コンテキスト制限は、どのジョブがどのシークレットを見るかを減らすことができる。セルフホストランナーのドキュメント（ランナートークンガイダンスを含む、https://circleci.com/docs/guides/execution-runner/runner-faqs/）は、ランナートークンに独自の管理モデルがあることを示している。OAuth 組織での CircleCI GitHub App の使用に関する CircleCI のドキュメント（https://circleci.com/docs/guides/integration/using-the-circleci-github-app-in-an-oauth-org/）は、広範な OAuth トークンと比較して、より細かく短期間のバージョン管理アクセスを指し示している。各制御は信頼グラフの異なる部分を狭める。

経済的摩擦は現実的だ。OIDC の採用にはクラウド IAM の作業、信頼ポリシー、ジョブ設定、場合によってはアプリケーションの変更が必要になる。コンテキストの最小化には、エンジニアリングチームがシークレットを再編成し、利便性をある程度犠牲にする必要がある。IP 範囲はクレジットを消費し、一部のネットワークパターンにしか適合しない場合がある。監査ログのレビューはスタッフの時間を消費する。GitHub App への移行はユーザー認証フローを変更する可能性がある。しかし、インシデントは代替コストを示した：ライブの不確実性ウィンドウ中の緊急ローテーションにわたる多くのチームの協調。成熟したリスクファイルは、デフォルトで安全な設定の定常コストと、露出後のクリーンアップの破壊的コストを比較すべきである。

開示は、顧客が確実性を過大主張せずに行動できるようにする必要があった

CircleCI のコミュニケーション負担は、すべてのフォレンジック詳細が完了する前に顧客が緊急行動を必要としたため困難だった。1月4日のアラートは即時のローテーションを優先した。1月12日のインシデントレポートは、攻撃経路、タイムライン、データクラス、対応アクション、調査ガイダンスを追加した。説明責任の観点から、この順序は防御可能である：プロバイダーが顧客シークレットが露出した可能性があることを知っている場合、遅延はダウンストリームの害を増大させる可能性がある。しかし、緊急性は混乱も生み出す。顧客は、何が正確に露出したのか、ビルドは安全か、どの時間枠を調査すべきか、どのシークレットをローテーションすべきかを尋ねた。

レポートはそれらの質問の一部に明示的な記述で回答した。CircleCI は、プラットフォームの是正後、顧客は安全にビルドできると述べた。2023年1月5日以降にシステムに入力されたものはすべて安全と見なすことができると述べた。不正な第三者アクセスは2022年12月19日に確認され、データ流出は2022年12月22日に発生したと述べた。12月16日の侵害日から顧客がローテーションを完了するまでの期間を調査することを推奨した。公開時点で、5社未満の顧客がインシデントの結果としてサードパーティシステムへの不正アクセスを CircleCI に報告していたと述べた。

これらの詳細は曖昧さを減らすが、すべての未知を排除するわけではない。公開証拠は、影響を受けたすべての顧客、露出したすべてのキー、アクセスされたすべてのデータストア、すべての顧客のローテーション結果を列挙していない。すべてのダウンストリーム認証情報が失効されたことを独立して証明していない。完全な外部フォレンジックレポートを示していない。責任ある分析は、それらのギャップを推測で埋めるべきではない。正しい結論はより狭い：CircleCI は顧客の環境変数、キー、トークンの流出を公開確認した；保存されたシークレットはアクセスされたと想定するよう顧客に促した；タイムラインとインジケータを提供した；それらのシークレットのすべてのダウンストリーム使用を知ることはできないと認めた。

このバランスは顧客の信頼にとって重要である。プロバイダーが少なすぎることを言うと、顧客は行動できない。証拠が成熟する前に多すぎることを言うと、顧客は誤った決定を下したり、後の修正への信頼を失ったりする可能性がある。CircleCI の顧客ツールと API メタデータの追加は、開示が言葉だけではないことも示している。プロバイダーは、ログ、タイムスタンプ、スクリプト、インジケータ、機械可読エンドポイントを公開することで、コミュニケーションをより実行可能にすることができる。

規制および公共部門のガイダンスは、この証拠優先のアプローチを支持している。CISA のセキュアバイデザインプログラム（https://www.cisa.gov/securebydesign）は、設計と説明責任を通じて顧客リスクを削減することを強調している。NIST のサイバーセキュリティフレームワーク（https://www.nist.gov/cyberframework）は、特定、保護、検出、対応、復旧の有用なサイクルを提供する。CircleCI のケースでは、サイクルは具体的である：保存されたシークレットを特定し、最小権限と短期間の認証情報を通じて将来のジョブを保護し、不審なダウンストリーム使用を検出し、ローテーションと失効によって対応し、古い認証情報がもはや機能しないことを証明して復旧する。

実質的な管理は共有されていたが、平等ではなかった

このインシデントにおける責任は、実質的な管理によって割り当てられるべきである。攻撃者は不正アクセスと流出を実行した。CircleCI はプラットフォーム環境、従業員エンドポイント制御、プロダクションアクセスモデル、セッション保護、ストレージと暗号化アーキテクチャ、プラットフォーム発行トークンの失効、顧客コミュニケーション、是正ツールを管理していた。顧客は CircleCI に何を保存するか、それらのシークレットに付与された特権、ダウンストリームログレビュー、自社のクラウドおよびアプリケーションシステム内でのローテーションを管理していた。バージョン管理およびクラウドプロバイダーは、独自のトークンモデル、監査ログ、フェデレーション ID 機能、失効メカニズムを管理していた。

割り当ては平等ではない。CircleCI は失敗したプラットフォーム境界に対する最も強力な管理を持っていた。顧客はインシデント前に CircleCI の従業員ノート PC、プロダクションセッションモデル、内部プロダクションホストを検査できなかった。彼らは CircleCI の制御と開示に依存した。そのため、CircleCI はプロバイダー側の失敗と顧客の是正を可能にすることについて主要な説明責任のある当事者となる。顧客は依然として爆発半径の選択、特に短期間のフェデレーションまたはより狭いスコープが利用可能な場合に長期有効な高特権認証情報を保存することに対して責任を負う。しかし、顧客の責任は管理に対するプロバイダーの責任を消し去るものではない。

GitHub、Bitbucket、GitLab、AWS、Google Cloud は、顧客の CI シークレットがしばしばそれらを指すため、説明責任マップに登場する。CircleCI のレポートは、トークンローテーションについて GitHub および Atlassian と協力したと述べている。GitHub のドキュメントは監査ログと OAuth 制御を説明している。AWS と Google Cloud のドキュメントはフェデレーション ID を説明している。これらのプロバイダーは公開記録において CircleCI のインシデントを引き起こしたと主張されていない。それらは修復エコシステムの一部であり、顧客が認証情報をローテーション、失効、監査、再設計するためにそれらの制御を使用する必要があったからである。

セキュリティベンダーやサードパーティのレポートは顧客がイベントを解釈するのに役立つが、二次的であるべきである。Snyk の分析（https://snyk.io/blog/supply-chain-security-incident-circleci-secrets/）と AppOmni の議論（https://appomni.com/ao-labs/unpacking-preventing-circleci-data-breach/）は、シークレットローテーションと SaaS リスクに関する外部ガイダンスの有用な例である。それらは確認された事実の情報源として CircleCI のインシデントレポートを置き換えるべきではない。最も強力な記録は、一次インシデント開示、プラットフォームドキュメント、クラウド ID ドキュメント、顧客側ログを組み合わせる。

顧客の調達教訓は直接的である。CI プロバイダーが保存中のシークレットを暗号化しているかどうかだけを尋ねるベンダーアンケートは不十分である。このインシデントでは、CircleCI は環境変数が保存中に暗号化されていたと述べているが、攻撃者は顧客シークレットを含むストアからデータを取得することができた。より深い質問は、プロダクションで誰がシークレットを復号化またはアクセスできるか、従業員セッションがどのように制約されているか、特権のあるプロダクションアクションに段階的上昇認証が必要かどうか、顧客シークレットがテナントと目的ごとに分離されているかどうか、監査ログがシークレットアクセスを示すかどうか、プラットフォーム発行トークンがどのくらい迅速に失効できるか、インシデント中に顧客がどのようなツールを受け取るかである。

検証可能な修復はどのように見えるべきか

CI シークレットインシデント後の検証可能な修復には、いくつかのレイヤーが必要である。最初のレイヤーはプロバイダー側の封じ込めである。プロバイダーは攻撃者のアクセスを削除し、露出の可能性がある内部ホストとキーをローテーションし、侵害されたセッションを無効にし、プロダクションアクセスを制限し、ログと必要に応じて外部調査員を使用して調査結果を検証しなければならない。CircleCI は、アクセス停止、プロダクションホストのローテーション、API トークンの失効、パートナー支援による OAuth ローテーション、MDM およびアンチウイルス検出の更新、段階的上昇認証、監視、サードパーティサポートを含むこれらのアクションの多くを公開説明した。

第二のレイヤーは顧客側の棚卸しである。顧客は、プロジェクト環境変数、コンテキスト変数、プロジェクト API トークン、個人用 API トークン、ランナートークン、SSH キー、OAuth 許可、その他の保存されたシークレットの完全なリストを必要とする。棚卸しには、場所、所有者、最終更新時刻、特権、依存ジョブ、ダウンストリームシステムを含める必要がある。名前だけでは、チームがトークンの到達範囲を判断できない場合は十分ではない。CircleCI の発見ツール、Contexts API の更新、監査ログ、サポートガイダンスは、顧客がこのリストを構築するのに役立ったため重要だった。

第三のレイヤーは失効とダウンストリーム検証である。ローテーションされたシークレットは、それを受け入れるシステムで無効化されなければならない。古い認証情報でジョブが成功し続ける場合、修復されていない。顧客は、露出期間中の不審な使用について、クラウド監査ログ、バージョン管理ログ、データベースログ、パッケージレジストリログ、デプロイメントログ、ウェブフックログ、アプリケーションログを確認すべきである。CircleCI 自身の声明はすべてのダウンストリーム使用を知ることはできないと述べており、顧客ログはオプションではない。それらは一部の悪用が可視化される唯一の場所である。

第四のレイヤーは再設計である。長期有効なシークレットは、可能な場合は短期間のフェデレーション認証情報、OIDC、スコープ設定された GitHub App 権限、狭いコンテキスト、ブランチおよびプロジェクト制限、保護された環境、個別のデプロイ承認に置き換えられるべきである。CircleCI の定期的な自動 OAuth トークンローテーションの開始、OAuth から GitHub App への移行、警告の拡大、セッション信頼の低減、認証要素の追加、より頻繁なアクセスローテーションの実行、権限のより一時的なものへの変更計画は、このレイヤーと一致している。顧客は、これらのコミットメントがインシデント言語だけでなく、デフォルトのリスクを変更したという証拠を期待すべきである。

第五のレイヤーは監査可能性である。顧客は自社の組織に関連するプラットフォームアクティビティのログにアクセスできるべきである。プロバイダーは保持、イベント範囲、エクスポート制限、プランに基づく制約を文書化すべきである。CircleCI の2023年11月のチェンジログエントリ（https://circleci.com/changelog/audit-log-includes-context-accessed/）は、context.secrets.accessedを監査ログイベントとして示しており、顧客が必要とする詳細の種類を示している：ジョブが実行されただけでなく、機密コンテキストがアクセスされたことである。より多くのログ詳細はプライバシーとセキュリティのトレードオフを生み出す可能性があるが、イベント証拠がなければ、顧客はシークレット露出を独立して評価できない。

第六のレイヤーはガバナンスである。プロバイダーはイベントを一度きりの緊急事態として扱うべきではない。インシデントを方針に変換すべきである：定期的なシークレットレビュー、最小権限のプロダクションアクセス、ハードウェアバインドまたはフィッシング耐性の特権認証、エンドポイント侵害訓練、顧客インシデントプレイブック、長期有効なシークレットを discourage する製品デフォルト、エンタープライズバイヤーのための調達証拠。顧客はイベントを自社の方針に変換すべきである：フェデレーションが利用可能な場合に高特権の耐久性のある認証情報を CI に保存しない、コンテキスト使用を制限する、ランナートークンの管理をレビューする、ローテーションの所有者を文書化する、緊急時の認証情報失効をテストする。

証拠の境界と未知のもの

公開証拠はいくつかの確固たる結論を裏付けている。CircleCI は2023年1月4日にセキュリティインシデントを開示した。インシデントレポートによると、エンジニアのノート PC 上のマルウェアにより、有効な2FA 対応 SSO セッションの盗難が可能になった。攻撃者は一部の本番システムにアクセスし、2022年12月22日に環境変数、トークン、キーを含む顧客情報を流出させた。関連期間中にシークレットを保存していた顧客に対して、それらのシークレットがアクセスされたと想定するよう指示した。いくつかのカテゴリのトークンを取り消すかローテーションし、パートナーと協力した。調査ガイダンスとインジケータを提供した。レポートの時点で、5社未満の顧客がサードパーティシステムへの不正アクセスを CircleCI に報告したと述べた。

公開証拠はいくつかのより強い主張を裏付けていない。すべての CircleCI 顧客が不正なダウンストリームアクセスを受けたことを証明していない。露出したすべてのシークレットやすべての顧客を特定していない。完全なサードパーティフォレンジックレポートを提供していない。すべての顧客がローテーションを完了したことを証明していない。是正前後のすべての内部プロダクションアクセス制御を示していない。顧客が高特権シークレットのローテーションに失敗した場合、顧客のシステムが安全であることを証明していない。これらの境界は、説明責任分析が不確実性を非難に変えると信頼性を失うため重要である。

残りの未知のものは依然としてガバナンスに関連する。どのくらいの組織が高特権認証情報を保存していたか？一部のシークレットはローテーションなしでどのくらい存在していたか？どの顧客セグメントが静的キーではなく OIDC を使用していたか？12月16日以降に調査するのに十分なダウンストリームログを持っていた顧客はどのくらいか？顧客はどのくらい迅速にローテーションを完了したか？インシデント後に CircleCI の製品デフォルトは恒久的にどのように変更されたか？どの特権従業員アクションが現在ハードウェアバインドまたは段階的上昇証明を必要とするか？公開記事はそれらすべてに答えることはできない。エンタープライズバイヤーは、NDA、セキュリティレビュー、監査レポート、調達評価の下で証拠を要求することができ、またそうすべきである。

最も強い教訓は、CI シークレット露出はクラウドサービス依存関係の問題であり、セキュリティ運用の問題だけではないということである。クラウド CI プロバイダーは顧客シークレットを委任された権限として扱わなければならない。顧客は、別途制約しない限り、すべての CI シークレットをライブプロダクション経路として扱わなければならない。修復基準は、プロバイダーが自信を持ったポストモーテムを公開するかどうかではない。それは、両側がシークレットの管理、ローテーション、監査可能性、将来の認証情報設計が、同じプロバイダー側の失敗が顧客側の侵害になる可能性を減少させたことを証明できるかどうかである。

2026年になってもこれが重要な理由

CircleCI インシデントは2026年になっても重要であり、それは開発者オートメーションが以前よりも特権的になっているからであり、その逆ではない。CI システムは現在、インフラストラクチャ・アズ・コードの変更、コンテナビルド、デプロイ承認、パッケージ公開、フィーチャーフラグ変更、セキュリティスキャン、モデルデプロイ、モバイルリリース、コンプライアンス証拠収集をトリガーする。単一の CI 環境は多くのビジネスシステムへの鍵を保持できる。チームがより多くのオートメーションを採用するにつれて、開発者生産性と運用権限の境界線は曖昧になり続けている。

インシデントはまた、セキュリティオートメーションが説明責任オートメーションと組み合わされなければならない理由を示している。プラットフォームが顧客にシークレットのローテーションを推奨するだけでは十分ではない。顧客が作業を検証できるようにする API、タイムスタンプ、ログ、棚卸しツール、インジケータ、製品デフォルトが必要である。顧客が認証情報をローテーションしたと言うだけでは十分ではない。依存関係マップ、所有者、古いキーの無効化チェック、ダウンストリームログレビューが必要である。緊急時には、手動の記憶と暗黙知は信頼できる制御ではない。

取締役会と経営幹部にとって、このケースは CI リスクを事業継続リスクとして再定義する。シークレットローテーションの演習は、デプロイメントを凍結し、統合を破壊し、収益運用を中断し、エンジニアリングの注意を消費する可能性がある。見逃された認証情報はフォローオンアクセスを許可する可能性がある。ログの欠如は、リーダーシップがインシデントが終了したかどうかを顧客に伝えることを不可能にする。したがって、経済的損害は元の侵入だけでなく、弱い棚卸しと弱いローテーション証明によって課される不確実性税である。

ベンダーにとって、このケースは安全なデフォルトを指し示している。OIDC は採用が容易であるべきだ。コンテキストは制限が容易であるべきだ。監査ログは機密アクセスを示すべきだ。GitHub App 統合は、可能な場合は広範な OAuth パスよりも容易であるべきだ。ランナートークンは棚卸しが容易であるべきだ。未使用のシークレットは警告を生成すべきだ。プロダクション従業員アクセスは稀で、短期間で、強力に検証されるべきだ。インシデントコミュニケーションには、声明だけでなく行動経路を含めるべきだ。

顧客にとって、このケースは CI プロバイダーがいつか失敗する可能性があるかのように CI 認証情報を設計することを主張している。それはクラウド CI を拒否することを意味しない。最小権限、短期間の認証情報、個別の環境、デプロイ承認、外部ログ保持、リハーサルされたローテーションを使用することを意味する。緊急事態の前にすべてのプロジェクトとコンテキストにどのシークレットが存在するかを知っていることを意味する。ビルドが「開発」と呼ばれていても、CI をプロダクション信頼境界の一部として扱うことを意味する。

最終的な説明責任の所見は狭く、証拠に基づいている。CircleCI は、攻撃者がエンドポイントとセッションを侵害した後、一部のシステムから顧客の環境変数、トークン、キーを流出させたことを公開確認した。公開証拠は普遍的なダウンストリーム侵害を証明していない。公開証拠は、顧客シークレットローテーションが中心的な修復負担となったことを証明している。インシデントはクラウド CI の構造的現実を可視化した：プロバイダーは顧客のアプリケーションを所有していないかもしれないが、そのアプリケーションを動かす認証情報を保持することができる。

ソース元台帳