株式会社サイバーセキュリティクラウドは2026年11月12日、ソフトウェア開発に利用するGitHub上の同社管理領域で不審なアクセスがあり、一部顧客の氏名・メールアドレスなどの情報が漏えいしたおそれがあると発表しました。従業員が業務で使用していたGitHub認証情報1件の外部流出が判明しています。
現時点では対象者・件数は調査中です。同社が提供するセキュリティサービスへの不正操作や機能への影響、二次被害は確認されておらず、サービスは通常どおり提供されています。利用企業や関係者が今すべきことを、会社の公式発表とGitHub公式資料から整理しました。
確認日：2026年11月13日／対象発表：11月12日付「第一報」。今後の調査で対象範囲が変わる可能性があります。
自分の情報は漏えい対象？ 今すべきこと
今の段階では自分や自社が対象かを誰でも検索できる一覧は公表されていません。同社は対象となることが確認された顧客に順次案内し、委託を受けて取り扱う個人情報については、委託元と連携して本人通知などを進めるとしています。
- サイバーセキュリティクラウドの利用企業：同社の公式案内を確認し、自社の契約窓口・担当者宛ての連絡を把握する。対象が判明した場合は自社の情報管理責任者や委託元・委託先との連絡体制を確認する。
- サービスの一般利用者：現在の発表だけで全員のパスワード変更が必要とはいえません。会社・サービスを装った不審なメールのリンクは開かず、必要な確認は公式サイトから行う。
- 情シス・開発担当者：自社のGitHub認証情報、リポジトリ権限、保存済みシークレット、操作ログを点検する。この点検は今回の企業の被害が自社へ波及したと断定するものではなく、同様の事故を防ぐための一般的な対策です。
顧客への案内や問い合わせ窓口については会社の公式発表を参照してください。
何が起きた？ 11月5日の確認から11月12日の公表まで
| 日付 | 確認・公表されたこと |
|---|---|
| 2026年11月5日 | 流出したと判明した認証情報を使用した、第三者によるものと考えられる過去の不審アクセスを、GitHubのログ調査で確認 |
| 2026年11月12日 | 会社が「第一報」を公表。一部の顧客情報などの漏えいのおそれ、封じ込め措置、サービス提供状況を説明 |
| 2026年11月13日時点 | 対象人数・件数、認証情報が流出した原因や経路、影響範囲の調査が継続 |
調査のきっかけは外部機関からの情報提供でした。会社は従業員の業務用GitHub認証情報1件が流出していたことを把握し、その情報による不審なアクセスを過去の記録から確認しています。11月5日はアクセスの確認日であって、侵入が始まった日ではありません。
また、同社は確認可能なログの期間・記録内容に制約があり、認証情報が有効だった期間全体のアクセス状況は確認できていないと説明しています。「調査した範囲で痕跡が見つからない」ことと「過去に一切アクセスされていない」ことは区別が必要です。
どんな情報が漏えいした可能性がある？
会社は、GitHub内の管理領域に保存していた次の情報について、第三者に閲覧・取得された可能性を否定できないとしています。情報の漏えいが確定したという発表ではありません。
| 情報の種類 | 11月12日付第一報の位置づけ |
|---|---|
| 一部顧客の企業名 | 漏えいのおそれ |
| 一部顧客の氏名・メールアドレス等 | 漏えいのおそれ |
| サービス利用に伴う通信関連情報 | 漏えいのおそれ。具体的な項目・範囲は未公表 |
| 対象人数・件数 | 調査中 |
| パスワードなど個々の顧客認証情報 | 第一報からは漏えい対象と断定できない |
「通信関連情報」が具体的に何を含むかは公表文では明示されていません。IPアドレスや通信内容など、個別のデータ項目を推測で加えるべきではありません。対象となる顧客や本人への案内は、調査結果を待って判断する必要があります。
GitHub自体が攻撃されたのか？ 認証情報1件で起こり得ること
今回、公式に説明されたのはサイバーセキュリティクラウドが管理するGitHub領域への不審アクセスです。GitHubサービス全体が侵害された、GitHubに脆弱性があった、という発表ではありません。
GitHubでは、利用者や連携システムが認証され、許可されたリポジトリや組織の情報にアクセスします。認証情報を第三者に利用されると、攻撃者が正規の利用者になりすまして、その認証情報に与えられた権限の範囲内でリポジトリや関連情報にアクセスするおそれがあります。
認証情報には、ログイン用の認証手段やアクセストークン、SSH鍵など複数の種類があります。今回流出した認証情報の具体的な種類や、どのように外部流出したかは公表されていません。したがって「PAT（Personal Access Token）が漏れた」「ソースコードがすべて抜き取られた」とは断定できません。
ただし一般論として、古い権限設定のまま有効なトークンが使われている場合、必要以上に広い範囲へアクセスされる危険があります。GitHubも個人用アクセストークンをパスワードと同様に管理し、必要最小限の権限と有効期限を設けることを推奨しています（GitHub公式：Personal access tokenの管理）。
情シス・開発担当者向け：同様の事故を防ぐ確認手順
以下はGitHubを使う組織向けの一般的な対応手順です。今回の被害企業が実際にどの認証方式を使っていたかとは切り分けて読んでください。
1. 流出の疑いがある認証情報を無効化する
認証情報の種類を特定し、影響を受けたトークン・SSH鍵・アプリ連携・セッションなどを管理者が確認します。疑わしい認証情報は速やかに失効・削除し、必要な新しい認証情報を安全な経路で再発行します。GitHubのPATなら「Settings → Developer settings → Personal access tokens」から対象を確認できます。関連するCI/CDや自動処理が停止しないよう、再設定も計画します。
2. GitHubのアクセス・監査ログを保存して調べる
個人アカウントのSecurity logに加え、組織の管理者は「Organization → Settings → Logs → Audit log」を確認します。想定外のアカウント操作、権限変更、リポジトリへのアクセス権の追加、トークン利用を調べ、必要なログを保全します。GitHub公式によると組織の監査ログには過去180日以内の対象イベントが一覧表示されますが、すべての閲覧・取得操作が必ず記録されるわけではなく、利用プランや記録種別による制約にも注意が必要です（GitHub公式：組織の監査ログ）。
3. リポジトリ内の顧客情報とシークレットを棚卸しする
ソースコードだけでなく、Issue、設定ファイル、テスト用データ、実行ログ、CI/CD設定、過去のコミット履歴に、顧客情報やAPIキー、クラウド認証情報、秘密鍵が保存されていないか確認します。認証情報が見つかった場合は、ファイルを削除するだけで済ませず、その認証情報自体を失効・ローテーションしてください。Gitの履歴に残る可能性にも留意します。
4. 外部サービスの認証情報も確認する
GitHubの権限を失効させても、取得された別サービスのAPIキーなどが残っていれば危険が続きます。対象リポジトリやワークフローから参照できたクラウド、配布基盤、監視サービス等の認証情報を洗い出し、必要に応じて変更します。調査のための証拠保全と、攻撃を止めるための失効を並行して進めます。
5. 必要最小限の権限・有効期限・漏えい防止機能を設定する
リポジトリと組織の権限は最小限にし、個人用アクセストークンには短い有効期限を設けます。長期間動作する組織の自動処理はGitHub Appへの置き換えも検討します。利用条件を確認したうえで、Secret scanningやPush protectionを使えば、対応する種類の秘密情報がGitHubへ登録されるのを検知・抑止できます（GitHub公式：Push protectionの有効化）。
6. 利用企業と委託元・委託先の連絡経路を整える
委託先の開発環境で事故が起きたとき、自社のどの情報が保存されていたか、当該情報にアクセス可能だった範囲、本人通知や監督官庁への報告を誰が担うかを整理しておくことが重要です。今回も委託元の顧客と連携し、本人通知と個人情報保護委員会への報告方法を調整するとしています。
サイバーセキュリティクラウドが実施した対策とサービスの提供状況
会社が第一報で実施済みとした対応は、次のとおりです。
- 外部に流出したGitHub認証情報を無効化
- GitHub上に保存されていた他サービスの認証情報を確認・変更
- 関連する認証情報とアクセス権限を見直し・変更
- 関係する開発端末を隔離し、アカウントの利用を停止
現在は社内のセキュリティエンジニアと外部専門機関によるログ調査・フォレンジック調査、影響する顧客情報の特定、再発防止策の見直しを進めています。個人情報保護委員会など関係機関へ報告したことも明らかにしています。
同社サービスへの不正アクセス、不正操作、二次被害、セキュリティ機能への影響は、11月12日の第一報時点で確認されていません。サービスは通常どおり継続しています。ただし、これは調査の終了や被害が絶対にないことを意味しません。
よくある質問（FAQ）
Q. GitHubを使っている人は全員パスワードを変えるべきですか？
いいえ。今回の発表からGitHub利用者全員の認証情報が流出したとはいえません。今回の対象企業と無関係なアカウントについて一律の変更が必要だという案内は出ていません。自分のGitHub認証情報に不審な履歴や漏えいの兆候があれば、個別に対処してください。
Q. サイバーセキュリティクラウドのサービスは停止していますか？
いいえ。11月12日付第一報によると、サービスおよびセキュリティ機能への影響は確認されておらず、通常どおり提供されています。
Q. 自分が情報漏えいの対象か、どう確認できますか？
現時点では対象者・件数は調査中です。会社は対象となることが確認された顧客へ順次案内するとしています。確認の際は不審なメールのリンクを使わず、公式サイトや契約時の正規窓口を利用してください。
Q. 顧客情報が流出したことは確定したのですか？
いいえ。GitHub認証情報1件の外部流出と過去の不審なアクセスは判明していますが、顧客情報については「閲覧・取得された可能性を否定できない」という段階です。対象人数や範囲も調査中です。
まとめ：対象確認と認証情報の見直しが重要
今回の事故では、従業員のGitHub認証情報1件の流出をきっかけに、企業が管理する開発環境への不審なアクセスが確認されました。顧客情報は漏えいのおそれがある一方、件数や対象はまだ確定していません。サービスは通常提供中です。
利用者は公式の続報と個別通知を確認し、情シス・開発担当者は自社のGitHubの認証情報、アクセス権、保存情報、ログ保全を点検することが実務的な対策になります。類似の事案で調査報告をまとめる際には、関連記事「JPCERT/CCの情報漏えい・ランサムウェア調査チェックリスト」も参考になります。
出典・更新履歴
- サイバーセキュリティクラウド：当社開発環境における情報漏えいのおそれに関するお知らせとお詫び（第一報）（2026年11月12日）
- GitHub Docs：個人用アクセス トークンを管理する
- GitHub Docs：あなたの組織の監査ログを確認する
- GitHub Docs：Enabling push protection for your repository
- 2026年11月13日：第一報およびGitHub公式資料を確認し、新規公開。影響人数・対象範囲・認証情報の種類は未確定。
