見落とされがちなGitHubの10大リスクベクトル

出典: Piotr Swat / Alamy Stock Photo

解説

GitHubは、単なるバージョン管理から現代のソフトウェア開発の基盤へと進化しました。組織はnpmや、PyPIのパッケージ依存関係を熱心にスキャンしていますが、より広範な危険、すなわちソフトウェア開発ライフサイクル全体でGitHubホストのコードがシステムに侵入する多様な経路を見落としがちです。これらの隠れたリスクベクトルは、巧妙な攻撃者が積極的に悪用しており、tj-actionsのGitHub ActionやXZ Utilsの侵害などの事例で明らかになっています。

拡大するGitHub参照の攻撃対象領域

OX Securityが実施した調査によると、初期のコーディングから本番環境へのデプロイまで、開発チームはソフトウェア開発サイクルのさまざまな段階でGitHubのコンテンツを参照しており、それぞれが悪意あるコードの侵入口となり得ます。

1. 依存関係管理：GitHubへの直接参照

リスクベクトル：npm、pip、Maven、Go modulesなどのパッケージマネージャは、公式レジストリではなくGitHubリポジトリから直接依存関係を取得できます。

攻撃対象領域：「main」などのブランチのような可変参照を使うと、ビルドが非決定的になり得ます。リポジトリの所有者が変更または放棄した場合、リポジトリ乗っ取りのリスクもあります。

実際の影響：分析の結果、約11万件のpackage-lock.json、6万5千件超のrequirements.txt/pyproject.toml、5万4千件超のJitPack設定がGitHubを直接参照しており、アプリケーション権限で悪意あるコードが実行される大規模な攻撃対象領域となっています。

2. コンテナビルド：イメージ作成時のコード注入

リスクベクトル：Dockerfileは、git cloneやADD/COPYでGitHubのURLを使い、ソースコードやビルドツール、セットアップスクリプトをイメージビルド時に取得することがよくあります。

攻撃対象領域：調査では約23万4千件のDockerfileと7万8千件のdocker-composeファイルがGitHubを参照しており、レイヤキャッシュによりリモートリポジトリが変更された場合に古いまたは侵害されたコードが再利用される可能性があります。

実際の影響：ビルド時にクローンされた一見無害なユーティリティが、コンテナ内で実行される際に環境変数を漏洩させる隠し機能を持つ場合があり、基本的なTLS以外に整合性検証がほとんど行われません。

3. Kubernetesデプロイメント：Helmチャートとマニフェスト

リスクベクトル：Kubernetesマニフェスト内のHelmチャートやinitコンテナが、デプロイ時にGitHubから設定やスクリプトを取得します。

攻撃対象領域：未検証のチャートやフックによる動的取得により、クラスター権限で悪意あるリソースがデプロイされる可能性があります。GitHubはホストされた.tgzをリポジトリのソースコード検証なしで自動的に取得・利用します。

実際の影響：調査によると、悪意あるGitHub URLを参照するHelmチャートをデプロイすると、環境変数がデプロイ時に漏洩する可能性があります。

4. 構成管理：インフラ自動化

リスクベクトル：Ansible（3,000件のrequirements.yml）、SaltStack（1,000件の設定）、Logstash、Grafana（各5,000件のインストール）がGitHubから直接設定やコンポーネントを取得します。

攻撃対象領域：未検証のロール、ステート、パターン、ダッシュボードがインフラ全体で管理者権限で実行されます。

実際の影響：侵害された設定によりログのリダイレクト、ReDoS攻撃、悪意あるコマンドの実行が可能です。GrafanaダッシュボードはXSSペイロードを含んだり、データソース設定の侵害で認証情報が漏洩する恐れがあります。

5. CI/CD自動化：GitHub Actionsとワークフロー

リスクベクトル：GitHub Actionsはサードパーティ製アクションや、ワークフロー内で直接git cloneを実行します。

攻撃対象領域：分析では、約56万1千件のワークフローが外部GitHub Actionsを参照し、約16万7千件が明示的なgit cloneを使用しており、多くの場合リポジトリのシークレットやデプロイ認証情報にアクセスできます。

実際の影響：実際の事例として、侵害されたGitHub ActionsがGITHUB_TOKENを窃取したり、アーティファクトを改ざんしたり、バックドア付きコードをデプロイする可能性が示されています。可変タグ（@main）を使うと、コミットハッシュ固定よりも大きなリスクとなります。

6. コード構成：Gitサブモジュールとサブツリー

リスクベクトル：Gitサブモジュールやサブツリーは、外部リポジトリをプロジェクト内に組み込み、複雑な依存関係ツリーを作ります。

攻撃対象領域：分析では、約1万4千件のサブモジュール追加コマンドと2千件のサブツリー追加コマンドがGitHubを参照しており、参照先リポジトリが侵害または乗っ取られるリスクがあります。

実際の影響：リポジトリが乗っ取られると、‘git submodule update –init’や‘git subtree pull’コマンド実行時に悪意あるコードが導入される可能性があり、特に古いコミットに固定されたサブモジュールは重要なセキュリティアップデートを逃している場合があります。

7. インフラプロビジョニング：TerraformとIaCモジュール

リスクベクトル：Infrastructure as Code（IaC）モジュールをGitHubから直接取得し、クラウドリソースのプロビジョニングを自動化します。

攻撃対象領域：調査では、約11万4千件のTerraformファイルと1万3千件のterragrunt.hclファイルがGitHubモジュールを参照しており、多くが可変参照（?ref=main）を使用しています。

実際の影響：侵害されたモジュールは、攻撃者の管理下にあるリソースのプロビジョニング、セキュリティホール（公開S3バケット、広範なファイアウォールルール）の作成、VMへの悪意ある起動スクリプト埋め込み、stateファイルのシークレット漏洩などを引き起こす可能性があります。

8. ビルド・アプリケーションプラグイン：コアツールの拡張

リスクベクトル：GradleのようなビルドツールやRedisのようなアプリケーションが、GitHubから直接プラグインを読み込み、コア機能を拡張します。

攻撃対象領域：分析では、約2万4千件のGradle参照と1千件のRedisプラグインがGitHub上にあり、公式プラグインマーケットプレイスに比べて審査がほとんど行われていません。

実際の影響：調査によると、一見無害なPRがGitHubホストのGradleプラグイン経由で機能を追加すると、ビルドプロセス中に環境変数が漏洩する可能性があります。

9. 開発者ワークフロー：プリコミット＆インストールフック

リスクベクトル：Gitフックやパッケージマネージャのライフサイクルスクリプトは、開発ワークフローの初期段階で自動的に実行されます。

攻撃対象領域：調査では、約7千件の.git/hookファイルがGitHubから取得され、6万5千件のnpmパッケージがpre-/post-installスクリプトを持ち、ほとんどユーザー操作なしで実行されます。

実際の影響：悪意あるnpmインストールスクリプトは認証情報を盗んだりマルウェアをインストールしたりする可能性があり、文中で言及されているESLintの侵害のような実際の攻撃例もあります。

10. クロスリポジトリトリガー：Webhookと統合

リスクベクトル：repository_dispatchイベントにより、あるリポジトリがAPI呼び出しを通じて別のリポジトリのワークフローをトリガーできます。

攻撃対象領域：分析では、約5万6千件の.github/workflowsがrepository_dispatchイベントをリッスンしており、外部トリガーへの備えが示唆されています。

実際の影響：HMAC署名検証がなければ、攻撃者がトークンを入手した場合、repository_dispatchイベントを偽造し、client_payload経由で意図しないワークフローやインジェクションベクトルをトリガーできる可能性があります。

GitHubの利点を活用しつつ自衛するには

これらのベクトルは、従来の依存関係スキャンから包括的なサプライチェーンガバナンスへの転換を要求します。組織はSDLC全体でのGitHub参照を棚卸しし、不変な固定参照の標準化、整合性検証の実施、一般的な外部依存関係に対する安全な社内代替手段の開発が必要です。サイバーセキュリティ担当者は、開発者が未検証でリスクのあるGitHubホストコードに頼らなくて済むよう、事前に安全なインフラを用意する必要があります。

これらの見落とされがちなリスクベクトルに対処することで、組織はGitHubのイノベーションを活用しつつ、相互接続されたソフトウェアエコシステムを狙う高度なサプライチェーン攻撃から守ることができます。

著者について