トークンには有効期限があるが、キーにはない。
GitHub Appの認証は、最大10分の寿命を持つJSON Web Token (JWT) を生成するプライベートキーに依存しています。このJWTは、最大1時間有効なインストールアクセストークンを要求します。GitHubはこれらの下流トークンの有効期限を厳格に強制しており、一時的なアクセスであるかのような錯覚を生み出しています。
しかし、これらの認証情報の源であるルートプライベートキーには、ネイティブな有効期限（TTL）がありません。明示的に取り消されない限り、新しいトークンを永続的に生成し続けることができます。この根本的なアーキテクチャ上の選択は、侵害された、あるいは忘れられたキーが、それが生成する短命なトークンとは異なり、永続的な脅威であり続けることを意味します。
これは、プラットフォームによる有効期限の強制がないという点でSSHキーの挙動に似ていると主張する人もいますが、GitHub Appの権限範囲はリスクを劇的に高めます。アプリは多くの場合、以下のような広範なマルチリポジトリアクセス権を持っています：
- 組織の管理権限
- プライベートコードへの書き込みアクセス
- セルフホストランナーおよびワークフロー実行の制御
GitGuardianの調査によると、474個の有効なキーが発見され、そのうち44個は組織全体の管理者権限を持っていました。米国CDCに関連するあるキーは、流出後17ヶ月間もプライベートコードへの書き込みアクセスを許可していました。これは、管理されていないGitHub Appキーが、一般的なSSHキーをはるかに超える、重大かつ永続的なガバナンスリスクをもたらす理由を浮き彫りにしています。
474個の流出したキーが依然として扉を開いたままにしていた
GitGuardianの最近の調査により、厳しい現実が明らかになりました。50万個以上の公開されたRSAキーのうち、4,802個がGitHub App IDに関連付けられていました。驚くべきことに、これらのキーのうち474個は公開されていたにもかかわらず認証が可能であり、440個の異なるアプリに相当しました。これはセキュリティチェーンにおける重大な脆弱性を示しています。
これらの永続的な露出がもたらす影響は深刻です。44個の有効なアプリは組織全体の管理者権限を持っており、72%はプライベートリポジトリを読み取ることができました。さらに、207個のアプリは書き込み権限を保持しており、任意のコード注入やパイプライン汚染を可能にする、重大なサプライチェーンセキュリティリスクとなっています。
この問題の持続性は懸念すべきものです。Crusher.devのあるキーは2020年から公開されたままアクティブでした。米国CDCに関連するキーは、流出から17ヶ月間有効であったと報告されています。また、広く使用されているアプリ「Access Tokens for GitHub Actions」は、2024年1月にプライベートキーを漏洩させ、防衛請負業者であるSierra Nevada Corpを含む約300の組織に影響を与えました。
これらの例は、GitHub Appプライベートキーの危険性を強調しています。それらが生成する短命なJWTやインストールアクセストークンとは異なり、ルートプライベートキー自体にはネイティブな有効期限がありません。このアーキテクチャ上の見落としにより、一度の流出が永続的なセキュリティ脅威へと変わり、早急な対応と堅牢なキーローテーション戦略が求められています。
忘れられたアプリがサプライチェーンの足がかりになる可能性がある
忘れられたアプリは、サプライチェーンにおける重大な足がかりとなります。流出したキーにより、攻撃者はプライベートコードの読み取り、リポジトリへの書き込み、ワークフローの操作、あるいはセルフホストランナーの管理が可能になります。このようなアクセスは、コードの改ざん、CI/CDの侵害、そして最終的には組織の乗っ取りを直接的に促進します。
放置されたインテグレーションは見過ごされがちです。GitGuardianの調査によると、アクティブなキーを持つ440の異なるアプリのうち59%がインストールは1回のみで、多くはアドホックな自動化のために使用されていました。エンジニアが離職したりプロジェクトが放棄されたりすると、これらのアプリの所有権が不明確になり、永続的な脆弱性が残ります。Crusher.devのアプリキーは2020年から漏洩しており、プロジェクトのメンテナンスが終了した後も数年間アクティブなままでした。
例えば、米国疾病予防管理センター（CDC）では、プライベートリポジトリへの書き込み権限を持つ秘密鍵が17ヶ月間漏洩しており、Microsoft Azureインフラストラクチャへのアクセスを仲介していました。同様に、広く使用されている「Access Tokens for GitHub Actions」アプリでも秘密鍵が漏洩し、約300の組織が危険にさらされました。
有効なキーが存在することが直ちに悪用を証明するわけではありませんが、永続的な露出を意味します。攻撃者は一度有効なキーを入手すれば、アプリに付与された権限でいつでも行動できます。これらの永続的な脅威の詳細については、GitGuardianの調査「GitHub App Private Keys: 474 Leaked Keys Still Work」を参照してください。これは、GitHub App private keysとその関連権限を厳格に管理し、supply-chain risksを軽減することの重要性を強調しています。
この記事が気に入ったら、毎朝同じようなものをメールで受け取れます。
1日1通 · 2クリックで解除 · サードパーティのトラッキングなし
ダウンタイムなしでローテーションし、所有者のいないものを廃止する
アプリの所有者は、堅牢なキーローテーション戦略を実装する必要があります。新しいprivate keyを生成し、デプロイして機能を検証した後、古いキーを失効させます。GitHubではアプリごとに最大25個のアクティブな秘密鍵を保持できるため、サービスを中断することなく段階的なローテーションが可能です。
文書化されたローテーションの頻度と安全なキー保管プロトコルを確立し、開発者が所有するパブリックフォークを含むすべてのリポジトリにsecret scanningを統合してください。最小権限の原則を強制し、アプリの機能に厳密に必要なリポジトリとアクションのみに権限を制限します。これにより、万が一侵害された場合の被害範囲を最小限に抑えることができます。
組織の管理者は、インストールされているアプリを監査するという重要な責務を負っています。すべてのインテグレーションに対して責任者を特定し、割り当ててください。放棄されたアプリやメンテナンスされていないアプリは、永続的な足場を求める攻撃者の格好の標的となるため、速やかに削除してください。
最後に、残存するすべてのアプリが最小限必要な権限で動作していることを確認してください。これらのアクセス制御を見直し強化することで攻撃対象領域が減少し、忘れ去られたアプリが組織の最も機密性の高い資産への入り口となることを防げます。
よくある質問
GitHub App private keysは自動的に期限切れになりますか？
いいえ。GitHub App private keysには組み込みの有効期限がないため、所有者がローテーションと失効を行う必要があります。
期限切れになっていないGitHub App keyはどのように悪用されますか？
短命なJWTの署名に使用でき、それを最大1時間有効なインストールアクセストークンと交換することが可能です。
一度にアクティブにできるGitHub App private keysはいくつですか？
GitHubではアプリごとに最大25個の秘密鍵を保持できるため、チームは古いキーを削除する前に代替キーをデプロイできます。
メンテナンスされていないアプリに対して組織は何をすべきですか？
インストールされているGitHub Appsを監査し、放置されたインテグレーションや所有者のいないインテグレーションを削除し、残ったものに対しては権限とリポジトリへのアクセスを制限してください。