セキュリティ情報漏洩のニュースサイトセキュリティ対策Labの運営とBtoB マーケティングコンサル支援|合同会社ロケットボーイズ

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は顧客情報への影響について、これまでの公表と同様に、顧客情報への影響を示す証拠は確認されていないとしています。利用企業側で直ちに自社リポジトリや顧客データが侵害されたと判断できる状況ではありません。 利用企業が追加で確認すべきポイント 今回の続報で、VS Code拡張機能が侵害経路として示された点は重要です。GitHubを利用する企業では、GitHub側の続報確認に加え、自社の開発端末と拡張機能管理を確認する必要があります。 Step 1：VS Code拡張機能の棚卸し 開発者端末に導入されているVS Code拡張機能を棚卸ししてください。 特に、以下を確認する必要があります。 確認項目 内容 導入済み拡張機能 業務上必要なものか 提供元 公式・信頼できる発行元か 権限 ワークスペース、ファイル、ターミナル、Git、認証情報へ過剰にアクセスしていないか 更新履歴 直近で不自然な更新がないか 類似名 有名拡張機能に似せた別物が入っていないか 未使用拡張 長期間使っていないものが残っていないか VS Code拡張機能は利便性が高い一方で、開発者端末上のコードや設定に触れるため、通常のブラウザ拡張機能や業務アプリよりも慎重に管理する必要があります。 Step 2：拡張機能の許可リスト化 企業利用では、VS Code拡張機能を開発者任せにせず、許可リスト方式で管理することが望まれます。 特に、本番リポジトリ、クラウド認証情報、CI/CD設定、顧客データを扱う開発端末では、以下を検討してください。 対策 内容 許可リスト 利用可能な拡張機能を限定 禁止リスト 危険または出所不明な拡張機能を禁止 バージョン固定 業務上重要な拡張機能の更新を管理 自動更新制御 拡張機能の自動更新によるリスクを抑制 MDM管理 端末単位でインストール状況を把握 開発端末EDR 拡張機能起点の不審プロセスを検知 Step 3：開発端末上の認証情報を確認 悪意ある拡張機能が導入された場合、ローカル端末上の認証情報が狙われる可能性があります。 確認対象は以下です。 種別 例 GitHub Personal Access Token、GitHub CLI認証情報、SSH鍵 クラウド AWS、GCP、Azureのローカル認証情報 パッケージ npm、PyPI、Docker Hub、GitHub Packagesのトークン インフラ kubeconfig、Vault token、Terraform state 開発ツール .npmrc、.pypirc、.gitconfig、.ssh/config AI開発ツール コーディング支援ツールやエージェントの設定ファイル 開発端末に本番環境へアクセスできる長期トークンが保存されている場合、拡張機能侵害時の影響が大きくなります。可能な限り、短命トークン、OIDC、SSO、端末証明書、条件付きアクセスへ移行すべきです。 Step 4：GitHub監査ログとActionsログを確認 GitHubを利用している企業では、引き続き監査ログを確認してください。 特に以下を確認します。 確認項目 内容 リポジトリ操作 不審なclone、fork、visibility変更 権限変更 Owner、Admin、外部コラボレーターの追加 トークン PAT作成、fine-grained token作成、権限変更 Deploy Key 新規追加や用途不明の鍵 GitHub App 新規インストール、権限拡大 Actions workflow変更、Secret変更、不審な実行 Webhook 不審な送信先の追加 今回の事案で顧客環境への影響は確認されていませんが、GitHubは開発基盤の中核であり、平時から監査できる状態にしておく必要があります。 Step 5：便乗フィッシングに注意 GitHubが内部リポジトリ不正アクセスの調査を進めていることに便乗し、GitHubやMicrosoftを装ったフィッシングが発生する可能性があります。 以下のような文面には注意してください。 GitHub侵害に伴いアカウント確認が必要 VS Code拡張機能の再認証が必要 GitHub Tokenを再発行してください Organizationの安全確認をしてください GitHub Actions Secretを再登録してください セキュリティ調査のためログインしてください ログインや認証情報入力を求めるリンクは、メールやSNSから開かず、公式管理画面から確認してください。 企業が注意すべき点 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へ横展開される可能性があります。 関連記事 セキュリティ対策Lab：CAMPFIRE、GitHubアカウントへの不正アクセスを公表 一部ソースコードが閲覧された可能性 セキュリティ対策Lab：GitHubへの不正アクセスで顧客情報管理システムの一部で不正アクセスの痕跡 セキュリティ対策Lab：マネーフォワード、GitHubへの不正アクセスでビジネスカード情報370件・ソースコード流出の可能性 即時対応：情報システム・開発部門が確認すべきポイント 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環境に保存しているトークンやクラウド権限は、侵害された場合の影響範囲を基準に見直してください。 参考情報・出典 GitHub 公式X：内部リポジトリへの不正アクセスに関する投稿 GitHub Docs：Common security incident investigation areas

ブログ