Codecov Bash Uploader の侵害：CI シークレットの説明責任を問う

要約

• Codecov の 2021 年の Bash uploader 侵害は、CI シークレットの説明責任テストとなった。Codecov 自身のセキュリティアップデートによると、第三者が Bash uploader を改ざんし、顧客の CI 環境から環境変数や Git リモート情報をエクスポートする可能性があったためである。
• Codecov の事後分析（ポストモーテム）では、攻撃者がパブリックなセルフホスト Docker イメージの中間レイヤから Google Cloud Storage サービスアカウントの HMAC キーを抽出し、そのキーを使用してエンドユーザーに提供される Bash uploader を改ざんしたとしている。
• 責任の所在は、単にユーザーがチェックサムを確認すべきであったという問題ではない。Codecov は、アップローダーの配布経路、公開 Docker イメージのビルドプロセス、ホストされたスクリプトの監視、顧客への通知、そして curl-to-shell の信頼パターンからの移行計画を管理していた。
• 顧客側は、CI ジョブで利用可能なシークレット、使用するアップロード方法、チェックサム検証の実施、通知後の認証情報のローテーション速度を制御できた。しかし、これらの顧客側の制御は、プロバイダーのスクリプト整合性に対する責任を消し去るものではない。
• 本記事では、Codecov のセキュリティアップデートとポストモーテムを一次情報源、顧客のインシデント対応を自社側のダウンストリーム証拠、NIST、CISA、SLSA、Sigstore、および CI ドキュメントを技術的管理用語として扱う。法執行機関のファイル、顧客の非公開リスト、攻撃者の完全なインフラログへのアクセスを主張するものではない。

なぜこのケースがリスクと説明責任ファイルに含まれるのか

Codecov がリスクと説明責任ファイルに含まれる理由は、2021 年の Bash uploader 侵害により、日常的なカバレッジアップロード手順が CI シークレットの漏洩経路となる可能性が明らかになったからである。Codecov の 2021 年 4 月 15 日のセキュリティアップデート（https://about.codecov.io/security-update/）によると、Codecov は 4 月 1 日に、誰かが Bash uploader スクリプトに不正にアクセスし、許可なく改ざんしたことを把握した。同社は、Codecov の Docker イメージ作成プロセスのエラーにより、アップローダーを改ざんするために必要な認証情報が抽出されたことが原因だと述べている。また、2021 年 1 月 31 日以降、定期的に不正な改ざんが行われ、顧客の継続的インテグレーション環境に保存された情報を Codecov のインフラ外の第三者のサーバーにエクスポートする可能性があったとしている。

この公開情報により、このケースは単なるベンダースクリプトの侵害以上のものとなった。Bash uploader は顧客の CI ジョブ内で実行され、多くの場合、テスト完了後、カバレッジデータのアップロード前に動作する。CI ジョブには、リポジトリ URL、ビルドメタデータ、デプロイトークン、パッケージ公開認証情報、クラウド認証情報、署名鍵、データベース URL、ウェブフックシークレット、個人用アクセストークン、テストおよびリリース自動化で使用される環境変数が含まれる可能性がある。アップローダーへの小さな悪意のある追加が、認証情報の収集ポイントとなり得るのは、顧客が意図的に CI に信頼とシークレットを配置しているためである。

Codecov の事後分析（https://about.codecov.io/apr-2021-post-mortem/）は、この管理の全体像をより鮮明にした。それによると、脅威アクターは Bash uploader を標的とし、Bash uploader、Codecov GitHub Action、Codecov CircleCI Orb、Codecov Bitrise Step を利用するユーザーに悪意のあるペイロードを配信するために使用した。攻撃者は、パブリックな Codecov セルフホスト Docker イメージの中間レイヤから Google Cloud Storage サービスアカウントの HMAC キーを抽出し、そのキーを使用して Google Cloud Storage 内の Bash uploader を改ざんした。また、SHASUM チェックを実行し、GitHub で報告されたハッシュとダウンロードしたアップローダーの計算ハッシュとの不一致に気づいた顧客が、このインシデントを検出したとしている。

これらの事実は、責任が共有されつつも不平等なシステムに位置づけられる。Codecov は、ホストされたアップローダー、Google Cloud Storage への書き込み経路、セルフホスト Docker イメージのビルドプロセス、インシデント後の鍵のローテーション、顧客への通知、新しいアップローダーへの移行を管理していた。顧客側は、アップローダー実行時にどの CI 変数が存在するか、スクリプトをライブで取得するかどうか、チェックサム検証を実施するかどうか、露出したシークレットをどの程度迅速にローテーションできるかを制御していた。CI プロバイダーは、シークレットのマスキング、ジョブの分離、ログ記録の一部を管理していた。ダウンストリームのユーザーは、露出した認証情報が後日システムやコードへのアクセスを可能にした場合、リスクを負うことになる。実際の課題は、各当事者が適時に行動するのに十分な証拠を持っていたかどうかである。

この出来事は、開発者ツールの経済性に適合する。なぜなら、Codecov の価値提案は、多くの CI システムにわたる低摩擦のカバレッジレポートだったからである。アーカイブされた Codecov Bash uploader リポジトリ（https://github.com/codecov/codecov-bash）は、利便性のパターンを直接示している。顧客はリモートスクリプトを取得して実行し、多くの CI プロバイダーで同じアップローダーを使用し、オプションで SHASUM を検証できた。利便性が採用の原動力だった。しかし、信頼されたリモートスクリプトが攻撃者制御の経路から変更可能になったとき、隠れたコストとして、緊急の認証情報インベントリ、ローテーション、リポジトリレビュー、顧客通知、インシデント対応が発生した。

Bash uploader は CI 内に信頼の逆転を生み出した

カバレッジアップローダーは過小評価されがちである。テストジョブの最後、メインのアプリケーションコードがすでに実行された後に現れる。この配置は、ビルドツール、デプロイコマンド、パッケージ公開ステップよりもリスクが低いように見える。しかし実際には、パイプラインが意図的に分離しない限り、カバレッジアップローダーはそれを呼び出すジョブと同じ環境を見ることができる。ジョブにクラウド認証情報、API トークン、リポジトリアクセス、パッケージレジストリのシークレット、サービスキーが含まれている場合、アップローダープロセスはそれらを読み取ることができる可能性がある。

Codecov 自身の Bash uploader ドキュメント（https://docs.codecov.com/docs/about-the-codecov-bash-uploader）とアーカイブされたリポジトリの指示は、これが重要である理由を示している。アップローダーは、CI 設定を検出し、レポートを収集し、カバレッジデータを送信するように設計されていた。同じリポジトリには、SHASUM ファイルを使用した検証プロセスが文書化されていたが、Codecov の事後分析では、インシデント前にこのプロセスが完全または適切に文書化されていなかったことが認められている。セキュリティアップデートでは、Bash uploader を使用する前にチェックサム比較を実行していた顧客は影響を受けていない可能性があるとも述べられている。これは示唆に富む境界である。整合性チェックは有効な防御策であったが、配布モデルによって回避不能にされていなかった。

信頼の逆転は単純だった。顧客は Codecov のスクリプトを信頼した。なぜなら、そのスクリプトはテストカバレッジを測定するワークフローにおける依存関係だったからである。そのスクリプトは、Codecov がカバレッジレポートを受け取るために必要な権限よりもはるかに多くの権限を含む可能性のある、顧客管理の CI 環境内で実行された。実質的に、顧客はレポートツールに、もしツールが改ざんされた場合にデプロイシークレットを観察またはエクスポートできる位置を与えたことになる。これは、すべての顧客が重要なシークレットを漏洩したことを意味するわけではない。爆発半径は、Codecov のサービス境界だけでなく、各顧客の CI 環境設計に依存していたことを意味する。

公式の Codecov 通知は、改ざんされたアップローダーが実行されたときにアクセス可能だった場合に影響を受ける可能性のあるクラスとして、認証情報、トークン、キー、サービス、データストア、アプリケーションコード、Git リモート情報を挙げた。この声明は注意深く読む必要がある。すべての顧客がすべてのシークレットを失ったことを証明するものではない。スクリプトが実行された場所に基づく露出の可能性を説明している。その後、顧客は自身のジョブにどのシークレットが存在していたか、それらのシークレットが機密性を持つか、どのシステムをアンロックするか、後の悪用がログに可視かどうかを判断する必要があった。

最新の CI ドキュメントは、この共有リスクモデルを強化している。GitHub Actions のハードニングガイダンス（https://docs.github.com/en/actions/security-guides/security-hardening-for-github-actions）では、シークレット、トークン権限、サードパーティアクション、スクリプトインジェクションリスクについて説明している。GitLab の CI/CD 変数ドキュメント（https://docs.gitlab.com/ci/variables/）や CircleCI の環境変数ドキュメント（https://circleci.com/docs/env-vars/）は、CI システムが制御された条件下で意図的にシークレットをジョブに公開する方法を示している。これらのドキュメントは Codecov に関するインシデントの調査結果ではない。Codecov の侵害が深刻になった環境を定義している。CI ジョブは特権的な自動化ルームであり、中立な端末ではない。

検出のタイミングにより、顧客は不確実性を抱えさせられた

検出のタイミングは中心的な説明責任の問題である。なぜなら、顧客は即座に範囲を知ることができなかったからである。Codecov は、SHASUM 検証を実行していた顧客が不一致を報告した後、2021 年 4 月 1 日に問題を認識したとしている。4 月 15 日の公開開示は、調査、フォレンジック、調整を経て行われた。セキュリティアップデートでは、該当する期間は 1 月 31 日から始まり、影響を受けるユーザーには電子メールとアプリ内通知で連絡が行われたとしている。4 月 29 日のアップデートでは、不正に取得された可能性のある環境変数や、影響を受けた組織とリポジトリに関する追加情報が提供された。

ここには、同時に考慮すべき 2 つの公平性のポイントがある。第一に、インシデント対応には確かに調査が必要である。基本的事実を理解する前に開示するプロバイダーは、顧客を誤解させ、誤った修復を引き起こす可能性がある。Codecov の事後分析では、連邦法執行機関およびサイバーセキュリティ機関と調整しながら調査を行ったとしている。第二に、露出した CI シークレットを持つ顧客には独自の時計がある。2 月にクラウド認証情報、パッケージトークン、リポジトリデプロイキー、署名鍵がジョブで利用可能だった場合、顧客はそれを即座にローテーションし、監査ログを確認し、ダウンストリームの露出を評価する必要があるかもしれない。不確実性が長く続くほど、認証情報が使用されたかどうかを知ることが難しくなる。

したがって、説明責任ファイルは、顧客が 4 月 1 日、4 月 15 日、4 月 29 日に何を知っていたかを問うべきである。影響を受けるアップローダーを使用しているリポジトリを知っていたか。侵害された期間中にアップローダーをライブで取得したかどうかを知っていたか。どの環境変数が取得された可能性があるかを知っていたか。それらのジョブにどのシークレットが正確に存在していたかを知っていたか。チェックサム検証が実行されたかどうかを知っていたか。可能性のある悪用を検査するのに十分な長さのログを持っていたか。これらの質問は、通知が実行可能であったかどうかを決定する。

CISA の Codecov に関するアラートページ（https://www.cisa.gov/news-events/alerts/2021/04/22/codecov-releases-security-update）は、ベンダーの通知を増幅するに値する重要なものとして扱った。これは、インシデントがソフトウェアサプライチェーンおよび顧客修復の問題であり、Codecov 内部の出来事に過ぎないことを示す有用な公開証拠である。NIST のセキュアソフトウェア開発フレームワーク（https://csrc.nist.gov/pubs/sp/800/218/final）もここで有用であり、サードパーティのソフトウェアコンポーネント、ビルド環境、脆弱性対応をライフサイクル管理として位置づけている。Codecov の侵害は、これら 3 つの境界に位置していた。

検出のストーリーは、顧客側の検証の価値と弱点も示している。顧客は、ダウンロードした Bash uploader を期待される SHASUM と照合したことで不一致を発見した。これは検証が機能するという強いシグナルである。また、異常に注意深い顧客だけが実行する場合には弱い管理策でもある。より強力な設計は、署名されていない、または検証不可能な実行を例外とし、デフォルトとしないことである。Codecov の事後分析では、新しいアップローダーは署名され、SHASUM 検証可能なバイナリ実行可能ファイルとして出荷され、Bash uploader の非推奨が是正措置の一部であると述べている。新しいアップローダーの発表（https://about.codecov.io/blog/introducing-codecovs-new-uploader/）は、その理由から修復ファイルに属する。

シークレットのローテーションは実際の顧客の作業負荷だった

侵害が公開されると、運用負担はすぐに顧客に移った。Codecov は、影響を受けるユーザーに対して、CI 環境に露出したキーとトークンを特定し、機密性の高い認証情報を無効にし、交換を生成し、トークンの使用を監査するようアドバイスした。これは、実際のソフトウェア組織に適用されるまで簡単に聞こえる。単一の CI ジョブには、パッケージレジストリトークン、クラウドプロバイダー認証情報、デプロイキー、アーティファクトリポジトリシークレット、統合テスト用のデータベース URL、テストアカウントのパスワード、Slack や PagerDuty のウェブフック、Docker レジストリパスワード、Terraform ステート認証情報、署名材料、個人用アクセストークンが含まれる可能性がある。これらのシークレットは、リポジトリ間で再利用されたり、組織レベルの CI 設定から継承されたりする可能性がある。

顧客側の課題は、ローテーションだけではなかった。マッピングだった。どのリポジトリが影響を受けるアップローダーを使用したか。影響を受ける期間中にどのジョブが実行されたか。それらのジョブにどの環境変数が存在したか。シークレットはログでマスクされていたが、プロセスで読み取り可能だったか。どのクラウドアカウント、パッケージレジストリ、コードホスト、内部サービスがそれらの認証情報を受け入れたか。どのシステムに監査ログがあったか。ログはどの程度保持されていたか。組織は悪用がないことを証明できるか、または防御的にローテーションするしかないか。インシデントのコストは、したがって、確認された悪用と同様に、インシデント対応の労力で測定された。

自社側の顧客対応は、これが重要である理由を示している。HashiCorp の公開セキュリティ通知（https://discuss.hashicorp.com/t/hcsec-2021-12-codecov-security-event-and-hashicorp-gpg-key-exposure/23512）は、リリース署名に使用される GPG 秘密鍵の露出と、失効および交換のプロセスを説明している。Twilio の対応（https://www.twilio.com/en-us/blog/company/communications/response-to-the-codecov-vulnerability）は、その調査と顧客影響評価を説明している。Rapid7 の対応（https://www.rapid7.com/blog/post/2021/05/13/rapid7s-response-to-codecov-incident/）は、自社のレビューと修復を説明している。Mercari のインシデントレポート（https://about.mercari.com/en/press/news/articles/20210521_incident_report/）は、Codecov インシデントに関連する顧客および従業員データの露出を説明している。これらは、すべての Codecov 顧客が同じ結果であったことを証明するものではない。顧客の修復が現実的で、多様で、結果を伴うものであったことを示すダウンストリーム証拠である。

HashiCorp の例は、署名鍵が通常の API トークンではないため、特に教訓的である。署名鍵はソフトウェアの真正性に影響を与える可能性がある。その交換には、失効、新しい信頼の配布、顧客とのコミュニケーション、時間が必要である。これは、Codecov がすべての署名済みアーティファクトを直接侵害したことを意味するわけではない。CI シークレットの露出は、露出した材料がソフトウェアの証明または配布に使用される鍵を含む場合、ソフトウェアサプライチェーンに到達する可能性があることを意味する。爆発半径は、シークレットの種類、使用法、有効期間、および失効の証拠に依存する。

Mercari の例は別の境界を示している。Codecov のインシデントはベンダーツールの侵害であったが、顧客データの露出は、影響を受ける CI ジョブで利用可能なシークレットとシステムに応じて、顧客自身の環境で可視化される可能性がある。そのため、プロバイダーの説明責任と顧客の説明責任をきれいな箱に分けることはできない。Codecov はアップローダーの整合性を修復し、何が起こったかを顧客に伝える必要があった。顧客は、どのシークレットが存在し、それらのシークレットが何に到達できるかを判断する必要があった。

配布の整合性が中心的な修復の主張だった

Codecov インシデント後の中心的な修復の主張は、配布の整合性だった。Bash uploader パターンは、顧客がジョブ実行時に実行可能コードを取得することを奨励した。このパターンにより、アップデートが容易になり、言語サポートが広がったが、ホストされたスクリプトは価値の高い標的となった。攻撃者がストレージ内のスクリプトを改ざんできれば、検証されていないすべてのダウンストリーム取得が悪意のある変更を継承する可能性がある。したがって、プロバイダーは、変更権限、署名、チェックサム、監視、イメージビルド、リリース手順が変更されたことを示す必要があった。

Codecov の事後分析では、いくつかの是正措置が挙げられている。盗まれた鍵の失効、本番鍵の監査とローテーション、公開 Docker イメージをスクォッシュまたはマルチステージビルドに更新、新しいアップローダーの起動、関連する Google Cloud Storage アセットの監視、署名と SHASUM 検証のためのドキュメントの改善、鍵生成とローテーションポリシーの変更、インシデント対応の強化、専任のセキュリティ機能の配置。各措置は、チェーンの異なる部分に対処している。Docker イメージの修正は、イメージレイヤーを介したシークレット漏洩に対処した。鍵のローテーションは、即時の認証経路に対処した。監視は、将来の不正変更に対処した。新しいアップローダーは、配布と検証の設計に対処した。

Docker イメージレイヤーは重要な証拠ポイントである。Codecov は、攻撃者がパブリックなセルフホスト Docker イメージの中間レイヤーから HMAC キーを抽出したと述べている。Docker 自身のマルチステージビルドに関するドキュメント（https://docs.docker.com/build/building/multi-stage/）は、ビルドアーティファクトと中間材料を最終イメージから除外する必要がある理由を説明している。Codecov の事後分析における、スクォッシュまたはマルチステージビルドを使用するという是正措置は、したがって、根本原因のクラスに直接関連していた。イメージレイヤー内のシークレットは、最終コンテナがクリーンに見えるからといって保護されるわけではない。

より広範なソフトウェアサプライチェーン用語も役立つ。SLSA フレームワーク（https://slsa.dev/）と Sigstore（https://www.sigstore.dev/）は、両方ともソフトウェアアーティファクトの整合性、来歴、署名、検証可能性に対処している。これらは Codecov の 2021 年のアップローダーに対する遡及的なコンプライアンステストではない。なぜ可変のホストスクリプトが、署名され、バージョン管理され、検証可能で、来歴のあるアーティファクトよりも弱い配布モデルであるかを定義している。OpenSSF Scorecard（https://scorecard.dev/）も同様に、依存関係とリポジトリの衛生状態を測定可能なサプライチェーン管理として位置づけている。重要なのは、あるフレームワークがインシデントのすべての部分を防止できたということではない。重要なのは、アーティファクトの整合性は、顧客が手動で改ざんを発見することを期待されないように設計されなければならないということである。

現在の Codecov アップローダードキュメント（https://docs.codecov.com/docs/codecov-uploader）とアップローダーリポジトリ（https://github.com/codecov/uploader）は、以前の Bash のみのモデルからの移行方向を示している。Codecov GitHub Action リポジトリ（https://github.com/codecov/codecov-action）は、多くのユーザーが直接の Bash 呼び出しではなく、プラットフォーム統合を通じて Codecov を利用していたため、引き続き関連性がある。インシデントは、ラッパー、オーブ、ステップが共有の基礎となるアップローダーの信頼境界を継承する可能性があることを示した。顧客は CI ネイティブの統合を使用していると考えるかもしれないが、リスクは依然として同じリモートスクリプトまたはバイナリを介して流れる可能性がある。

CI プロバイダーと顧客は依然として爆発半径を縮小する必要があった

プロバイダーの修復は必要だったが、顧客側の爆発半径の縮小は依然として不可欠だった。CI 環境は、ジョブが不要なシークレットを公開すべきではない。カバレッジアップロードステップは、一般的にカバレッジファイルを読み取り、Codecov に認証するために十分な権限のみを必要とする。同じジョブが無関係な責任を組み合わせていない限り、広範なクラウドデプロイ認証情報、本番データベースアクセス、パッケージ公開権限、長期有効な個人用トークンを必要とすべきではない。CI における最小権限は抽象的なものではない。それは、侵害されたサードパーティのアクションやスクリプトが無害なアップロードトークンを見るのか、それとも組織全体の認証情報を見るのかを決定する。

GitHub Actions、GitLab CI、CircleCI、Buildkite、Jenkins などの CI システムは、組織が変数をスコープし、ジョブを分離し、シークレットをマスクし、ブランチアクセスを制限し、保護された環境を要求し、トークン権限を制限する方法を提供している。しかし、これらの管理策は、パイプライン設計がそれらを使用する場合にのみ有用である。テストの実行、アーティファクトのビルド、インフラのデプロイ、リリースの署名、パッケージの公開、カバレッジのアップロードを行うモノリシックジョブは、共通モードの露出を生み出す。最後のカバレッジステップが以前のステップで使用されたすべての環境変数を読み取れる場合、爆発半径は必要性ではなく利便性によって定義される。

したがって、Codecov の出来事は、開発者ツールの経済性と同様に、セキュリティ自動化にも属する。自動化は手動リスクを減らすことを目的としている。しかし、自動化は信頼の前提を隠すこともできる。YAML ファイルが何年も前にコピーされた可能性がある。アップローダーコマンドが数十のリポジトリで実行される可能性がある。組織レベルのシークレットが、プロジェクトごとにスコープするよりも簡単だったために、すべてのジョブに注入される可能性がある。ローテーションされたトークンは、所有権が不明確な場合にパイプラインを壊す可能性がある。インシデントは、チームがバックグラウンドインフラとなっていた自動化を監査することを余儀なくさせた。

顧客の証拠には、CI シークレットインベントリ、ジョブレベルの権限レビュー、トークンローテーションログ、監査ログレビュー、サードパーティのアクションまたはスクリプトの依存関係マップが含まれるべきである。組織が特定の期間に特定のアップローダーを使用したリポジトリを特定できない場合、露出の範囲を自信を持って判断できない。どのシークレットが存在したかを特定できない場合、インテリジェントにローテーションできない。トークンが露出後に使用されたかどうかを判断できない場合、確認された悪用と予防的ローテーションを区別できない。

これが、公開された顧客通知が異なる理由である。一部の組織は、調査後に不正アクセスの証拠はないと報告した。他の組織は、鍵をローテーションしたか、より具体的な露出を開示した。このばらつきは矛盾ではない。Codecov の侵害されたアップローダーが潜在的な流出メカニズムを作り出した一方で、ダウンストリームの結果は各 CI 環境に依存したという事実を反映している。説明責任の記録は、潜在的な露出、確認されたシークレットアクセス、確認された悪用、顧客データへの影響を別々のカテゴリに保持しなければならない。

証拠の境界と過剰主張のない規律

公開証拠は強力な結論を支持するが、無制限の主張は支持しない。Codecov の Bash uploader が許可なく改ざんされ、その改ざんにより CI 環境から環境変数や Git リモート情報がエクスポートされる可能性があったこと、該当期間は 2021 年 1 月 31 日に始まり 4 月 1 日の修復で終了したこと、顧客のチェックサム不一致が問題の検出に役立ったこと、公開 Docker イメージレイヤーがアップローダーを改ざんするために使用された認証情報を露出させたこと、Codecov が影響を受けるユーザーに認証情報のローテーションを推奨したことを支持する。一部の顧客が自らの修復または露出を公開したことも支持する。

公開証拠は、すべての Codecov 顧客が機密シークレットを漏洩した、すべての露出したシークレットが使用された、すべてのダウンストリームインシデントが Codecov によって引き起こされた、または Codecov が開示前に完全な影響を知っていたと主張するものではない。完全な影響を受けた顧客リスト、完全な攻撃者インフラログ、すべての法執行機関の調査結果、すべてのフォレンジックレポート、または取得されたすべての顧客環境変数は明らかにしていない。真剣な説明責任ファイルは、これらの未知数を疑いで埋めるのではなく、名前を挙げるべきである。

潜在的な露出と確認された悪用の違いは、顧客とダウンストリームユーザーにとって重要である。Codecov のセキュリティアップデートは、アップローダーが利用可能だった場合に影響を受ける可能性のある認証情報、トークン、キー、サービス、データストア、アプリケーションコード、Git リモート情報について語っていた。その可能性は、広範なローテーションガイダンスを正当化するのに十分重要だった。しかし、可能性は後のアクセスの証明と同じではない。顧客インシデント通知が必要なのは、各顧客が一般的な露出経路を自身の環境に適用する必要があったからである。

開示のタイミングは別の境界である。Codecov は、4 月 1 日にイベントを発見した後、4 月 15 日に公開開示を行った。同社は、フォレンジック専門家と調査し、当局と調整していたと説明した。顧客は依然として、対象を絞った早期の警告が可能だったかどうか、リスクの高い露出のある顧客にもっと早く通知すべきだったかどうか、4 月 29 日の追加情報が十分迅速に届いたかどうかを問うことができる。これらは正当な説明責任の質問である。これらは、より多くの証拠なしに悪意を証明するものではない。

この記事はまた、チェックサム検証を責任の完全な移転として扱うべきではない。Codecov は SHASUM 検証を文書化しており、その管理策を使用した顧客が問題を検出した。その事実は、オプションの手順を実装していなかったすべての顧客が過失であったことを意味するわけではない。製品の一般的な使用パターンがライブのリモートスクリプトを取得することであった場合、プロバイダーは多くの顧客が簡単な経路をたどるリスクを負わなければならなかった。統合の摩擦が少なければ少ないほど、プロバイダーはデフォルトの経路に整合性チェックを組み込む責任が大きくなる。

耐久性のある説明責任テストは、修復された信頼の証明である

耐久性のある説明責任テストは、Codecov とその顧客がインシデントを修復された信頼の証明に変換したかどうかである。Codecov にとって、証明とは、盗まれた鍵の失効、内部認証情報のローテーション、露出したイメージレイヤーシークレットの除去、Docker イメージビルドプロセスの変更、ホストされたスクリプトストレージの監視、検証の文書化、署名され検証可能な代替アップローダーの出荷、インシデント対応の改善を意味した。顧客にとって、証明とは、影響を受けるリポジトリの特定、CI シークレットの列挙、露出した認証情報のローテーション、ダウンストリームログのレビュー、ジョブ権限の絞り込み、サードパーティツールの検証の採用を意味した。

重要な修復の質問は、配布のデフォルトである。顧客が依然として組み込み検証なしに可変コードを頻繁に取得して実行する場合、同じクラスのリスクが残る。アップローダーが署名され、バージョン管理され、固定され、チェックサムされ、監視されている場合、リスクは低減される。CI ジョブがカバレッジアップロードをデプロイ権限から分離する場合、将来のアップローダー侵害が盗むものは少なくなる。シークレットマネージャーが長期有効なトークンの代わりに短期有効な認証情報を発行する場合、緊急ローテーションが容易になる。監査ログが十分な期間保持されている場合、顧客は予防策と確認された悪用を区別できる。

調達およびガバナンスチームも、このケースから学ぶべきである。CI で実行される開発者ツールは、無害な可観測性アドオンではない。それは、高価値のシークレットを含む可能性のある自動化環境内でのコード実行である。ベンダーレビューでは、アップローダーやアクションがどのように配布されるか、アーティファクトが署名されているか、侵害がどのように検出されるか、顧客にどのように通知されるか、影響を受けるリポジトリを特定するためにベンダーが提供できるテレメトリ、ベンダーが公開ビルドアーティファクトに署名鍵を保存または露出しない方法を尋ねるべきである。

インシデントはまた、「セキュリティ自動化」の意味を変えた。自動化は自動化されているから安全ではない。自動化は、権限が制限され、入力が検証可能で、アーティファクトが再現可能で、ログが監査可能で、迅速な失効が可能な場合に安全である。Codecov の Bash uploader 侵害は、小さな自動化ステップが、シークレットが存在する場所ならどこでも実行される場合、大きな信頼境界になる可能性があることを示した。

最後の教訓は実用的である。カバレッジデータは重要だが、カバレッジアップロードは企業が所有するすべての認証情報と同じ部屋を共有すべきではない。開発者テレメトリプロバイダーは、顧客に実行を依頼するコードの整合性を証明しなければならない。顧客は、サードパーティツールが必要なものだけを見るように CI を設計しなければならない。どちらかが証拠なしに利便性に依存する場合、その代償は緊急のシークレットローテーション、顧客通知、サプライチェーンの不確実性として現れる。Codecov はその代償を見えるようにした。

アップローダーは小さかったが、その実行時コンテキストは大きかった

Codecov インシデントが重要であり続ける理由の一つは、侵害されたオブジェクトが運用上小さかったことである。それは完全なソースコードホスト、クラウドコンソール、アイデンティティプロバイダー、パッケージレジストリではなかった。それはカバレッジアップローダーだった。しかし、アップローダーの実行時コンテキストは、CI ジョブが多くのシステムから同時に権限を集めることが多いため、大きくなる可能性がある。テストジョブは、プライベートリポジトリのクローン、依存関係のダウンロード、内部パッケージミラーへのアクセス、テスト認証情報の復号、クラウドサービスの起動、レポートの公開、カバレッジプラットフォームへの認証、後のデプロイステップのトリガーを行うことができる。同じ環境変数がジョブ全体で可視である場合、最終的なレポートスクリプトは他の目的で作成されたアクセスを継承する。

そのため、CI における最小権限は、組織レベルだけでなく、ジョブとステップレベルで実装されなければならない。デプロイに適したシークレットは、カバレッジのみのジョブに注入されるべきではない。パッケージ公開トークンは、カバレッジをアップロードする単体テストステップ中に利用可能であるべきではない。統合テストに使用されるクラウド認証情報は、短期有効でテストリソースにスコープされるべきである。リポジトリトークンは最小限の権限を持つべきである。保護されたブランチのシークレットは、信頼されていないプルリクエストコンテキストに露出されるべきではない。Codecov の侵害はこれらのルールを発明したわけではないが、それらを実施する具体的な理由を提供した。

インシデントはまた、シークレットマスキングだけでは不十分である理由を示している。CI プラットフォームはしばしばログ内のシークレットをマスクするが、これは有用であるが、マスキングはプロセスが環境変数を読み取って他の場所に送信することを止めない。マスキングはログの人間の読者を保護する。高権限のシークレットを低権限のシークレットに変換するわけではない。サードパーティのスクリプトがシークレットと同じプロセスコンテキストで実行される場合、管理はすでにログ内の機密性からコード内の信頼に移行している。これははるかに強い前提である。

より強力な設計は、カバレッジアップロードを制約されたステージに分離する。そのステージは、カバレッジファイルとカバレッジサービスへの認証に必要なトークンのみを受け取る。固定されたアップローダーバージョンまたは署名された検証済みバイナリを実行する。デプロイ認証情報、本番クラウドキー、パッケージ公開トークン、長期有効な個人用アクセストークン、無関係なジョブ出力へのアクセスは持たない。アップローダーが後日侵害された場合、攻撃者は狭い環境を見る。インシデントは、企業全体のシークレットローテーションイベントではなく、ベンダーの整合性問題となる。

この設計は調査にも役立つ。侵害されたサードパーティツールが狭い環境を持つ場合、対応者は露出の質問に迅速に答えることができる。どのトークンが存在したか、どのシステムに到達したか、ローテーションされたか、どのログを確認すべきかがわかる。ジョブが多くの継承されたシークレットを持つ場合、対応者は時間的プレッシャーの下で広範なグラフを再構築しなければならない。Codecov インシデントの運用コストは、その不確実性に部分的に起因していた。顧客は自身の CI ジョブが何を可視化していたかを発見する必要があった。

検証はデフォルトで、観察可能で、退屈であるべき

Codecov の記録はまた、より広範な原則を示している。ソフトウェア検証はデフォルトで、観察可能で、退屈であるべきである。異常に注意深い一人の顧客がハッシュの不一致に気づくことに依存すべきではない。不一致を発見した顧客は重要な公共サービスを果たしたが、成熟した配布チャネルは、改ざんをすべての消費者に可視化するか、自動的に実行を停止するようにすべきである。つまり、固定されたバージョン、署名されたアーティファクト、独立したチェックサム公開、可能な場合は再現可能または監査可能なビルド、予期しないオブジェクト変更の監視、通常のチームがサプライチェーン専門家にならずに従える明確なドキュメントが必要である。

実用的なバランスがある。開発者ツールは、採用が容易であるために成功する。検証が難しすぎる場合、チームはそれをスキップする。検証がオプションで埋もれている場合、最もセキュリティ意識の高いチームだけがそれを使用する。したがって、プロバイダーは、安全な経路が通常の経路となるようにデフォルトの統合を設計する必要がある。GitHub Action はバージョンと権限を明確に固定するべきである。バイナリアップローダーは、インストール手順によって署名されチェックされるべきである。CI Orb やステップは、その依存関係を可視化せずに、可変のリモートスクリプトを静かにラップすべきではない。ドキュメントは、ハッピーパスのコマンドだけでなく、障害モードを説明すべきである。

観察可能性はプロバイダー側でも重要である。Codecov の事後分析では、関連する Google Cloud Storage アセットの監視を追加したとしている。その管理カテゴリは不可欠である。ホストされたスクリプトまたはバイナリ配布バケットは、コンテンツが予期せず変更された場合、キーが異常なコンテキストから使用された場合、オブジェクトメタデータが変更された場合、またはリリースパスが予期される自動化から逸脱した場合にアラートを生成する必要がある。署名は実行時に顧客を保護する。監視は配布時にプロバイダーを保護する。両方が必要である。

最後に、検証証拠はインシデント後も存続するべきである。侵害後、顧客はどのアーティファクトバージョンが存在したか、いつ変更されたか、どの署名が有効だったか、どの統合経路がどのアーティファクトを取得したか、影響を受けた期間中にどのリポジトリが実行されたかを知る必要がある。これらの質問に答えられないプロバイダーは、顧客に不完全なログから露出を推測させることになる。Codecov 後の最善の修復は、より安全なアップローダーだけではない。顧客が将来のインシデントを迅速にスコープできる配布証拠台帳である。

その台帳は、プロバイダーの責任と顧客の行動の橋渡しである。Codecov はアップローダーの整合性を検証可能にできる。顧客は CI シークレットを絞り込み、依存関係を固定できる。CI プラットフォームは、権限境界、シークレットスコーピング、監査ログをサポートできる。これらの管理策は単独では十分ではない。一緒に、カバレッジアップロードステップを隠れた信頼の前提から制御された自動化境界に変える。

調達は CI ツールを特権コードとして扱うべき

調達の教訓は直接的である。CI で実行されるツールは、ビジネス機能が観察的に聞こえる場合でも、特権コードとしてレビューされるべきである。カバレッジレポート、静的解析、依存関係スキャン、アーティファクトアップロード、リリースノート生成、ドキュメント公開、デプロイ通知はすべて、シークレットを保持する環境で実行される可能性がある。ベンダーが顧客データを保存するかどうかのみを尋ねるベンダーアンケートは、より重要な質問を逃している。ベンダーは顧客にどのようなコードの実行を依頼するか、そのコードはどこから来るか、どのように検証されるか、実行中にどのような権限を観察できるか。

有用なレビューでは、ベンダーが署名済みリリースを公開しているか、顧客が不変のバージョンを固定できるか、ホストされたスクリプトが予期しない変更について監視されているか、配布キーが公開ビルドアーティファクトから分離されているか、インシデント通知が影響を受ける統合経路を特定できるか、ベンダーが露出をスコープするために十分なテレメトリを提供できるかを尋ねるべきである。また、顧客が CI ステージを分離してベンダーツールが必要な権限のみを受け取るようにしているかも尋ねるべきである。答えは、部分的に契約、部分的にアーキテクチャ、部分的に運用である。

レビューはまた、インシデントサポートを製品の一部として扱うべきである。CI 統合されたベンダーが侵害を開示する場合、顧客は一般的なブログ投稿以上のものを必要とする。アーティファクトハッシュ、影響を受ける時間枠、統合名、検出方法、推奨されるローテーション順序、既知の誤った前提、自身のリポジトリやトークンが観察されたかどうかを尋ねる方法が必要である。ベンダーは、特に法執行機関や顧客の調査が進行中の間は、すべてのフォレンジック詳細を開示できないかもしれないが、顧客が迅速に行動できるようにする対応パッケージを準備できる。Codecov インシデントは、侵害された開発者ツールの運用負担が、ベンダーのセキュリティチーム内だけでなく、数百または数千の顧客パイプラインに及ぶことを示した。

そのサポートパッケージは、インシデント前にテストされるべきである。プロバイダーは、どの顧客向けシステムが緊急通知を送信できるか、どのドキュメントページがローテーションガイダンスをホストするか、どのサポートキューが高リスク環境をトリアージするか、どのログが顧客が影響を受けた期間中に統合が実行されたかどうかを特定するのに役立つかを把握しておくべきである。その準備がなければ、開示は第二の障害モードとなる。プロバイダーは技術的インシデントを発見するかもしれないが、顧客は依然として実用的な露出マップを再構築する時間を失う。したがって、説明責任には、アップローダーの改ざん防止だけでなく、顧客の対応の最初の1時間を使用可能にすることも含まれる。

したがって、このケースは単なる侵害された Bash スクリプトに関する歴史的メモではない。自動化の中に位置する開発者ツールを判断するためのテンプレートである。安全な質問はもはや、抽象的に「このベンダーを信頼するか」ではない。安全な質問は、「このベンダーが管理するコードが明日変更された場合、何を読み取り、どの証拠が迅速にそれを示すか」である。Codecov のインシデントは、利便性スクリプトを本番グレードのシークレットの隣で実行させていたすべてのチームに対して、その質問を可視化した。