GitHubは公式Xで、GitHubの内部リポジトリに対する不正アクセスについて調査していると公表しました。現時点で、顧客情報に影響があったことを示す証拠は確認していないと説明しています。
現段階では、影響を受けたリポジトリの範囲、侵入経路、攻撃者、取得された可能性のある情報など、詳細は明らかにされていません。そのため、利用企業側で直ちに被害が発生したと断定する状況ではありません。
一方で、GitHubは多くの企業にとって、ソースコード管理、GitHub ActionsによるCI/CD、パッケージ公開、クラウド連携、シークレット管理、外部委託先との開発連携の中核です。公式な追加情報を待ちつつ、自社GitHub環境の監査ログやシークレット、トークン、外部連携アプリの状態を確認しておくことが重要です。
この記事のサマリー
- GitHubは、内部リポジトリへの不正アクセスについて調査していると公表しました。
- 現時点で、顧客情報への影響を示す証拠は確認されていません。
- 影響範囲、侵入経路、攻撃者、取得された情報の詳細はまだ公表されていません。
- GitHubを利用する企業では、監査ログ、Personal Access Token、GitHub Actions Secret、Deploy Key、GitHub App、OAuth App、外部委託先アカウントを確認する必要があります。
- 便乗したフィッシングメールや偽のGitHubセキュリティ通知にも注意が必要です。
続報:GitHubのソースコードが不正アクセスによるサイバー攻撃でダークウェブで売りに出される-TeamPCPが犯行声明
目次
GitHub内部リポジトリとは
GitHub内部リポジトリとは、GitHub自身がサービス開発や運用、検証、社内ツール、インフラ管理などに利用しているリポジトリを指すと考えられます。
一般に、内部リポジトリには製品コードだけでなく、ビルド設定、テストコード、CI/CDワークフロー、インフラ構成、運用スクリプト、開発ドキュメントなどが含まれる可能性があります。ただし、今回の件で具体的にどの種類のリポジトリが影響を受けたかは、現時点で公表されていません。
重要なのは、内部リポジトリへの不正アクセスが確認されたとしても、それだけで利用企業のプライベートリポジトリや顧客データに影響が及んだと判断することはできない点です。GitHubは現時点で、顧客情報への影響を示す証拠は確認していないとしています。
何が起きたか
GitHubは公式Xで、内部リポジトリへの不正アクセスについて調査していると公表しました。
同社は、現時点で顧客情報への影響を示す証拠は確認していないと説明しています。影響範囲や詳細については、今後の公式発表を確認する必要があります。
現時点では、利用企業側で自社リポジトリが侵害された、GitHub Actions Secretが漏えいした、顧客データが流出した、と判断できる情報は確認されていません。したがって、過度に断定した対応ではなく、公式発表を確認しながら、自社環境の監査と予防的な確認を進める段階です。
GitHubが続報、従業員端末が悪意あるVS Code拡張機能で侵害
GitHubはその後の続報で、内部リポジトリへの不正アクセスに関する調査状況を公表しました。
GitHubによると、同社は従業員のデバイスがVS Code拡張機能によって侵害されたことを検知し、封じ込めを実施しました。また、悪意のある拡張機能のバージョンを削除したと説明しています。
現時点でGitHubは、今回の活動はGitHub内部リポジトリのデータ流出に限定されると判断しているとしています。攻撃者が主張する約3,800件のリポジトリ流出という数字については、これまでの調査結果と概ね一致していると説明しています。
一方で、GitHubは顧客情報への影響について、これまでの公表と同様に、顧客情報への影響を示す証拠は確認されていないとしています。利用企業側で直ちに自社リポジトリや顧客データが侵害されたと判断できる状況ではありません。
企業が注意すべき点
GitHubは単なるソースコード保管場所ではありません。
多くの企業では、GitHubにソースコード、インフラ構成、GitHub Actionsワークフロー、Terraform、Kubernetesマニフェスト、Dockerfile、デプロイ手順、外部SaaS連携設定などが集約されています。さらに、GitHub Actions SecretやEnvironment Secretには、クラウド認証情報、npmトークン、Dockerレジストリ認証情報、Slack Webhook、Sentry DSN、Vaultトークン、SSH秘密鍵などが保存されている場合があります。
GitHub公式ドキュメントでは、認証情報漏えいが疑われる場合、監査ログでトークンに関連する操作を確認し、secret scanning alertsやコード検索を使って、コード、.env、設定ファイル内の露出を調べることが推奨されています。
今回の件で顧客情報への影響が確認されていないとしても、GitHubを中核にした開発基盤では、アカウント侵害やシークレット漏えいが起きると、クラウド環境、CI/CD、パッケージ公開、社内APIへ横展開される可能性があります。
関連記事
即時対応:情報システム・開発部門が確認すべきポイント
Step 1:GitHub公式の続報を確認する
まず、GitHub公式X、GitHub Blog、GitHub Status、GitHub Enterprise管理者向け通知を確認してください。
現時点では、GitHubが内部リポジトリへの不正アクセスを調査していること、顧客情報への影響を示す証拠は確認していないことが公表されている段階です。
未確認情報やSNS上の投稿だけで判断せず、GitHubの公式発表を基準にしてください。
Step 2:自社GitHub Organizationの監査ログを確認する
GitHub Enterprise、GitHub Organizationを利用している場合は、監査ログを確認してください。
確認すべき項目は以下です。
| 確認項目 | 見るべき内容 |
|---|---|
| ログイン | 不審なIP、通常と異なる国・地域、深夜帯のアクセス |
| 権限変更 | Organization Owner、Repository Admin、外部コラボレーターの追加・変更 |
| トークン | Personal Access Token、fine-grained tokenの新規作成や権限変更 |
| Deploy Key | 新規Deploy Key、不要なSSH Keyの追加 |
| GitHub App | 新規インストール、権限スコープの変更 |
| OAuth App | 不審なOAuth連携、過剰な権限付与 |
| リポジトリ操作 | 大量clone、visibility変更、未知のリポジトリ作成 |
| Actions | 不審なworkflow実行、workflowファイル変更、Secrets変更 |
GitHub公式ドキュメントでも、アカウント侵害が疑われる場合は、メンバー追加、権限変更、Deploy KeyやAppの作成、リポジトリの公開設定変更、予期しないpushやforce pushを確認するよう案内されています。
Step 3:GitHub Actions SecretとEnvironment Secretを棚卸しする
GitHub Actionsに保存しているシークレットを棚卸ししてください。
特に、以下のような長期有効な認証情報は注意が必要です。
| 種別 | 例 |
|---|---|
| クラウド | AWS Access Key、GCP Service Account、Azure Client Secret |
| パッケージ | npm token、PyPI token、Docker Hub token、GitHub Packages token |
| インフラ | Kubernetes kubeconfig、Vault token、SSH秘密鍵 |
| SaaS | Slack Webhook、Sentry、Datadog、Stripe、SendGrid |
| データベース | PostgreSQL、MySQL、MongoDB、Redis接続文字列 |
すぐに全シークレットをローテーションする必要があると断定できる段階ではありません。ただし、強い権限を持つ長期トークン、退職者や委託先が作成したトークン、用途不明のSecretは、この機会に整理してください。
Step 4:Personal Access TokenとGitHub Appを確認する
Personal Access Token、GitHub App、OAuth Appは、GitHub環境の侵害で狙われやすいポイントです。
確認すべき内容は以下です。
- 長期間使われていないPersonal Access Tokenが残っていないか
- classic PATが残っていないか
- fine-grained tokenで必要最小限の権限になっているか
- GitHub Appに過剰な権限が付与されていないか
- OAuth Appが不要なOrganizationアクセスを持っていないか
- 外部委託先や退職者が作成したトークンが残っていないか
GitHubをクラウドデプロイやパッケージ公開に使っている場合、トークン侵害は単なるリポジトリ閲覧にとどまらず、デプロイや成果物配布への影響につながります。
Step 5:重要リポジトリのアクセス権限を見直す
重要リポジトリについて、以下を確認してください。
| 項目 | 確認内容 |
|---|---|
| 管理者権限 | Owner、Adminが必要最小限か |
| 外部コラボレーター | 業務終了済みの委託先が残っていないか |
| ブランチ保護 | main、releaseブランチに直接pushできないか |
| 必須レビュー | 重要ファイル変更にレビューが必須か |
| Actions権限 | Fork PRや外部コードが高権限で実行されないか |
| Secret利用範囲 | 全リポジトリ共通Secretが過剰でないか |
特に、.github/workflows/配下の変更は重点的に確認してください。GitHub公式ドキュメントでも、悪意あるコードやワークフロー変更が疑われる場合、Actionsタブ、workflow実行ログ、.github/workflows/、シェルスクリプト、設定ファイルの不審な変更を確認するよう説明されています。
Step 6:便乗フィッシングに注意する
今回の話題に便乗し、GitHub、GitHub Security、Microsoft、開発基盤の管理者を装ったメールやDMが送られる可能性があります。
特に以下の文面には注意してください。
- GitHubアカウント確認が必要
- トークンを再発行してください
- リポジトリ漏えいの確認はこちら
- セキュリティ警告に対応してください
- GitHub Actions Secretを再登録してください
- OAuth Appの再認証が必要です
ログインや認証情報入力を求めるリンクは、メールやSNSから開かず、ブラウザのブックマークや公式管理画面から確認してください。
CI/CD・クラウド環境で確認すべき設定
GitHub Actionsを利用している場合、CI/CDの権限分離を確認してください。
依存関係のインストール、テスト、ビルド、デプロイ、パッケージ公開を同じワークフローで実行し、すべてのジョブに強いシークレットを渡している構成は危険です。
確認すべきポイントは以下です。
| 項目 | 確認内容 |
|---|---|
GITHUB_TOKEN |
permissionsが必要最小限か |
| OIDC | クラウド側のAssumeRole条件がリポジトリ・ブランチ単位で限定されているか |
| Secrets | PR検証ワークフローに本番Secretが渡っていないか |
| Self-hosted runner | 外部PRや不審コードが自己ホストランナーで動かないか |
| Artifact | ビルド成果物にシークレットや設定ファイルが含まれていないか |
| ログ | set -xやデバッグ出力でSecretが漏れていないか |
GitHub公式ドキュメントでは、データ持ち出しが疑われる場合、大量のgit.cloneやgit.fetch、APIリクエスト、リポジトリのvisibility変更、未知のwebhook作成などを確認するよう案内されています。
今回の件で直接の顧客影響は確認されていませんが、GitHubを経由したソフトウェアサプライチェーン攻撃は継続的に発生しています。CI/CD環境に保存しているトークンやクラウド権限は、侵害された場合の影響範囲を基準に見直してください。








