GitHub はホストキー輪換を契約と管理の説明責任の試金石とした

要約

• GitHub は、自社の GitHub.com RSA SSH ホスト秘密鍵が公開リポジトリに一時的に露出したことを確認し、2023年3月24日05:00 UTC 頃に RSA ホスト鍵を交換したと発表した。また、この鍵によって GitHub のインフラや顧客データにアクセスされることはなく、悪用された形跡もないとしている。主要な告知は、GitHub のセキュリティ声明（https://github.blog/news-insights/company-news/we-updated-our-rsa-ssh-host-key/）である。
• 実際のインシデントは、単なる秘密鍵の露出にとどまらなかった。それは、開発者、CI システム、リリースマネージャー、中小企業に課せられた信頼修復の問題であり、変更された SSH ホスト ID が正当なプロバイダーによるローテーションなのか、傍受の試みなのかを判断しなければならなかった。
• 契約と管理の不一致とは、プラットフォームの利用規約が保証や責任を制限できる一方で、プロバイダーの運用が依然として顧客のビルド、リリース、ソース管理の継続性に対して実質的な権限を行使している点にある。GitHub の規約（https://docs.github.com/en/site-policy/github-terms/github-terms-of-service）は、ローテーション中の運用管理の実態とは異なる形で法的リスクを配分している。
• 説明責任は、各主体が実際に保持していた管理権限に基づく。GitHub はホスト鍵の管理、検知、ローテーション、公式ガイダンス、サポート対象アクションの更新を管理していた。顧客はトラストストアの管理、独立した検証、固定ワークフローの更新、代替通信手段、リリース中断の規律を管理していた。

契約では鍵をローテーションできず、GitHub にはできた

2023年3月の出来事は、顧客リポジトリ、顧客アカウント、GitHub の本番環境が侵害されたわけではないため、過小評価されがちである。また、サーバーホスト鍵の所持は、ユーザー資格情報やプライベートコードのマスターキーの所持とは異なるため、過大評価もされやすい。有用な説明責任の分析は、この両極端の中間にある。プロバイダーが管理する単一の信頼オブジェクトの機密性が失われ、プロバイダーの修復措置が顧客システムに対して、まさに敵対的な変更時に表示されるよう設計された警告と同一のものとして可視化されたのである。

GitHub の告知によれば、旧 RSA SSH ホスト秘密鍵は公開 GitHub リポジトリに一時的に露出し、同社は SSH を介したなりすましや盗聴からユーザーを保護するために措置を講じたという。影響は SSH 経由の Git 操作（RSA 使用時）に限定され、HTTPS Git 操作、ウェブトラフィック、ECDSA および Ed25519 ユーザーは同様の影響を受けなかった。この範囲は重要である。本件は、プライベートリポジトリが GitHub から読み取られた、顧客の SSH 秘密鍵が開示された、あるいは GitHub の内部サービスが全般的に侵害されたという主張を裏付けるものではない。しかし、多くの顧客が SSH 経由でコードを受け入れる前提条件として固定していたサービス ID を、GitHub が交換せざるを得なかったという事実は裏付けている。

契約と管理を巡る問題は、サービス関係から始まる。GitHub の現在の利用規約は、広範なサービスを定義し、サービスが「現状有姿」で提供され、適時性、セキュリティ、中断のないアクセス、エラーのない動作に関する保証に制限があることを免責している。これらの条項は法的配分には有用だが、顧客に GitHub.com のホスト鍵をローテーションする権限を与えるものではない。プライベート鍵が公開された後、小規模なソフトウェア企業が旧鍵を安全に保持し続けることを可能にするものでもない。CI ランナーが、新しい鍵が本物かどうかを独自に知る方法を与えるものでもなかった。法的文言と運用上の権限は、異なる方向を指していた。

このミスマッチは、クラウド依存においてよく見られる。プロバイダーは広範な裁量権を留保し、エクスポージャーを制限する一方で、共有管理を運用できる唯一の主体にもなり得る。顧客は理論上プラットフォームを離脱できるが、緊急ローテーションの瞬間には、調達の検討ではなく、数分での意思決定が必要となる。彼らのビルドシステム、デプロイメントツール、サブモジュール、ベンダー連携、内部ミラーは、しばしば GitHub の SSH エンドポイントが安定した信頼の基盤であることを前提としている。その信頼の基盤自体が変更される場合、顧客は停止するか、別のチャネルで検証するかの二者択一となる。

これは、GitHub がローテーションしたことへの不満ではない。プライベート鍵が漏洩した可能性がある以上、ローテーションは正しい封じ込め措置であった。説明責任のテストは、信頼オブジェクトを管理する組織が、それを公開リポジトリから守る十分な予防的管理を有していたか、露出の経緯を知る十分な検知能力を有していたか、回避可能な混乱を生じさせることなく失効させる十分な対応管理を有していたか、そして顧客が自らを保護する管理そのものを弱めることなく復旧できるだけの情報開示を行ったか、である。

確認された事実と未解明の点

GitHub の公開説明は、5つの事実を確認している。第一に、関与した秘密は、SSH 経由の GitHub.com Git 操作のための RSA SSH ホスト秘密鍵であった。第二に、同社は、それが公開リポジトリに一時的に出現したことを発見した。第三に、GitHub は2023年3月24日05:00 UTC 頃に鍵を交換し、新しい鍵は準備中に02:30 UTC 頃から一時的に見えていたと報告した。第四に、同社は本件が GitHub システムや顧客情報の侵害に起因するものではないと述べた。第五に、GitHub はこの鍵が悪用された形跡はないとした。

これらの声明は証拠の境界を画定する。リポジトリ、人物、ワークフロー、スキャナー、露出期間、閲覧回数、クローン回数、キャッシュ動作、根本原因は特定されていない。悪用がないと結論付けるために使用されたテレメトリも開示されていない。プライベート鍵が、リポジトリへの公開を不可能にすべき方法で生成または保存されていたかどうかも述べられていない。露出が GitHub 自身のシークレットスキャン、従業員の報告、ユーザー報告、研究者、または別の管理策によって検知されたのかも明らかにされていない。

この不在は重要である。なぜなら GitHub は、公開シークレットの露出を防ぐための管理策を販売し、文書化しているからだ。2023年2月、GitHub は公開リポジトリ向けの無料シークレットスキャンアラートを発表した（https://github.blog/news-insights/product-news/secret-scanning-alerts-are-now-available-and-free-for-all-public-repositories/）。2023年5月、ホスト鍵イベントの後、公開リポジトリ向けのより広範な無料プッシュ保護を発表した（https://github.blog/news-insights/product-news/push-protection-is-generally-available-and-free-for-all-public-repositories/）。現在の GitHub ドキュメントには、一般的な秘密鍵パターンがリストされている（https://docs.github.com/en/code-security/reference/secret-security/supported-secret-scanning-patterns）。これらの情報源は管理策の体系を示しているが、2023年3月に特定のホスト鍵をどの管理策が検知、見落とし、またはブロックしたのかを証明するものではない。

したがって、根本原因は限定的に述べられるべきである。引き金は、ホスト秘密鍵の公開リポジトリへの露出であった。根本的な説明責任の問題は、単なる露出ではなく、本番サービス ID が公開可能となることを許した管理体制と、その後ライブ検証に依存せざるを得なかった顧客の復旧経路にある。寄与した条件としては、GitHub SSH の広範な利用、RSA に固定された古いクライアントトラストストア、人間が近くにいない場合にフェイルクローズする自動化、旧アクションコードに固定されたワークフロー、ホスト鍵警告をサプライチェーンのシグナルではなくローカルな煩わしさとして扱うことが多かった顧客のランブックが挙げられる。

公開記録はまた、潜在的な害と観測された害を分けている。旧 RSA ホスト秘密鍵を入手した第三者は、トラフィックを迂回させ、そのクライアントが旧 RSA ID を受け入れる場合に、GitHub になりすますことを試みる可能性がある。これにより、その接続を通じた Git コマンド、プッシュされたオブジェクト、要求されたリポジトリコンテンツの露出、または攻撃者の位置によってはより精巧な欺瞞が可能になる。しかし、この鍵自体はネットワーク上の位置、ユーザー資格情報、GitHub アカウントアクセス、または GitHub の保存リポジトリへのアクセスを提供するものではない。レビューされた情報源は、なりすましインシデントの成功を立証していない。

警告は管理策が機能していた証拠

SSH ホスト鍵の警告は、飾りの障害ではない。RFC 4253（https://datatracker.ietf.org/doc/html/rfc4253）は、トランスポート層でのサーバー認証をユーザー認証から分離している。予期されるサーバーID を記憶するクライアントは、サーバーが異なる鍵を提示した場合に停止するはずである。OpenSSH クライアントマニュアル（https://man.openbsd.org/ssh_config）は、厳密なホストチェックを、変更されたホスト鍵を拒否する設定として説明している。この拒否こそが、攻撃者が顧客と GitHub の間に立ちはだかろうとした場合に必要なものであった。

3月のローテーションは、運用上のパラドックスを生み出した。正当な GitHub の修復が、中間者攻撃と同様の症状を引き起こしたのである。開発者は変更された鍵の警告を見た。CI ランナーはチェックアウトの失敗を見た。デプロイメントジョブは非ゼロの終了コードを見た。マシンは、その変更が合法かどうかを知ることはできなかった。ホスト ID がローカル記録と一致しなくなったことだけを知っていた。これが、顧客データの窃取が確認されていなくとも、本件がリスクと説明責任のシリーズに属する理由である。

GitHub のトラブルシューティングガイダンス（https://docs.github.com/en/authentication/troubleshooting-ssh/error-host-key-verification-failed）は、公式の説明を探し、それが存在しない場合に接続しないようユーザーに指示している。フィンガープリントページ（https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/githubs-ssh-key-fingerprints）は、現在の GitHub SSH フィンガープリントを公開している。REST Meta ドキュメント（https://docs.github.com/en/rest/meta/meta）は、メタエンドポイントが SSH 鍵フィンガープリントとホスト鍵を返し、公開リソースに対して認証なしで使用できると述べている。これらのチャネルは合わせて復旧経路を提供したが、魔法の経路ではなかった。顧客は依然として、HTTPS ドキュメントと API が緊急時に十分信頼できると判断し、SSH 経路で現れた鍵を何でも受け入れるようにスタッフを教育することなく、修正されたトラストエントリーを配布しなければならなかった。

安全でない近道は、ホストチェックを全体的に無効にしたり、独立した検証なしにライブネットワークスキャンから信頼鍵をインポートすることだった。OpenBSD ssh-keyscan マニュアル（https://man.openbsd.org/OpenBSD-7.2/ssh-keyscan.1）は、検証なしにスキャン出力を使用すると傍受に対して脆弱になる可能性があると警告している。この警告は直接当てはまる。ID が争われているまさにその名前に対してスキャンを実行することは、経路が敵対的であれば、攻撃者の応答を真実として記録してしまう可能性がある。

規律ある手順は時間がかかるがより安全である。警告を保持し、提示されたフィンガープリントを認証済みのプロバイダー声明および内部承認情報源と比較し、影響を受ける RSA ホストエントリーのみを該当ホスト名に対して更新し、カナリアフェッチを実行し、その後マネージドクライアントとランナーにロールアウトする。この手順は、信頼の失敗を信頼のバイパスに変えないための代償として、短時間のリリース遅延を受け入れる。

CI が信頼修復をサービス継続に変えた

人間の開発者は通知を読むことができる。CI システムはそうではない。GitHub は具体的に、ssh-key オプション付きの actions/checkout を使用するワークフローが失敗する可能性があると警告し、v2、v3、main といったサポート対象タグを更新中であると述べた。アクションの公開リポジトリ（https://github.com/actions/checkout）は、SSH キーサポートと厳密なホストチェック動作を文書化している。移動タグが一元的に受けることができた同じ修復は、特定のコミット SHA に固定されたジョブには自動的には届かない。

この緊張関係は、ピン留めの欠陥ではない。GitHub 自身のアクション強化ガイダンス（https://docs.github.com/en/code-security/tutorials/secure-your-organization/protect-against-threats）は、サプライチェーンの完全性のためにアクションを不変のコミットに固定することを推奨している。2023年3月、不変のレビューは継続性のトレードオフを生み出した。旧アクションコードを固定した顧客は、サイレントなアクション変更から保護されていたが、埋め込まれた信頼更新を受け取るためには新しいコミットをレビューし採用する必要もあった。移動タグを使用する顧客は、プロバイダーの修正をより早く受け取ることができたが、自身のレビューなしにコードが移動する可能性があるというコストを払っていた。

これがこの出来事の開発者ツール経済である。GitHub は、リポジトリホスティング、コラボレーション、課題追跡、パッケージワークフロー、CI 統合を一元化する。それは、一元化がコストと摩擦を削減するからである。同じ一元化が、プロバイダーによるキーローテーションが一度に多くの顧客を中断させ得ることを意味する。各顧客はローカルにビルド失敗を経験するかもしれないが、原因は共有されたプラットフォーム管理にある。各顧客は独自の known_hosts ファイルを所有し得るが、その中身はプロバイダーが所有する主張である。

中小規模のチームが最も困難な状況に直面する。大企業はエンドポイント管理、CI プラットフォーム所有者、セキュリティエンジニアリング、ベンダー連絡先を有しているかもしれない。5人のソフトウェア事業者は、失敗したデプロイメントを見て、ソーシャルフィードをチェックし、サポートページを検索し、出荷するかどうかを決定しなければならない1人しかいないかもしれない。CISA の中小企業向け ICT サプライチェーンガイダンス（https://www.cisa.gov/resources-tools/resources/reducing-ict-supply-chain-risk-small-and-medium-sized-businesses-fact-sheet）は、小規模な企業が専任のリスクスタッフを欠きながら外部テクノロジープロバイダーに大きく依存していることを認識している。3月の出来事はその依存の典型的な例である。

中小企業は、説明責任を果たすために完璧な代替フォージを必要としない。しかし軽量な計画は必要である。すでにテスト済みの第二の Git トランスポート、重要なコードのためのリポジトリミラーまたはバンドル、プロバイダー通知を受信する2人の担当者、承認されたホストフィンガープリントとソース URL をリストする内部ページ、そしてホスト鍵警告が検証されるまではセキュリティイベントであるというルールである。GitHub のリモート URL ドキュメント（https://docs.github.com/en/get-started/git-basics/managing-remote-repositories?changing-a-remote-repositorys-url=&platform=linux）は、SSH と HTTPS の切り替えが技術的には簡単であることを示している。運用上は、新たなシークレット問題を引き起こさない、スコープされた資格情報、権限、ログが必要である。

バックアップも同様に限定的である。GitHub のリポジトリバックアップガイダンス（https://docs.github.com/en/enterprise-cloud%40latest/repositories/archiving-a-github-repository/backing-up-a-repository）と Git のバンドルドキュメント（https://git-scm.com/docs/git-bundle.html）は Git 履歴を保存できるが、自動的に課題、プルリクエスト、ワークフローシークレット、パッケージレジストリ、アクセスレビュー、リリース承認を保存するものではない。ソースコードを保護するがリリース状態を失うバックアップ計画は、依然としてビジネスのクリーンな復旧を不可能にする可能性がある。

契約条項はエクスポージャーを説明するが管理は説明しない

現在の GitHub 利用規約は、多くの組織が重要インフラとして扱うサービスの法的表面を示しているため関連性がある。規約はサービスを広範に定義し、プライベートリポジトリのコンテンツを明示されたアクセス目的に従って機密として扱い、電子的通信を規定し、通常の条項コミュニケーションには電話サポートがないことを述べ、広範な保証を否認している。これらの条項は商業的に合理的であり得る。また、契約文言が運用上の説明責任の代替にならない理由も示している。

GitHub のプライベートリポジトリ条項（https://docs.github.com/en/site-policy/github-terms/github-terms-of-service）には、GitHub がプライベートリポジトリのコンテンツを機密として扱い、セキュリティ、サポート、整合性、法的義務、または同意などの特定の目的でアクセスできるとある。この文言は、サービスの整合性に対するプロバイダー権限を認めている。ホストキーローテーションは、接続層で同様の権限を行使する。顧客は自身のコンテンツを所有しアクセスを設定できるが、SSH 経由で GitHub.com を認証するプラットフォーム ID を所有しているわけではない。

問題は、GitHub がローテーションする契約上の権利を持っていたかどうかではない。ほぼ確実にそれを必要としていた。問題は、契約上のリスク配分が実際の管理と一致していたかどうかである。顧客はトラストストアの更新、ビルドの再実行、失敗の説明、安全でない回避策の防止という下流のコストを負った。GitHub は、新しいフィンガープリント、影響を受ける鍵タイプ、ローテーション理由、露出境界、サポート対象アクション更新のステータス、悪用に関する確信度など、安全に行うために必要な事実を管理していた。一方の当事者が証拠を管理し、他方の当事者が復旧の労力を負う場合、開示の質は広報ではなく管理となる。

GitHub Status（https://www.githubstatus.com/）は運用インシデントとコンポーネントの健全性を伝達できるが、ホストキーイベントは認証されたセキュリティガイダンスも必要とする。一般的なグリーンのステータスページは、新しい SSH フィンガープリントが合法かどうかを CI ジョブに伝えることはできない。プロバイダー通知、フィンガープリントページ、API エンドポイント、サポート応答、ステータスコンポーネントは内部的に一貫していなければならない。一方が鍵は交換されたと言い、他方が沈黙または古いままなら、顧客はより長く停止するか、安全でない決定を下す可能性がある。

公開通知はいくつかの点で適切だった。影響を受けたアルゴリズムを特定し、正確なローテーション時刻を与え、新しい鍵の早期出現を認め、新しいフィンガープリントと完全な公開鍵を提供し、HTTPS および RSA SSH 以外のホスト鍵アルゴリズムを分離し、Actions ユーザーに警告し、旧鍵では GitHub インフラや顧客データにアクセスできないことを説明した。これらは有用な運用事実である。欠落している事実は他にある。正確な露出期間、検知経路、取得証拠、テレメトリ限界、管理体制の変更、そして同種の公開がより起こりにくくなったという後の保証である。

したがって、説明責任のレンズは、GitHub に完全な可用性やゼロエラーを約束するよう求めるものではない。プラットフォームに対し、自らが保持する管理に比例した証拠を提供するよう求めるものである。契約はリスクが限定的であると言うことができる。露出したプライベートホスト鍵を未露出にすることはできない。変更されたホスト鍵を自己認証させることもできない。GitHub だけが公表していない事実を、顧客が検証することを可能にすることもできない。

実際の管理による検知、対応、復旧の失敗

引き金は RSA ホスト秘密鍵の露出だった。根本的問題は鍵の管理体制と緊急時の信頼修復であった。寄与条件には、共有プラットフォーム ID、新しいホスト鍵よりも RSA を使用する顧客の不均一な利用、自動化における隠れたトラストストア、Actions におけるピン留めのトレードオフ、そして検証済みローテーション経路を欠くことが多かった顧客ランブックが含まれる。

検知の失敗は、GitHub が検知手段を開示しなかったため、公開記録から詳細には評価できない。本件は、管理策が正しく機能して発見された可能性がある。人によって発見された可能性がある。遅延の後に発見された可能性もある。正しい公開の結論は、検知が失敗したということではなく、検知証拠が外部から検証不可能であるということである。製品にシークレット検出を含むプロバイダーにとって、その証拠の欠如は重要である。なぜなら、顧客はその経路が説明されて初めて学ぶことができるからである。

対応は部分的に強力だった。露出した鍵は、公開通知の後、速やかに無効化された。交換は RSA に限定され、変更されていない ECDSA および Ed25519 鍵によって影響範囲は縮小された。GitHub は権威あるフィンガープリントと更新手順を提供した。また、サポート対象の actions/checkout タグも更新した。対応の弱点は、明示された05:00 UTC の交換前に02:30 UTC 頃に新しい鍵が一時的に出現したことで生じた、不可避の混乱だった。これは無害な準備だったかもしれないが、顧客にとっては最終的な切り替え前に ID が変更されたように見えた。GitHub はそれを認めたが、公開記録はメカニズムを説明していない。

復旧は顧客に分散された。ワークステーション、ランナー、コンテナ、ベースイメージ、アプライアンス、ビルドサービス、デプロイメントシステムはすべて、ローカルのトラストを更新しなければならなかった。GitHub は自社のサポート対象アクションタグを更新できたが、固定コミットや外部 CI を持つ顧客は行動する必要があった。それ自体は不公平ではない。それは運用上の責任共有境界である。不公平になるのは、プロバイダーのガイダンスが不完全である場合、顧客がそれを受け取る実際的な方法がない場合、または顧客契約がプラットフォーム ID イベント中には存在しない自律性を暗示している場合だけである。

最も示唆的な指標は、プロバイダーのローテーションまでの時間ではなく、検証された復旧までの時間だろう。主要な顧客カテゴリが、チェックを無効にすることなく厳密な SSH トラストを回復するのにどれだけの時間を要したか？安全でない回避策を含むサポートチケットはどれだけあったか？固定コードを含む失敗した Actions 実行はどれだけあったか？通知後も旧 RSA キーを使用した顧客はどれだけいたか？本記事のためにレビューされた公開記録は、これらの指標を提供していない。それらの欠如は、復旧が単に完了しただけなのか、測定可能に改善されたのかを述べる能力を制限する。

記録と可読性に関するタイポグラフィの注記

フォレンジックは単なる事実の集積ではない。それは提示の問題でもある。顧客は、安全な行動がプレッシャーの下で明確になるように、警告、フィンガープリント、日付、注意事項が配置されることを必要とする。以下のタイポグラフィの注記は、通知の形式が読者がシグナルを保持するか消去するかを変え得るため、この公開証拠群に属する。

タイポグラフィとは、書き言葉を読みやすく、可読性が高く、視覚的に魅力的にするために文字を配置する技術である。書体、ポイントサイズ、行長、行間、文字間隔の選択が含まれる。

• タイポグラフィは、15世紀にヨハネス・グーテンベルクによる可動式活字の発明に端を発する。
• 主要な要素には、フォント選択、カーニング、トラッキング、リーディングが含まれる。
• 優れたタイポグラフィは可読性を高め、デザインにおける雰囲気やトーンを伝える。

ホストキーローテーションに適用すると、実践的なポイントはシンプルだ。フィンガープリント、影響を受けるアルゴリズム、時間枠、安全なコマンドパスは、文脈や安心感の言葉から視覚的に区別されなければならない。マーケティングレイアウトや曖昧なステータスの散文の中に鍵素材を埋もれさせる通知は、顧客が間違ったエントリーを貼り付けたり、検証をスキップしたりする可能性を高める。同じ規律が内部ランブックにも適用される。リリースプレッシャーの下にある開発者は、背景説明の前に、停止条件、承認された情報源、正確なフィンガープリント、レビュアーのルールを見るべきである。

スローガンではなく管理による説明責任

GitHub が最大の予防的管理シェアを持っていた。ホスト秘密鍵の生成、保存、使用、廃止を管理していた。その鍵が出現したリポジトリサービスを管理していた。公開記録がどれが適用されたかを示していないとしても、秘密鍵を検出またはブロックできる可能性のある製品セキュリティ機能を管理していた。ローテーション計画、権威ある告知、フィンガープリントページ、API データ、サポートガイダンス、ファーストパーティのアクション更新を管理していた。封じ込め後に公開する詳細の量も管理していた。

GitHub はまた、正当化される緊急時の裁量を持っていた。顧客の摩擦を避けるために、コピーされた可能性のあるプライベートホスト鍵をサービスに残すことは、なりすまし経路を残すことになる。正しい批判は、プラットフォームが過度に攻撃的に動いたということではない。緊急時の権限は、準備態勢の証拠と組み合わせるべきだという点である。つまり、リハーサルされたローテーション、検証された公開管理策、一貫したメッセージング、そして持続的な変更のインシデント後説明である。

顧客は、自身のトラスト消費を管理していた。SSH を使うか HTTPS を使うか、RSA ホスト鍵を固定するか、代替ホスト鍵アルゴリズムを学ぶか、known-hosts を一元管理するか、イメージに鍵を焼き付けるか、アクションコミットを固定するか、ミラーを維持するか、開発者が厳密なチェックをバイパスすることを許可されるかを決定した。これらの選択は、プロバイダーの鍵露出を正当化するものではない。それらは、プロバイダー側のイベントがどれだけ顧客のダウンタイムや安全でない復旧につながるかを決定する。

CI メンテナーや統合ベンダーは、埋め込まれたトラストマテリアルと更新チャネルを管理していた。利便性のためにホスト鍵を隠すツールは、それらを安全に更新する方法を公開すべきである。ライブスキャンに依存するツールは、検証についてユーザーに警告すべきである。完全性のために依存関係を固定するツールは、安全なピン留めが古いピン留めにならないように、緊急レビューを十分高速に行えるようにすべきである。

調達および法務チームは、より静かな境界を管理していた。彼らはしばしば、ベンダーだけが行使可能な管理策をマッピングすることなく、プラットフォーム条項を受け入れていた。より良い契約レビューの質問は、損害賠償が制限されているかどうかだけではない。信頼イベント中にプロバイダーがどの運用事実を開示するか、顧客が緊急通知をどのように認証するか、セキュリティ上重要なローテーションにサポート経路が利用可能か、修復後にどのような証拠が提供されるか、である。

キーを使用した場合、攻撃者はなりすましや傍受の責任を問われる。公開記録はそのような使用を立証していない。ネットワーク事業者、DNS プロバイダー、その他のトラストチャネル参加者は、仮説上の悪用では重要だが、レビューされた事実は本件におけるそれらの失敗を示していない。

検証可能な修復とはどのようなものか

この出来事の後に成熟した管理記録は、いかなるホスト鍵も二度と露出しないという約束ではない。それは、障害の種類が再発しにくくなり、より安全に回復できるようになったという証拠だろう。

管理体制について、GitHub は、本番ホスト秘密鍵が、文書化された非常時経路以外では、通常のリポジトリ、開発者ワークステーション、ログ、テストフィクスチャ、ビルドアーティファクトに入り込めないことを示せるべきである。その証拠には、鍵生成管理、アクセスログ、エクスポート制限、スキャン網羅度、自動失効トリガーが含まれうる。部外者はすべての機密詳細を必要としない。修復が1つの鍵の交換に限定されなかったことを知るのに十分な保証を必要とする。

検知について、GitHub は、公開からアラート、アラートから封じ込め、封じ込めからローテーション決定、ローテーション決定から顧客通知までの時間を示せるべきである。また、どの種類の取得証拠がレビューされ、どの可視性の限界が残ったかを述べられるべきである。「悪用の形跡はない」は意味のある会社声明だが、公開された検知基盤と同一ではない。

対応について、GitHub は通常の訓練としてホストキーローテーションをテストすべきである。OpenSSH は、既に信頼された鍵での認証後の UpdateHostKeys などのメカニズム（https://man.openbsd.org/ssh_config）をサポートしているが、緊急時の露出は重複時間を制限する。プロバイダーは依然として、顧客通知、API 更新、ステータスメッセージング、ファーストパーティ統合、サポートスクリプトのリハーサルを行うことができる。クリーンな訓練は、顧客がチェックを無効にせずに更新できるかどうかを測定するだろう。

顧客にとって、検証可能な修復とは、すべての GitHub トラストマテリアルと SSH を使用するすべてのワークフローのインベントリを保持することを意味する。どのジョブが SSH 付きの actions/checkout を使用し、どれが固定され、どのベースイメージが known-hosts ファイルを含み、どのリリース経路が HTTPS に切り替え可能かを知ることを意味する。ホスト鍵障害を単なるビルドノイズとしてではなく、セキュリティイベントとしてログに記録することを意味する。トラストファイルを編集する前に証拠を保持することを意味する。

中小企業にとって、修復はシンプルであるべきだ。短いランブック、テスト済みの HTTPS リモート、重要なリポジトリのミラー、ホスト鍵変更のための第2レビューア、購読済みのセキュリティ通知が、多くの企業にとって十分かもしれない。中心的なポイントは、GitHub への依存を排除することではない。プロバイダーの信頼修復が即興を強いることがないように、依存を十分に可視化することである。

小規模顧客の障害連鎖

この出来事の小規模顧客版は、公的な提出物がほとんどなく、統合されたインシデントカウントも存在しないため、最も可視化されにくい。開発者が失敗したパイプラインに到着する。エラーは変更されたホスト鍵について言及している。リリースはすでに遅れている。セキュリティ通知は利用可能かもしれないが、それを読んでいる人はフィンガープリントを比較し、トラストファイルを更新し、ジョブを再実行し、顧客やマネージャーに遅延を説明しなければならない。組織にランブックがなければ、安全な経路は、古いフォーラムの回答からコピーされた1行の回避策と競合する。

ここに、開発者ツール経済が説明責任の証拠となる理由がある。GitHub は、リポジトリホスティング、コラボレーションワークフロー、プルリクエスト、課題、パッケージ、ホスト型自動化を一箇所で提供することで、小規模チームの運用コストを削減する。小規模企業は、そのプラットフォームに依存することで、何年分ものインフラ作業を節約できるかもしれない。その節約のコストは、プロバイダーの信頼変更がローカルの運用イベントとして到来することである。企業はホストキーローテーションのスケジュールを交渉しない。リアクションするのである。

そのような企業にとっての第一の管理策は、事前決定の明確化である。ホスト鍵の警告は、リリースを通過させたいという最も強い欲求を持つ人物に割り当てられるべきではない。事前に選定されたセキュリティまたはリリース所有者に割り当てられるべきであり、たとえその所有者が2人のエンジニアのうちの1人であってもである。組織は、正確なプロバイダーフィンガープリント情報源、内部承認ルール、ロールバック計画を短い記録に保持すべきである。ポイントは形式的なことではない。プレッシャーの下での判断の即興を排除することである。

第二の管理策は、復旧の分割である。一人が HTTPS チャネルを通じてプロバイダー通知とフィンガープリントを検証する。もう一人が構成管理またはレビュー済みコミットを通じて変更を適用する。オンコールに2人に満たないチームの場合、定義された緊急パッチを除き、第2のレビューアが利用可能になるまでリリースを遅延させるのが代替策である。これは、2人が常により正確だからではない。検証と適用を分離する行為が、最も一般的な安全でないショートカットを捕捉するからである。それは、争われている SSH 経路によって提示された鍵を信頼することである。

第三の管理策は、トランスポートの規律である。SSH ホストの信頼が修復中の時、HTTPS へのフォールバックは配信を維持できるが、スコープされた資格情報で事前設定されていなければならない。広範な個人用トークンを使用したり、ビルドログに資格情報を露出させたりする急ぎの切り替えは、一つのインシデントを別のインシデントと交換する。フォールバックは、特定のリポジトリをフェッチまたはプッシュするのに十分でそれ以上の権限を持たずに、プロバイダーイベント前にテストされるべきである。

第四の管理策は、証拠の保持である。失敗した CI ログ、ホスト鍵警告、タイムスタンプは、編集前に保存されるべきである。顧客が後に傍受を疑う場合、または失敗したデプロイメントがプロバイダーのローテーションによって引き起こされたことを証明する必要がある場合、消去されたローカル証拠は答えを弱める。GitHub は成功した Git 活動のサーバー側記録を持つかもしれないが、拒否された SSH ハンドシェイクは Git イベントとしてサービスに到達しない可能性がある。クライアントログは記録の一部である。

これらの管理策は控えめである。エンタープライズセキュリティオペレーションセンターを必要としない。ホスト ID が本番設定であることを認識するだけでよい。その認識が生まれれば、キーローテーションのコストは、作業をグリーンにするためにセキュリティ管理を無効にする危機としてではなく、小さな変更として管理できる。

調達はローテーション証拠を求めるべき

調達はしばしば、クラウドおよび開発者ツールベンダーに、アップタイム数値、データ処理条項、セキュリティ認証、インシデント通知条項を求める。2023年3月の出来事は、ソフトウェアサプライチェーンプラットフォームに対する、より具体的な証拠要求を示唆している。顧客の信頼オブジェクトがどのようにローテーションされ、顧客がその交換をどのように認証するかを示すことである。

この要求は、秘密の内部設計を求めるべきではない。本番プライベート鍵がエクスポート制限されているか、緊急ローテーションがリハーサルされているか、認証された鍵素材にどの顧客チャネルが使われるか、どのファーストパーティ統合がホスト ID を埋め込んでいるか、ステータスとセキュリティ通知がどのように一貫性を保たれているか、顧客が変更された管理策のインシデント後説明を受け取るか、を問うべきである。これらは風変わりな質問ではない。それらはベンダー権限と顧客依存の間の運用インターフェースである。

契約文言はまた、顧客がプラットフォーム鍵を管理しているふりをせずに、顧客の義務を明記することができる。バランスの取れた条項は、プロバイダーが認証された交換素材と影響を受けるサービス範囲を速やかに公開し、一方で顧客が自身のトラストストアを更新し厳密なチェックを維持するプロセスを維持する、と述べることができる。これは責任紛争を排除しない。双方に訓練された経路を与える。

同じ証拠が内部リスク登録簿に含まれる。コードを他にクローンできるから GitHub は重要ではないと言う企業は、その主張をテストすべきである。リポジトリ、保護されたブランチルール、リリースアーティファクト、ワークフロー定義、デプロイメントキー、課題履歴、パッケージ参照、チーム権限を、ビジネスにとって十分な速さで他に復元できるか？できなければ、GitHub は、契約が広範な可用性保証を否認していても、トラストローテーション計画を正当化するほど重要である。

そのテストは通知チャネルそのものも含むべきである。ホスト鍵変更を承認できる唯一の人々が、同じプラットフォームイベントに依存するチャットシステム、シングルサインオンフロー、またはデプロイメントダッシュボードを通じてしか到達できない場合、復旧計画は循環的である。緊急信頼変更は、認証された情報源、オフラインで読めるランブック、開発者ツールが劣化している時にも存在するレビュアー経路を必要とする。

最終評価

確認された事象は中程度の影響、高い確信度で評価される。プライベート RSA ホスト鍵の露出は、まだその鍵を信頼し、ネットワーク経路が迂回可能な SSH クライアントにとって、信憑性のあるなりすましリスクを生み出した。GitHub のローテーションは慎重で、範囲が限定され、公的に文書化されていた。レビューされた記録は、顧客リポジトリの窃取、GitHub インフラの侵害、ユーザープライベート鍵の露出、または旧ホスト鍵の確認された悪用を示していない。

説明責任の所見は、インシデントの規模よりも鋭い。GitHub の共有ホスト ID に対する運用管理は、顧客が通常の条件で購入できる実質的な保護を超えていた。顧客は契約を読むことができたが、鍵管理の経路を検査することはできなかった。免責条項を受け入れることはできたが、ホスト ID が変更された場合にはビルドを停止しなければならなかった。リポジトリを所有することはできたが、プロバイダー側の鍵イベントが、彼らのリリースシステムがソースを信頼するかどうかを決定し得た。

これが契約と管理のミスマッチである。法的文書はサービス関係を記述し、インシデントは運用上の依存を明らかにした。したがって、説明責任は実質的な管理の点に帰属する。GitHub は管理体制、迅速なローテーション、正確な通知、修復証拠を負っていた。顧客は厳格な検証、トラストインベントリ、継続性計画を負っていた。これらの義務の違いは抽象的ではない。2023年3月24日05:00 UTC、それは安全な一時停止と安全でない貼り付けの違いだった。