GitHub の正しいセキュリティ対応が攻撃に見えた朝

概要

出来事：GitHub は2023年3月20日の週に、GitHub.com の RSA SSH ホスト秘密鍵が公開 GitHub リポジトリに一時的に露出したことを発見した。同社は3月24日05:00 UTC 頃に鍵を交換した。それに先立ち、約02:30 UTC から新しい鍵が短時間準備的に出現していた。
境界：そのホスト鍵を保有すれば、攻撃者はトラフィックを迂回させ、古い RSA ID を依然として信頼する SSH クライアントに対して GitHub を偽装することができる可能性があった。鍵自体は GitHub のインフラ、顧客リポジトリ、顧客アカウント、またはユーザーの秘密 SSH 鍵へのアクセスを提供するものではなかった。GitHub は悪用されたと信じる理由はないと報告し、公開は GitHub システムや顧客情報の侵害によるものではないとした。
運用上のパラドックス：厳格な SSH クライアントは、GitHub の ID が変更されたときに停止することになっていた。その保護機能の失敗は、誰かが新しい鍵を検証して配布するまで、開発者のプッシュ、自動チェックアウト、サブモジュールの取得、ビルド、デプロイを中断させる可能性があった。古い鍵を盲目的に削除するか、チェックを無効にすると、実際の攻撃を特定する可能性のある証拠を破棄して可用性を回復することになる。
説明責任の発見：GitHub は、ホスト秘密鍵の管理、公開の防止と検出、ローテーションの実行、公式なコミュニケーション、サポートされているactions/checkoutタグの更新を管理していた。顧客は、トラストストアの在庫、独立した検証、自動更新パス、フォールバックトランスポート、継続性計画を管理していた。公開記録は、中程度の影響を与えるセキュリティおよび継続性イベントを支持するが、顧客コードが盗まれたり改ざんされたりしたという発見は支持しない。

02:30 UTC: 正しい新しい ID が早すぎて現れる

GitHub の報告で最も明らかになる部分は、偶発的な公開そのものではない。それは、正当なインフラが攻撃下にあるインフラのように振る舞った間隔である。

GitHub の最高セキュリティ責任者は3月23日に同社のホスト鍵交換通知を公開した。通知によると、新しい RSA 鍵は3月24日の02:30 UTC 頃から、GitHub が変更を準備している間、短時間提示された。05:00 UTC 頃、GitHub は GitHub.com の Git 操作に使用されていた古い RSA SSH ホスト鍵を交換した。同社は変更が次の30分間で伝播することを予想していた。

古い RSA ホスト ID を固定していたクライアントにとっては、どちらの提示も深刻な警告を生じさせる可能性があった：リモート ID が変更された、誰かが接続を傍受している可能性がある、厳格なチェックが拒否した。メッセージは、原因がプロバイダーの緊急メンテナンス、オペレーターのミス、トラストストアの破損、DNS またはルーティングの迂回、または盗まれたホスト鍵を使用した攻撃者によるものかどうかを示さなかった。それはありえなかった。この制御のポイントは、説明のつかない ID 変更を停止に変換することだった。

したがって GitHub はユーザーに、時間的プレッシャーの下で重要な区別をするよう求めていた。古い鍵は安全ではなくなり、廃止する必要があった。新しい鍵は定義上、見慣れないものだった。修復の目に見える症状は、脅威の目に見える症状でもあった。パッチを出荷したい開発者、または人間が立ち会わずにデプロイすることが期待されるビルドランナーは、争点の SSH 接続からは得られない第三の事実を必要としていた：GitHub の新しい鍵がどうあるべきかについての独立して認証された声明である。

それが、GitHub が顧客データの侵害を報告しなかったにもかかわらず、このイベントが説明責任の記録に属する理由である。クラウドサービスは、内部システムを稼働させ続ける責任だけでなく、信頼素材、クライアントの動作、更新義務、緊急時の意思決定を顧客環境に輸出する。このケースでは、サービスは HTTPS を介して利用可能であり、GitHub の ECDSA および Ed25519 ホスト鍵は変更されていなかった。しかし、プロバイダー側の1つの秘密が、グローバルな顧客側の検証タスクを生み出した。

最初の反事実は単純である：警告が現れなかったと仮定しよう。自動化ジョブは変更されたサーバーID を通過して続行され、組織は偽装者を介してコードを送受信したかどうかを決して知らないかもしれない。失敗したジョブは安全な結果だった。継続性の問題は、SSH が慎重すぎたことではなかった。多くの組織が、慎重な拒否を検証済みの回復に変える準備された方法を持っていなかったことである。

何が露出し、何が露出しなかったか

SSH は異なる主張に対して異なる鍵を使用する。それらを混同すると、イベントが証拠が許容するよりもはるかに悪いか、はるかに小さいかのように聞こえる。

ユーザー鍵またはデプロイ鍵は通常、クライアントを GitHub に証明する：保持者はアカウントまたはリポジトリに関連付けられた秘密鍵の管理を実証する。ホスト鍵はサーバーをクライアントに証明する：GitHub は鍵交換素材に署名し、クライアントが相手方が GitHub の期待されるサーバーID を管理していると判断できるようにする。SSH トランスポート仕様 RFC 4253は、トランスポート層での暗号化ホスト認証を、その上のユーザー認証から分離している。GitHub の露出した秘密は、その交換のサーバーID 側にあった。

GitHub は、RSA ホスト秘密鍵がそのインフラや顧客データへのアクセスを提供しなかったと述べた。また、露出は GitHub システムや顧客情報の侵害によるものではなく、鍵が悪用されたと信じる理由はないと述べた。これらは意味のある境界である。それらは、公開自体を攻撃者が GitHub にログインし、プライベートリポジトリを静止状態で読み取り、ユーザーの SSH 秘密鍵を取得し、ブランチを変更し、Web および HTTPS Git サービスに到達した証拠として扱うことを排除する。

リスクは条件的ではあるが現実的だった。古いホスト秘密鍵を保有する攻撃者は、被害者の経路に偽装者を配置するか、被害者がそれに接続するように仕向ける必要がある。それには、悪意のある DNS、ルート操作、侵害されたプロキシまたはネットワーク、欺瞞的なホスト設定、またはクライアントが既に通過しているインフラの制御が含まれる可能性がある。クライアントが古い RSA ID を GitHub として受け入れた場合、攻撃者は SSH 接続を信頼されたホストとして終了させることができる。攻撃者はそのエンドポイントに送信された Git リクエストを観察し、プッシュされたオブジェクトを受け取り、偽のリポジトリコンテンツを提供し、またはクライアントの設定に応じてより精巧なリレーや資格情報攻撃を試みることができる。盗まれた鍵はサーバー偽装能力を供給したが、自動的にネットワーク上の位置を供給したわけではない。

公開記録は、以前に記録された Git トラフィックの事後的な復号化を確立していない。最新の SSH 鍵交換は通常、セッション秘密を別途導出し、ホスト鍵を使用して交換を認証する。GitHub の通知は偽装と盗聴の可能性について警告したが、過去のセッションが復号化された、悪意のあるエンドポイントが見つかった、被害者の接続が特定された、またはリポジトリ素材が傍受されたとは報告していない。

これにより、規律あるインシデント声明が生まれる：プライベートサービスの認証鍵が公開され、その開示は SSH クライアントのサブセットに対してサービスを偽装する機会を生み出し、GitHub は鍵を交換することでその機会を無効にし、その交換は一部の正しく厳格なクライアントを混乱させ、本記事のためにレビューされた公開証拠は悪用を示していない。潜在的な結果は緊急性に情報を提供するべきである。観測された侵害として書き換えられるべきではない。

サブセットも重要である。GitHub は GitHub.com RSA SSH ホスト鍵のみを交換した。通知によると、ECDSA および Ed25519 ユーザーは行動する必要がなく、HTTPS Git 操作と通常の Web トラフィックは影響を受けなかった。GitHub が管理するSSH フィンガープリントページは、個別の RSA、ECDSA、および Ed25519 フィンガープリントと完全な公開鍵エントリを公開している。「GitHub の SSH 鍵が変更された」とアルゴリズムを指定せずに言う組織は、まだ有効な信頼を不必要に削除し、フォレンジックレビューを困難にするだろう。

公開通知が許容するタイムライン

イベントは GitHub が開示した解像度でのみ再構築できる。欠落した間隔は発見の一部であり、推測への招待ではない。

発見前。古い RSA ホスト鍵はアクティブであり、クライアントに信頼されていた。GitHub は、秘密鍵が現れたリポジトリ、それを所有していたアカウントまたは組織、ファイルパス、公開した人物またはプロセス、正確な露出間隔を公に特定していない。「一時的に」はタイムスタンプではない。認証されていないクローン、フォーク、キャッシュ、検索インデックス、API レスポンス、ログ、またはサードパーティのミラーが素材を保持したかどうかは開示されていない。

3月20日の週。GitHub は露出を発見した。通知は、検出が自社のシークレットスキャン、従業員、ユーザー、研究者、または他の自動化された制御から来たかどうかを述べていない。直ちに露出を封じ込め、根本原因と影響の調査を開始したと述べている。公開された説明では、リポジトリアーティファクトの封じ込めが後のホスト鍵交換を超えて何を含んでいたかは定義されていない。

3月24日02:30 UTC 頃。一部のクライアントは準備中に新しい RSA ホスト鍵に遭遇した可能性がある。これは、トラストストアの変更が約05:00 UTC の交換ポイントより前に外部から見えたため重要である。リハーサルされた緊急計画では、準備的な提示は文書化された期待される動作との意図的な互換性ステップ、またはインシデントタイムラインに捕捉された展開異常のいずれかである。GitHub はそれを認めたが、メカニズムを説明しなかった。

約05:00 UTC。GitHub は RSA 交換を完了し、伝播に約30分かかると見込んだ。古い鍵はその後、正規の GitHub.com SSH サービスを認証しなくなるはずである。それに固定されたクライアントはフェイルクローズする可能性がある。変更されていない鍵タイプをネゴシエートするクライアントは続行できる。HTTPS は代替 Git トランスポートのままだった。

交換直後。GitHub はユーザーに、古いgithub.comエントリを削除し、新しい公開鍵を直接追加するか、公開された鍵を GitHub Meta API から取得し、新しい RSA フィンガープリントを確認するように指示した。また、ssh-keyオプションを使用するactions/checkoutを使用した GitHub Actions ジョブが失敗する可能性があると警告した。GitHub はアクションのサポートされているv2、v3、およびmainタグを更新していたと述べている。特定のコミット SHA に固定されたジョブはそれらのタグとともに移動せず、意図的な更新が必要だった。

公開エンドポイントの状態。現在のREST Meta エンドポイントドキュメントは、認証されていないGET /metaレスポンスに SSH 鍵フィンガープリントと完全なホスト公開鍵の両方が含まれていることを示している。これによりマシンに構造化されたソースが提供される。特定の組織がインシデント中に新しいレスポンスを信頼すべきかどうかは決定せず、その現在のスキーマはすべてのクライアントが2023年3月に受け取った正確なレスポンスを証明するものではない。

公開された年表はそこで終了している。GitHub は、レビューされたソースにおいて、公開経路、露出期間、スキャナーの動作、失敗した顧客の数、古い鍵を使用しようとした試行の観測、または恒久的な鍵管理の変更を特定する後のフォレンジックレポートを発行しなかった。これらの詳細の欠如は、GitHub がそれらを調査しなかったことを証明するものではない。それは部外者が検証できるものを制限する。

警告は決定点であり、クリアすべきエラーメッセージではなかった

GitHub の現在のホスト鍵検証トラブルシューティングページは正しい決定ルールを示している：予期しない鍵は信頼できる情報源からの公式な説明を持つべきであり、そのような説明が存在しない場合、最も安全な行動は接続しないことである。特に GitHub のホスト鍵変更は GitHub Blog で発表されると述べ、ユーザーをフィンガープリントドキュメントに誘導している。

そのルールは、1つの赤い端末メッセージを3つの別々のタスクに変換する。

第一に、何が起こったかを保存する。UTC 時刻、ランナーまたはワークステーション、宛先名とアドレス、鍵アルゴリズム、提示されたフィンガープリント、コマンド、関連するネットワークパスを記録する。「GitHub がダウンしている」だけを含むサポートチケットはセキュリティシグナルを失う。誰かがそれをキャプチャする前に行を削除する開発者も同様である。

第二に、信頼が争点の鍵に依存しないチャネルを通じて検証する。2023年3月、GitHub は HTTPS ブログ通知、HTTPS ドキュメントページ、HTTPS API エンドポイントを提供した。これらのチャネルは GitHub の組織的管理下にあったが、古い SSH ホスト鍵ではなく Web PKI を使用していた。通常の開発者にとって、警告のフィンガープリントを通知およびドキュメントと比較することは、同じ SSH パスを介して提示された鍵を受け入れるよりもはるかに優れていた。

第三に、最も狭い影響を受ける信頼を更新する。対象のホスト名または管理エイリアスの古い RSA エントリを削除し、承認された置換エントリをインストールし、テストする。`known_hosts`ファイル全体を削除すると、無関係なサービスの信頼が破棄される。問題のあるネットワークパスから`ssh-keyscan`で鍵を取得し、すぐに信頼することは、そのパスが言うことを記録するだけである。インシデントと同時期の OpenBSD 7.2のssh-keyscan マニュアルは、検証されていないスキャン出力から known-hosts ファイルを構築すると、ユーザーが中間者攻撃に対して脆弱になることを警告している。

運用上の誘惑は、`StrictHostKeyChecking=no`を設定するか、`UserKnownHostsFile`を使い捨て可能な場所に指定することである。それによりパイプラインをグリーンにできるかもしれないが、質問を「これは GitHub か？」から「ポート22で何かが応答したか？」に変更する。OpenSSH のクライアント設定マニュアルは、厳格なチェックが変更されたホスト鍵を拒否し、この種の偽装に対して最大の保護を提供すると説明している。また、`accept-new`について説明しており、これは以前は未知のホストを受け入れるが、変更された鍵は依然として拒否する。どちらの設定も、本物のホスト ID を配布する必要性を排除しない。

教訓は、すべての開発者が05:00 UTC に暗号技術者にならなければならないということではない。組織が緊急事態の前に暗号上の質問を運用上の質問に変換すべきであるということである：どのソースが権威があるか、誰が新しいフィンガープリントを承認できるか、どのように配布されるか、どのジョブが一時停止しなければならないか、成功した回復はどのように証拠付けられるか。

反事実その1：公開がスケジュールを強制する前にローテーションする

もしも GitHub が1ヶ月前に計画された演習として RSA ホスト鍵をローテーションしていたらどうなっていたかと考えてみる。

計画されたローテーションは、将来のフィンガープリントを事前に公開し、複数のホスト鍵アルゴリズムを提示し、管理されたトラストストアを更新し、GitHub Actions パスを実行し、まだ RSA に固定されているクライアントを測定し、定義された重複期間中に古い鍵を有効のままにしておくことができる。OpenSSH の`UpdateHostKeys`メカニズムは、サーバーが既に信頼されている鍵で認証された後にのみ追加の鍵を学習できる。これは優雅なローテーションのための有用なパターンである：無傷の信頼関係を使用して、現在のものを廃止する前に次の ID を導入する。

秘密鍵の露出後の緊急ローテーションは異なる。古い秘密鍵が攻撃者の手にある可能性がある場合、長期の重複は偽装の機会を維持する。プロバイダーはローテーションを決して行わないと約束することでその緊張を解決できない。独立して保護された複数のホスト鍵を維持し、クライアントのネゴシエーションを定期的にテストし、安定した検証エンドポイントを公開し、圧縮された失効パスをリハーサルし、どのプロバイダー管理の依存関係が古い鍵を埋め込んでいるかを知ることでそれを減らすことができる。

GitHub は既に ECDSA および Ed25519 ホスト ID を持っており、通知はそれらの鍵のユーザーは影響を受けなかったと述べている。これにより爆発半径が減少した。公開記録は、どのくらいのユーザーとジョブが既にそれらの代替手段を学習していたか、いくつが RSA のみであったか、または露出前のローテーション演習が緊急パスをテストしていたかを定量化していない。それらの数字は、サーバー上の暗号的多様性と顧客ベース全体の使用可能な継続性を区別するだろう。

実用的なローテーションテストは、両端に証拠がある。プロバイダーは、交換を開発者ワークスペースに秘密素材をエクスポートせずに生成できること、意図しない早期提示なしに展開できること、古い鍵を迅速に失効できること、ブログ、ドキュメント、API、サポート、ステータスメッセージが一貫していること、ファーストパーティのクライアントとアクションが更新できることを示せるべきである。顧客は、そのフリートが予告なしの変更を拒否し、承認された予告された変更を消費し、各開発者が即興で行うことを要求しないことを示せるべきである。

重要な指標は「ローテーション完了」ではない。それは、プロバイダーの決定から検証済みの顧客回復までの時間であり、人間のワークステーション、永続サーバー、エフェメラルランナー、サードパーティ CI、デプロイアプライアンス、固定されたアクションバージョンで分割される。サービスエッジで成功しながら、高価値のデプロイメントシステムがソースを取得できないままにするローテーションは、技術的には完了しているが、運用上は未完了である。

反事実その2：検証を重要になるほど独立させる

さて、攻撃者が露出した RSA 鍵と、GitHub が変更を発表した瞬間に1つの顧客のネットワーク上の位置の両方を持っていたと仮定する。顧客は、本物の新しい鍵と、依然として信頼されている古い鍵を提示する攻撃者を区別できるだろうか？

3月の通知はいくつかの有用な事実を提供した：影響を受けるアルゴリズム、交換フィンガープリント、完全な公開鍵、有効時間、変更されていない代替手段、コマンド。GitHub の API は機械可読データを提供した。ドキュメントとブログは HTTPS を使用していた。ほとんどの組織にとって、これらの表面の複数をチェックし、正確なフィンガープリントの一致を要求することは合理的な緊急手順だった。

しかし、「独立している」はスペクトルである。ブログ、ドキュメント、API、サポートポータル、サービスは同じ企業およびドメインエコシステム内で運用されている。GitHub の公開コントロールプレーンが広範囲に侵害された場合、一度に複数に影響を与える可能性があるが、ここではその証拠はない。より高い保証ニーズを持つ顧客は、承認されたフィンガープリントを独自の設定リポジトリにキャッシュし、事前登録されたチャネルを通じて署名されたベンダー勧告を受け取り、別々のネットワークからのソースを比較するために2人の内部レビューアを必要とするか、信頼できるサプライヤーフィードを使用できる。

SSH プロトコルは他の信頼配布モデルも定義している。RFC 4255は SSHFP DNS レコードを指定し、フィンガープリントが安全な検証チャネルなしで受け入れられる場合、接続が脆弱なままになると強調している。DNS ベースのロールオーバーは、DNS データが認証されている場合、通常は DNSSEC を使用して、クライアントがポリシーに従って検証する場合にのみ意味を持つ。フィンガープリントを SSH 警告から署名されていない DNS に移動することは、信頼問題を解決するのではなく、移転することになる。

GitHub の信頼性コミュニケーションは関連するが、互換性はない。同社のステータスサイトデザインの説明は、Git 操作が別個のコンポーネントを持ち、顧客がメール、SMS、または Webhook で購読できることを説明している。現在のGitHub サポートドキュメントも同様に、顧客をステータスインシデントと購読チャネルに誘導している。それらのフィードは運用チームにサービス問題が存在することを伝えることができる。ステータスライトだけでは、インシデントメッセージが権威ある鍵証拠を運ぶかリンクしない限り、交換フィンガープリントを認証できない。

したがって、反事実テストは具体的である：ステージングランナーを組織の通常の管理コンソールから切断し、期待される GitHub RSA 鍵をテスト鍵に置き換え、応答を観察する。ジョブは停止するか？アラートは提示されたフィンガープリントを保存するか？オンコールエンジニアは、そのジョブに依存しないチャネルを通じて承認された勧告を見つけられるか？変更を承認する権限のある人物の ID はあるか？設定管理はフリートを原子的に更新し、不正なエントリをロールバックできるか？答えが「誰かがウェブを検索して最初のコマンドを貼り付ける」である場合、信頼モデルはまだほとんど人間の運に依存している。

反事実その3：「一時的に」が始まる前に秘密鍵を止める

イベントは公開リポジトリ内の秘密素材から始まったため、合理的な制御レビューは公開がどこで中断され得たかを問う。GitHub が提供しなかった答えを仮定してはならない。

インシデントの数週間前の2023年2月28日、GitHub はシークレットスキャンアラートがすべての公開リポジトリで無料で一般利用可能になったと発表した。発表は、リポジトリ所有者が履歴全体のスキャンを有効にし、プロバイダー通知が不可能なシークレット（セルフホスト鍵を含む）のアラートを受け取ることができると述べた。これにより製品機能と公開リポジトリ管理者に対するそのオプトイン性質が確立される。ホスト鍵イベントに関与したリポジトリで機能が有効になっていたか、露出したエンコーディングがサポートされているパターンに一致したか、GitHub の内部セキュリティが別の制御を持っていたか、スキャンが鍵を発見したかは確立されない。

タイミングは重要である。GitHub は2023年5月9日にプッシュ保護をすべての公開リポジトリで一般利用可能にした。これはホスト鍵インシデントの後である。それ以前は、GitHub Advanced Security ユーザーに対して存在していた。後の発表は、より強力な制御ポイントを説明している：信頼性の高いシークレットがリポジトリに到達する前に特定し、コントリビューターに削除または明示的にバイパスするよう求める。5月の広範な利用可能性を3月に遡って読むのは不正確であろう。

GitHub の現在のサポートパターンリファレンスは、汎用 RSA および OpenSSH 秘密鍵パターンをリストしている。これは有用な2026年のベンチマークであり、2023年3月のマッチャーの証明ではない。ホスト秘密鍵は、エンコード、分割、暗号化、ビルド中に生成、アーカイブに保存、または汎用パターンが見逃す形式で表現される可能性もある。シークレットスキャンは1つの層であり、管理設計ではない。

より強力な反事実は Git の前から始まる。なぜプロダクションサービスのホスト秘密鍵が、任意のリポジトリにコミットされ得るコンテキストに存在できたのか？成熟した設計は、プロダクション秘密鍵の操作を署名境界、ハードウェアバックアップサービス、または厳密に管理された展開メカニズムの背後に保ち、エクスポートを制限し、プロダクション素材が通常のファイルシステムやログに入るのを防ぎ、リポジトリを分類し、ローカル変更とサーバー側プッシュをスキャンし、バイパスにはレビューを要求し、信頼できる露出が確認されたときに鍵を自動的に失効させる。

公開通知は、鍵が通常の管理システムからエクスポートされたか、安全でない場所で生成されたか、テスト用にコピーされたか、自動化によって出力されたか、それが何であるかを知る理由がない誰かによって公開されたかを述べていない。また、その後変更された予防的制御を特定していない。説明責任はその沈黙から正確な根本原因を割り当てることはできない。プロバイダーが保持すべき証拠を特定できる：鍵生成およびエクスポートログ、リポジトリプッシュイベント、スキャナー結果、アラートルーティング、最初のビューおよびクローン時刻、封じ込めアクション、鍵使用テレメトリ、キャッシュおよびフォークのレビュー、失効の決定記録。

ここには不快な製品レベルのミラーがある。GitHub は顧客が GitHub 上でシークレットを公開するのを防ぐための制御を販売し文書化している。自社のホスト鍵が公開 GitHub リポジトリに現れた。それは偽善や製品の失敗を証明するものではない。制御がイベントを検出したか、リポジトリに適用されなかったか、バイパスされた可能性がある。それは制御パスの開示を特に価値あるものにする。それがなければ、顧客はローテーションを見ることができるが、公開防御が改善されたかどうかを知ることはできない。

反事実その4：トラストストアをプロダクション依存関係として扱う

エンタープライズ自動化はしばしば SSH 信頼を列挙が困難な場所に隠す：ベースイメージ、デプロイメントコンテナ、セルフホストランナー、ベンダーアプライアンス、Jenkins 資格情報、Kubernetes シークレットまたは ConfigMap、開発者ブートストラップスクリプト、ゴールデンマシンイメージ、ビルドパック、サブモジュール設定、アクションコード。一部のエントリは`github.com`を使用する。他のものは SSH エイリアス、バスティオン、解決済みアドレス、またはハッシュ化されたホスト名を使用する。一部のランナーは状態を永続化する。他のものは、まだ古い鍵を含むイメージから各ジョブで再構築される。

3月のインシデントはその不可視性のコストを露呈した。GitHub は特に、`ssh-key`入力を使用する`actions/checkout`ジョブが失敗する可能性があると警告した。管理されているactions/checkoutリポジトリはその理由を文書化している：SSH 認証が選択されると、アクションは秘密鍵を設定し、デフォルトで厳格なホストチェックを有効にし、暗黙的に GitHub.com の公開ホスト鍵を追加する。アクションを更新すると、移動タグに対してその埋め込まれた信頼を更新できる。不変のコミットに固定されたジョブは、レビュー済みの古いコード、その古いホスト素材を含む、を実行し続ける。

これは固定化に対する議論ではない。現在の GitHub のActions 自動化の保護に関するガイダンスは、完全なコミット SHA を推奨している。なぜなら移動可能なタグはジョブが実行するコードを変更できるからである。2023年3月、その整合性制御は継続性のコストを伴った：GitHub は中央でサポートされているタグを修復できたが、SHA 固定の顧客は新しいコミットをレビューして選択する必要があった。セキュリティプロパティは競合し得る。答えは、レビューを保持する更新プロセスであり、可変依存関係への永久的な切り替えではない。

したがって、エンタープライズ信頼プロセスは信頼素材の目録を維持すべきである：ホスト名、サービス所有者、アルゴリズム、承認されたフィンガープリント、検証ソース、消費システム、配布方法、最終テスト、ローテーション連絡先、緊急フォールバック。変更はコードレビューされるべきだが、承認パスは緊急レーンを必要とする。中央チームは新しい鍵をステージングし、SSH を介してカナリアフェッチを実行し、HTTPS を比較し、プロバイダーの Meta API をクエリし、管理クライアントに変更をロールアウトできる。開発者は、正確な影響を受けるアルゴリズムとチェックを弱めない指示を含む短い内部勧告を受け取る。

ログはフォロースルーをサポートする。GitHub の現在の組織監査イベントリファレンスは、トランス port プロトコルフィールドを持つ`git.clone`および`git.fetch`イベントを文書化しているが、Git イベントのアクセスと保持は通常の監査イベントとは異なる。これらのレコードは、企業が SSH 使用を推定し、インシデント周辺の活動を特定するのに役立つ。それらは GitHub に決して到達しなかった失敗した接続を列挙せず、現在のドキュメントはすべての顧客の2023年の計画または保持を説明していると想定されるべきではない。クライアントと CI のログは依然として必要である。

反事実テストは、企業が何もローテーションする前に、「GitHub の RSA ホスト鍵が変更された場合、どのプロダクションパイプラインが停止するか？」に答えられるかどうかである。答えが許容されるデプロイメント停止時間より長い場合、トラストストアは管理されていないプロダクション依存関係である。

CI がフィンガープリントをサービス継続性イベントに変える

人間の開発者は警告を見る。無人ランナーは非ゼロの終了ステータスを返す。その違いが影響の形状を変える。

1回の失敗したチェックアウトで、テストが開始できなくなり、リリースアーティファクトのビルドが停止し、インフラリポジトリの変更が適用できなくなり、デプロイがソースを待つ状態になる可能性がある。プライベートサブモジュールとセカンダリリポジトリは、`actions/checkout`に SSH 鍵を提供する一般的な理由である。他の CI システムは`git clone`を直接呼び出す。ホスト鍵チェックは、Git が要求されたリポジトリが良性、緊急、または公開であるかを判断できる前に行われる。影響を受けるすべての操作は同じ信頼境界で失敗する。

失敗は不均一にもなり得る。以前に Ed25519 を学習したラップトップは続行するが、RSA に固定された古いアプライアンスは停止する。サポートされている移動タグを使用する GitHub ホストジョブは、プロバイダーがタグを更新した後に回復するが、焼き付けられたイメージを持つセルフホストランナーは壊れたままになる。1つの地域オフィスが管理トラストバンドルを通過するが、別のオフィスはユーザーごとのファイルに依存するかもしれない。リトライは誤解を招く証拠を作り出す可能性がある：ジョブは02:30頃に準備鍵に遭遇し、伝播中に再度古い鍵に遭遇し、05:00後に新しい鍵に遭遇するかもしれない。

3月24日のGitHub コミュニティディスカッションでの逸話的報告は、ユーザーが変更された鍵と失敗したランナーが正当であるかどうかを判断しようとしていることを示している。コミュニティ投稿は混乱と運用症状の有用な証拠であるが、影響を受けたユーザーの信頼できる数ではない。GitHub は失敗したジョブ、SSH クライアント、または遅延したデプロイメントの分母を公開しなかった。

これが、影響が中程度と評価される理由であり、無視できるまたは高ではない。露出した鍵は深刻な可能性のある信頼障害を生み出し、緊急交換は世界中の実際の配信システムを中断させる可能性があった。同時に、開示されたイベントは1つのホスト鍵アルゴリズムに範囲が限定され、代替 SSH ホスト鍵と HTTPS は利用可能であり、悪用、広範なリポジトリ侵害、長期にわたる GitHub 停止、安全影響、または定量化された重大なビジネス損失の公開証拠はない。

最も危険な回復アクションは、中程度の中断を無制限の整合性リスクに変換することだった：リリースを続行できるようにホストチェックをグローバルに無効にする。より規律のあるランブックは、影響を受けるレーンを一時停止し、承認された HTTPS または内部チャネルを通じて新しい鍵を検証し、カナリアを更新し、読み取り専用のフェッチと ID テストを実行し、信頼変更を展開し、失敗したジョブを再実行する。検証されていないエンドポイントを介して試みられたプッシュまたはデプロイメントは、単に再試行されるのではなく、レビューを必要とする証拠として扱われるべきである。

同じ朝の SME 版

中小企業（SME）は、リポジトリホスティング、コラボレーション、ID、自動化スタックを経済的に再現できないため、しばしば正確に GitHub を使用する。その効率性は、非常に小さいチームに決定を集中させる。ホスト警告を受け取る人は、製品デリバリー、顧客サポート、クラウドインフラ、インシデント対応も担当している可能性がある。

CISA のSMB ICT サプライチェーンリスクファクトシートは、イベントの2ヶ月後に公開され、この制約から始まる：小規模企業は ICT 製品とサービスに依存しているが、専任のリスク管理機能を持っていない可能性がある。そのような企業に「フィンガープリントを検証せよ」と言うのは必要だが不完全である。唯一のエンジニアがリリースプレッシャー下にあるときに機能する安価な手順が必要である。

最小限の実行可能な手順は控えめである。準備されテストされた資格情報方法を使用して、2つ目の Git リモート URL を HTTPS で保持する。ビジネスクリティカルなリポジトリのローカルまたは外部ミラーを維持する。プロバイダーのセキュリティおよびステータスコミュニケーションに少なくとも2人または役割を購読させる。承認されたホストフィンガープリントとソース URL を内部ランブックに保存する。組織全体の信頼を変更する前に2回目のチェックを要求する。どの CI ジョブが SSH を使用し、どのジョブが HTTPS を使用するかを知る。四半期ごとに失敗したチェックアウトをテストする。

GitHub のリモート管理ドキュメントは、リモートを SSH と HTTPS の間で切り替える方法を説明している。これは、3月のイベントが HTTPS Git 操作に影響しなかったため、有用な継続性オプションである。ただし、自動フェイルオーバーではない。HTTPS には独自の資格情報、信頼、プロキシ、最小権限の取り決めが必要である。ビルドログに広範な個人アクセストークンを埋め込む急いだ切り替えは、1つのインシデントを解決する代わりに別のインシデントを生み出す。

リポジトリの可用性も境界を必要とする。Git は分散型であるため、アクティブなクローンにはプロジェクト履歴が含まれるが、開発者ラップトップは完全な組織バックアップではない。GitHub のリポジトリバックアップガイダンスは、履歴のためにミラークローンを推奨し、異なる方法が異なるメタデータまたは Large File Storage オブジェクトを省略することを警告している。公式のgit-bundle ドキュメントは、オフライン転送と完全または増分リポジトリバックアップを説明している。どちらのメカニズムも、issues、pull requests、Actions 設定、シークレット、パッケージ、ブランチルール、現在のチーム権限を自動的に保持しない。

SME にとって、継続性はすべてのプロジェクトに対して2つ目の完全にライブな鍛冶場を必要としない。フォールバックをビジネス結果に一致させることが必要である。デプロイを4時間遅らせることができる企業は、検証済みの HTTPS フォールバックとミラーのみを必要とするかもしれない。緊急修正が GitHub に依存している医療または決済サプライヤーは、テストされた外部バックアップ、再現可能なビルドツール、2番目の承認チャネル、文書化された手動リリースパスを必要とするかもしれない。問題は、GitHub が「十分に信頼できる」かどうかではない。企業のプロダクションを変更する能力のどれだけが、1つのプロバイダーの信頼アサーションに依存しているかである。

評価を変える証拠

公開記録は交換アクションに関しては強力であり、露出メカニズムに関しては弱い。

GitHub が報告された時刻に RSA ホスト鍵を交換したという確信は高い。なぜなら、同社は新しいフィンガープリントを公開し、顧客は変更されたサービス ID を観察できたからである。鍵だけでは直接 GitHub の顧客アカウントやリポジトリを開けなかったという確信は高い。それは暗号の役割と GitHub の明示的な境界から導かれる。厳格なクライアントといくつかの SSH 設定の Actions ジョブが失敗する可能性があったという確信も高い。これは意図されたクライアント動作であり、GitHub がそれについて警告したからである。

秘密がどのように公開リポジトリに到達したか、どれだけの期間取得可能だったか、誰が取得したか、そして GitHub がどのように悪用を排除したかについての確信は低い。GitHub の「信じる理由はない」という声明は、誰も鍵をコピーしなかったという証明と同じではない。公開リポジトリは迅速な複製のために設計されている。逆に、間隔中のクローンまたはページビューは、それ自体で悪意のある使用を証明するものではない。使用の証拠は、ネットワークテレメトリ、開示後の古い鍵偽装の報告、不審なエンドポイント、または顧客側の接続レコードを必要とする。

より完全なプロバイダーレポートは8つの質問に答えるだろう：

秘密鍵を生成またはエクスポートしたのは何か、そしてどの管理境界が越えられたか？
どのリポジトリ表面がそれを露出させたか、正確にどのくらいの期間、どの API またはキャッシュを通じてか？
どの制御がそれを発見したか、そしてアラートはそれを失効させる権限のある人にどれだけ早く到達したか？
GitHub システムと顧客情報が侵害されていないという結論を支持する証拠は何か？
ホスト鍵使用の試みについてどのテレメトリが調査されたか、そしてどのような可視性の制限が残っていたか？
なぜ新しい鍵が約02:30 UTC から見えたのか、そしてそれは変更計画の範囲内だったか？
いくつのファーストパーティジョブまたはサポートされているアクションバージョンが更新を必要とし、顧客向けの回復にはどのくらいの時間がかかったか？
鍵管理、リポジトリ予防、ローテーションリハーサル、顧客通知にどのような恒久的な変更が加えられたか？

GitHub の現在のセキュリティインシデントへの対応に関するガイダンスは、証拠の保存、決定の記録、コミュニケーション、監査データの使用を推奨している。これは賢明な現在のベンチマークである。GitHub 自身の2023年の対応の独立した監査ではない。

NIST の現在のサイバーセキュリティサプライチェーンリスクガイダンスは、サプライヤー保証、インシデント調整、緊急時計画を組織ガバナンス内に配置している。ここに適用すると、保証はプロバイダーが安全であるという証明書ではない。それは、プロバイダーが侵害された ID を失効させ、顧客に交換を認証する方法を伝え、残りの不確実性を理解するのに役立つ証拠である。

責任は実用的な制御に従う

不注意な公開者（人物が関与していた場合）は直接的な行為を管理していたが、おそらくプロダクションホスト素材を公開可能にしたシステム全体を管理していなかった。その人物を特定しても、なぜエクスポートが可能だったのか、なぜリポジトリ制御がオブジェクトを許可したのか、なぜ検出にその時間がかかったのか、ローテーションが顧客にどのように影響したのかには答えない。GitHub はアクターを特定しておらず、動機を割り当てる根拠はない。

GitHub のセキュリティおよびインフラリーダーシップは、最も影響力の高い保護手段を管理していた：ホスト鍵の生成と保管、秘密素材へのアクセス、リポジトリポリシー、検出と調査、失効タイミング、新しい鍵の展開、悪用のテレメトリ、公開フィンガープリント、ファーストパーティの Actions 更新、サポート調整、インシデント後の開示の深さ。顧客は GitHub.com のホスト鍵をローテーションしたり、その管理を検査したりできなかったため、予防と対応の説明責任の最大のシェアを受け取る。

GitHub はまた、中核的な封じ込め決定に対して称賛に値する。鍵の交換は、運用コストにもかかわらず慎重な行動だった。通知は影響を受けるアルゴリズムを名指しし、SSH を HTTPS から分離し、新しいフィンガープリントと公開鍵を提供し、手動および API ベースの更新方法を示し、02:30 UTC の準備的提示を認め、Actions ユーザーに警告し、サポートされているタグを更新した。顧客を驚かせないように変更を隠蔽したプロバイダーは、開示された秘密鍵を信頼したままにしていただろう。

組織およびエンタープライズの所有者は、GitHub がどのように彼らのプロダクションチェーンに入るかを管理していた。彼らの責任には、SSH 使用の棚卸し、厳格な検証の維持、権威あるトラストバンドルの管理、通知の購読、オンコールスタッフへの承認パスの提供、クライアントログの保持、代替トランスポートのテスト、重要なソースとメタデータのバックアップが含まれていた。これらの義務は GitHub の公開を許すものではない。それらは、顧客の回復設計が GitHub が管理しないシステム上に存在することを認識するものである。

Action およびインテグレーションのメンテナーは、埋め込まれたホスト素材、リリースチャネル、更新手順を管理していた。移動タグは迅速な修正を提供できる。固定された SHA はレビュー済みの整合性を保持できる。メンテナーは正確な修正コミットを公開し、サポートされている場合はリリースに署名またはその他の方法で認証し、ライブで検証されていないスキャンを奨励せずに信頼素材を設定可能にするべきである。

SME のリーダーシップは優先順位とリソースを管理していた。5人の会社がグローバルな暗号対応チームを運用することを期待するのは非現実的である。所有者を割り当て、1つのテスト済みフォールバックを維持し、ソース管理の中断がどの程度許容されるかを決定することは合理的である。調達および保険会社は、一般的なアンケートではなく、その結果に見合った証拠を求めるべきである。

鍵を使用して GitHub を偽装した攻撃者は、その攻撃に対して責任を負うことになる。レビューされた公開記録では、そのような使用は確立されていない。ネットワークオペレーター、DNS プロバイダー、認証局は隣接する信頼チャネルを管理していたが、それらが失敗した、またはこのイベントに関与したという証拠はない。仮想的な攻撃がそれらを必要とするからといって、責任をすべての可能な参加者に分配すべきではない。

警告の両方の意味に耐える制御セット

耐久性のある目的は「ホスト鍵警告を防ぐ」ことではない。それは、警告がメンテナンスを意味するか攻撃を意味するかにかかわらず、組織が正しく対応するようにすることである。

プロバイダーにとって、可能な場合はホスト秘密鍵をエクスポート不可に保ち、プロダクション署名をリポジトリおよび開発者環境から分離し、すべての例外的なエクスポートをログに記録する。コミット前、プッシュ時、公開後にファイルをスキャンする。汎用秘密鍵形式を含める。信頼性の高いプロダクション鍵アラートをインシデント機能に直接ルーティングする。バイパスを稀にし、属性付け可能にし、レビューされるようにする。別の管理ドメインに少なくとも2つの最新のホスト鍵アルゴリズムを維持する。ファーストパーティクライアント、サポートされている Actions、ドキュメント、API、サポート、顧客通知を通じて緊急ローテーションをリハーサルする。

顧客にとって、厳格なチェックを実施し、承認されたホスト鍵を設定管理を通じて配布する。SSH over Git を実行するすべてのシステムを棚卸しする。プロバイダーのフィンガープリントと検証 URL を管理されたランブックにキャッシュする。セキュリティ変更と運用ステータスの両方のチャネルを購読する。正確なアルゴリズムとフィンガープリントの比較を要求する。失敗した接続の証拠を保存する。限定された資格情報で HTTPS フォールバックをテストし、ミラーまたはバンドルからリポジトリの復元をテストする。

両側にとって、ハンドオフを測定する。プロバイダーの検出、封じ込め、決定、ローテーション、公開、ファーストパーティ依存関係のパッチまでの時間は、内部的に可視であるべきである。顧客のアラート、検証、承認、カナリアの更新、信頼の展開、失敗したジョブのクリアまでの時間は、演習で測定されるべきである。02:30 UTC と05:00 UTC の間の間隔は、展開フェーズが外部に意味のあるタイムスタンプを必要とする理由を示している。

最終テストは意図的に不快なものである。1つの演習で予告された交換鍵を提示し、別の演習で予告なしの偽の鍵を提示する。予告された鍵は回復目標内で検証され展開されるべきである。偽の鍵はブロックされたままであり、疑わしい傍受としてエスカレーションされるべきである。両方が受け入れられた場合、セキュリティは失敗している。両方が無期限にブロックされたままの場合、継続性は失敗している。スタッフにどの演習がどれであるかが始まる前に伝えられた場合、組織はスクリプトをテストしたのであり、判断力をテストしたのではない。

説明責任の結論

GitHub の2023年3月の対応は、その中心的な行為において正しかった：公に露出したホスト秘密鍵は、観測された悪用がなくても、もはや信頼された ID であり続けることはできなかった。ローテーションはセキュリティリスクを低減した。結果として生じた失敗は副作用のノイズではなかった。それらは、クライアントが鍵が存在する目的である信頼決定を実施していることの証明だった。

このイベントは、その証拠の範囲内に留められるとき、より教訓的になる。それは、顧客リポジトリの開示された盗難ではなかった。それは、攻撃者が GitHub に侵入した証拠ではなかった。それは、一般的な GitHub.com の停止ではなかった。それは、プロバイダー認証秘密の公開であり、その後に迅速な交換が行われ、一部の顧客と自動化に、警戒すべき新しい ID が本物かどうかを決定することを強いた。

GitHub は、そのホスト秘密鍵が公開され得る条件と交換シグナルの品質を所有していた。顧客は、そのシグナルから開発者マシンとリリースシステムへのラストマイルを所有していた。それらの間のギャップがクラウド依存関係だった：グローバルプロバイダーは1つの新しいフィンガープリントを公開できたが、すべての依存組織はそれを認証し、承認し、運用化する必要があった。

成熟した企業にとって、これは管理された信頼更新であるべきである。SME にとって、それは2つ目の目とテスト済みの HTTPS ルートを持つ短いランブックであるべきである。どちらにとっても、答えは警告を沈黙させることではない。停止したクライアントが信頼できる証拠を取得し、狭く更新し、ID がもはや重要でないふりをせずに再開できる場合にのみ、その朝は安全だった。