Webセキュリティサービスを提供するサイバーセキュリティクラウドが、2026年11月12日に「当社開発環境における情報漏えいのおそれに関するお知らせとお詫び（第一報）」を公表しました。従業員が業務で使っていたGitHubの認証情報1件が外部に流出し、GitHub上の同社管理領域に保存されていた一部顧客の企業名・氏名・メールアドレス等に漏えいのおそれがあるという内容です。本記事の前半では、公式発表で確かめられる経緯・漏えい項目・対応と、同社サービスの利用企業が進める報告と鍵の入れ替えを整理します。後半は開発者向けに、GitHubの監査ログで流出トークンの利用履歴を洗い出す方法と、そのログに残らない範囲、リポジトリに残るシークレットを見つけて一括で失効させる手順をコマンド例で示します。
まとめ：サイバーセキュリティクラウド不正アクセスの公表事実と読者別の対応
発端は不正侵入ではなく、認証情報の流出です。外部機関の情報提供で流出が分かり、GitHubのアクセスログを調べた結果、第三者とみられる不審なアクセスが過去にあったことを11月5日に確認しています。
| 項目 | 公表内容（2026年11月12日・第一報） |
|---|---|
| 発覚の契機 | 外部機関からの情報提供 |
| 流出したもの | 従業員が業務で使うGitHubの認証情報1件 |
| 不審なアクセスの確認日 | 11月5日（アクセス自体は過去に発生） |
| 漏えいのおそれ | 一部顧客：社名・氏名・メール等、通信関連情報 |
| 件数・対象者 | 調査中（対象者には順次案内） |
| サービスへの影響 | 不正アクセス・二次被害は確認されず、通常提供 |
| 個人情報保護委員会 | 報告済み（委託元との連名報告を相談中） |
同社サービスの利用企業は、案内を待つ間に、自社が預けた個人データとAPIキー等の有無を棚卸ししておくと報告判断が早まります。GitHubを使う開発組織にとっての教訓は、監査ログの保持期間を過ぎた操作は後から確かめられない点です。流出に備えるなら、ログを外部に残す設定と、リポジトリに顧客データや鍵を置かない運用を先に整えます。
公式発表で確かめるGitHub認証情報流出の経緯・漏えい項目・対応状況
外部機関の情報提供から11月5日の不審アクセス確認までの公表済み経緯
サイバーセキュリティクラウドのお知らせと、同日の適時開示（第一報）によると、流れは「外部機関からの情報提供で認証情報1件の流出が判明」「GitHubのアクセスログを調査」「第三者とみられる不審なアクセスが過去に行われていたことを11月5日に確認」の順です。
注目すべきは次の一文です。公表文は「確認可能なアクセスログの対象期間や記録内容には制約があるため、当該認証情報が有効だった期間全体のアクセス状況を確認するには至っておりません」と書いています。流出した時期と、認証情報が使われ始めた時期は明らかにされていません。
顧客の企業名・氏名・メールアドレスと通信関連情報に分かれる漏えい項目
漏えいのおそれがあるのは、同社のGitHub上に保存されていた2種類の情報です。1つは一部の顧客に関する情報で、企業名・氏名・メールアドレス等とされています。もう1つは「サービス利用に伴う通信関連情報」です。
通信関連情報の中身は公表されていません。同社は受託して扱う個人情報について、委託元の顧客と連携して本人への通知を進めるとしています。対象と確認された顧客には順次案内が届く予定で、現時点で件数は出ていません。
認証情報の無効化・端末隔離・フォレンジックまで公表された対応一覧
実施済みとして挙げられた被害拡大防止策は次の4つです。
- 流出したGitHub認証情報の無効化
- GitHub上に保存されていた、他のサービスに関する各種認証情報の確認・変更
- 関連する各種認証情報およびアクセス権限の見直し・変更
- 関係する開発端末の隔離およびアカウントの利用停止
2つ目の項目から、GitHub上には他サービスの認証情報も置かれていたと読み取れます。リポジトリに入った鍵は、GitHubの認証情報1件を入口に、別のシステムへ広がる経路となるため危険です。調査はアクセスログの解析と、社内のセキュリティエンジニアおよび外部専門機関によるフォレンジックで続いています。
サイバーセキュリティクラウドの利用企業が今週確かめる通知・報告・鍵の棚卸し
委託元として個人情報保護委員会へ報告する期限と連名報告の相談
同社に個人データの取り扱いを委託している企業は、委託元として報告の要否を判断する立場にあります。同社は委託元による報告手続きについて、連名報告を含めた方法を相談中で、詳細が決まり次第案内するとしています。
期限の目安は個人情報保護委員会の「漏えい等の対応」に示されています。速報は発覚日から3〜5日以内、確報は30日以内で、不正な目的で行われたおそれがある場合は60日以内です。第三者による不正アクセスは「不正の目的をもって行われたおそれ」の類型に当たりうるため、件数が1,000人以下でも報告対象から外れるとは限りません。対象4類型と速報の書き方は個人情報保護委員会への報告義務の解説にまとめています。
連携時に預けたAPIキーやアカウントを予防的に入れ替える判断基準
公表文は、同社サービスへの不正アクセスやセキュリティ機能への影響は確認されていないとしています。それでも、導入時に自社のクラウドアカウントのAPIキーや連携用アカウントを同社に渡した企業は、入れ替えを検討する価値があります。理由は、同社がGitHub上の「他のサービスに関する各種認証情報」を確認・変更したと公表しているためです。
判断の線引きは単純です。同社側に長期有効な鍵を渡しているなら、案内を待たずに新しい鍵を発行し、古い鍵は失効させてください。有効期限の短いトークンや、自社側で信頼関係を設定するロール連携だけなら、入れ替えを急ぐ必要性は、長期有効な鍵を渡している場合より小さいという判断です。どちらの場合も、渡した鍵の一覧と発行日をAPIキーの発行・保管・失効の手順に沿って記録しておくと、続報が出たときに判断が早まります。社名と氏名・メールアドレスが漏れたおそれがあるため、同社や取引先を装った問い合わせメールにも注意が要ります。
GitHubの監査ログで流出トークンの利用履歴を洗い出す手順とログの限界
Organization監査ログ180日・Gitイベント7日という保持期間の制約
公表文の「アクセスログの対象期間や記録内容には制約がある」という説明を、GitHub側の仕様で読み解きます。同社がどの仕組みでログを調べたかは公表されていないため、以下はGitHubの一般仕様です。
| ログの種類 | 保持期間 | 出典 |
|---|---|---|
| Organization・Enterprise監査 | 過去180日 | GitHub Docs |
| 監査ログのGitイベント | 7日 | GitHub Docs（Enterprise） |
| 個人アカウントのセキュリティログ | 過去90日 | GitHub Docs |
企業の監査ログの説明には「監査ログには、Git イベントが 7 日間保持されます」とあります。リポジトリの複製（clone）や取得（fetch）はGitイベントに当たるため、流出から気付くまでに7日以上空くと、何がどこまで持ち出されたかを監査ログだけでは確かめられません。組織の監査ログの確認方法によれば、REST APIやGraphQL APIでの監査ログ操作はGitHub Enterprise Cloudの組織に限られます。
トークンのハッシュ値で監査ログを検索するコマンドとREST API例
流出したトークンの値が分かっている場合、そのトークンで行われた操作だけを監査ログから抜き出せます。アクセストークンによる監査ログイベントの識別に沿うと、トークンのSHA-256ハッシュをBase64にした値を hashed_token で検索します。対象はpersonal access token・OAuthトークン・GitHub Appsのトークンなどです。
# 1. 流出したトークンを画面に表示せずに読み込む（シェル履歴に残さない）
read -rs LEAKED_TOKEN
# 2. SHA-256 ハッシュを Base64 で求め、URL 用にエスケープする
HASH=$(printf '%s' "$LEAKED_TOKEN" | openssl dgst -sha256 -binary | base64)
ENC=$(python3 -c 'import sys, urllib.parse; print(urllib.parse.quote(sys.argv[1], safe=""))' "$HASH")
# 3. Organization の監査ログを hashed_token で検索（GitHub Enterprise Cloud・組織オーナーのトークンで実行）
curl -s \
-H "Accept: application/vnd.github+json" \
-H "Authorization: Bearer $ADMIN_TOKEN" \
-H "X-GitHub-Api-Version: 2026-03-10" \
"https://api.github.com/orgs/your-org/audit-log?phrase=hashed_token:%22${ENC}%22&per_page=100"
上記は公式ドキュメントのエンドポイントとヘッダに基づく例で、本稿の執筆環境では実行していません。your-org は自社の組織名に置き換えてください。返ってくる各イベントには hashed_token・programmatic_access_type・token_scopes が入り、どの権限で何をしたかを追えます。トークンの値が分からない場合は、流出した従業員のアカウントを actor: で、期間を created: で絞って同じ検索をかけます。
Gitイベントを7日より長く残すための監査ログストリーミング設定
UIとREST APIの検索ではGitイベントは返されません。公式ドキュメントは、Gitイベントを調べるには監査ログをエクスポートし、出力に含まれる認証情報のフィールドを確認するよう案内しています。つまり事故が起きてから慌てて検索しても、cloneの記録は出てこないのです。
対策は事前の設定だけです。Enterprise Cloudでは監査イベントとGitイベントを外部のデータ管理システムへストリーミングでき、保持期間を自社で決められます。Enterpriseプランを使っていない組織は、少なくとも個人アカウントのセキュリティログが90日しか残らないことを前提に、退職・異動時のトークン棚卸しを運用に組み込んでおきます。
リポジトリに残る顧客データとシークレットを探して失効させる作業手順
gitleaksでGit履歴全体からトークンと鍵を検出するコマンド
流出したGitHubアカウントから読める範囲に、他サービスの鍵が残っていないかを確かめます。現在のファイルだけでなく、過去のコミットに残った鍵も対象です。オープンソースのgitleaksは gitleaks git で、内部的に git log -p を使って履歴を走査します。READMEは同ツールを機能完成（feature complete）と宣言しており、今後はセキュリティ修正のみの提供です（2026年11月12日時点）。
# 全ブランチの履歴を走査し、結果を JSON で保存する（検出時は終了コード 1）
gitleaks git -v --log-opts="--all" --report-format json --report-path leaks.json .
# 検出された種類（RuleID）ごとの件数を確かめる
jq -r '.[].RuleID' leaks.json | sort | uniq -c | sort -rn
出力の leaks.json には鍵の値そのものが入るため、調査用の端末から外に出さず、作業後には必ず削除してください。GitHub側の機能では、シークレットスキャンが全ブランチのGit履歴全体を走査します。組織所有のプライベートリポジトリで使うにはGitHub Secret Protectionの有効化が要り、料金はGitHub Advanced Securityの料金解説で整理しています。
git log -pでメールアドレスなど個人情報が残るコミットを探す方法
今回の事案で漏えいのおそれがあるのは、鍵よりも顧客の氏名やメールアドレスです。gitleaksは鍵の検出に特化しているため、個人情報は別に探します。
# 履歴全体からメールアドレスらしき文字列を抜き出し、出現回数の多い順に並べる
git log --all -p | grep -Eo '[[:alnum:]._%+-]+@[[:alnum:].-]+[.][[:alpha:]]{2,}' | sort | uniq -c | sort -rn | head -n 30
# 過去に一度でもコミットされた CSV・Excel・SQL ダンプのファイル名を洗い出す
git log --all --name-only --format= | grep -Ei '[.](csv|xlsx|sql|dump)$' | sort -u
1つ目の結果には、コミット作者のアドレスや noreply のアドレスも含まれるため、すべてが顧客情報とは限りません。件数が数百を超えるアドレス群や、社外ドメインが並ぶ行があれば、テストデータとして本番の顧客情報を入れた跡を疑います。見つかったファイルは、どのコミットで入りどのブランチに残るかを記録し、影響範囲の特定に回します。
credentials/revokeで見つかったGitHubトークンを一括失効させる手順
履歴から見つかったGitHubのトークンは、持ち主が誰であっても認証情報の無効化APIで失効させられます。対象は ghp_（classic PAT）・github_pat_（fine-grained PAT）・gho_・ghu_・ghr_ で始まるトークンです。このAPIは認証なしで呼び出し、認証付きで送ると403になります。
# gitleaks の結果から GitHub トークンだけを取り出し、重複を除いて API の形式にする
jq -r '.[].Secret | select(test("^(ghp_|github_pat_|gho_|ghu_|ghr_)"))' leaks.json | sort -u \
| jq -R -s '{credentials: (split("\n") | map(select(length > 0)))}' > revoke.json
# 失効させる（Authorization ヘッダは付けない。1回 1000 件まで、1時間 60 回まで）
curl -s -X POST \
-H "Accept: application/vnd.github+json" \
-H "X-GitHub-Api-Version: 2026-03-10" \
https://api.github.com/credentials/revoke \
-d @revoke.json
受け付けられると202が返り、トークンの持ち主への通知も行われる仕組みです。失効したトークンは元に戻せないため、CIや本番が使っているトークンが含まれていないかを先に確かめ、代わりの鍵を用意してから実行します。GitHub以外の鍵（クラウドのアクセスキーやデータベースのパスワード）は、それぞれのサービスの管理画面で入れ替えます。
開発基盤の認証情報1件で顧客データが漏れない構成と見直しの優先順位
classic PATを組織で禁止しfine-grainedに承認と期限を課す設定
最初に手を付けるのは、組織の個人用アクセストークンのポリシーです。組織のPATポリシーの設定では、classic PATによる組織リソースへのアクセスを制限でき、最大有効期間も決められます。既定ではclassic PATに有効期限の要件はなく、fine-grained PATは366日以内に切れる設定です。
推奨はclassic PATの禁止、fine-grained PATの管理者承認必須、有効期限90日以内の3点です。ポリシーを変えても既存のトークンは取り消されないため、設定後に組織の承認済みトークン一覧を見て、不要なものを手で取り消します。classicとfine-grainedの違いと失効の操作はGitHub PATの作成・確認・失効の解説を参照してください。ただし、少人数で外部連携がほとんど無いリポジトリに承認フローを入れると、申請待ちで開発が止まる場面が増えます。メンバーが5人以下で顧客データを扱わない組織なら、承認必須は見送り、有効期限だけを短くする運用で十分です。
顧客データとテスト用の本番コピーをリポジトリに置かない運用の線引き
今回の事案で漏えいのおそれが生じたのは、GitHub上に顧客情報が保存されていたためです。認証情報の流出は完全には防げません。防げるのは、流出したときに読まれる中身を減らすことです。
線引きは「リポジトリには、公開されても顧客に連絡せずに済むものだけを置く」という基準です。テストデータは架空の値で作り、本番データの複製はリポジトリではなくアクセス記録が残るストレージに置きます。CIで使う鍵はGitHub ActionsのSecretsに移すか、GitHub ActionsのSecrets管理とOIDC移行の判断で示した短命な認証に切り替えます。例外として設定ファイルに鍵を直書きしたままの古いリポジトリが残っているなら、それは運用ではなく構成の問題です。自社だけで履歴と権限を点検しきれない場合は、脆弱性診断・セキュリティ診断で開発基盤を含めた第三者の点検を受ける方法もあります。
よくある質問
サイバーセキュリティクラウドの不正アクセスについて、検索されることの多い疑問に、2026年11月12日時点の公表内容をもとに答えます。
サイバーセキュリティクラウドの不正アクセスで漏れた可能性がある情報は何ですか？
同社のGitHub上に保存されていた、一部顧客の企業名・氏名・メールアドレス等と、サービス利用に伴う通信関連情報です。第三者に閲覧・取得された可能性を否定できないとして「漏えいのおそれ」と公表されており、漏えいが確定したわけではありません。範囲と対象者は調査中で、確認できた顧客には順次案内するとしています。
サイバーセキュリティクラウドのサービスは使い続けて大丈夫ですか？
第一報では、本件に起因するサービスへの不正アクセスや不正な操作、二次被害は確認されておらず、セキュリティ機能への影響もないとされています。各サービスは通常どおり提供されています。ただし調査は続いているため、第二報で範囲が変わらないかを確認し、同社に長期有効な鍵を渡している場合は予防的な入れ替えを検討してください。
自社が対象かどうかはどうすれば分かりますか？
対象と確認された顧客には同社から順次案内が届く予定です。案内を待つ以外に、顧客・パートナー向けの問い合わせ窓口が公表文に記載されています。委託元として個人情報保護委員会への報告が必要になる場合に備え、同社に渡している個人データの種類と人数を先に洗い出しておくと、案内が届いてからの判断が早まります。
GitHubの認証情報が漏れたら最初に何をすればよいですか？
最初に流出したトークンやパスワードを失効させ、次にそのアカウントから読めたリポジトリに他サービスの鍵が残っていないかを確かめます。鍵が見つかれば、それぞれのサービスで入れ替えます。監査ログのGitイベントは7日しか残らないため、cloneの記録を確かめたい場合は失効と並行して早めにエクスポートしてください。
GitHubの監査ログはどのくらい前まで確認できますか？
Organization・Enterpriseの監査ログは過去180日、そのうちGitイベントは7日、個人アカウントのセキュリティログは過去90日です。REST APIやGraphQL APIで監査ログを扱えるのはGitHub Enterprise Cloudの組織に限られます。7日を超えてGitイベントを残すには、監査ログを外部へストリーミングする設定が事前に必要です。
関連記事
- マネーフォワードの銀行連携は危険？いつ復旧したかと不正アクセス事案の全容：同じくGitHubへの不正アクセスが起点になった2026年の事案
- API不正アクセス対策の実装手順：JPCERT注意喚起に沿うレート制限・認可・トークン失効とアプリ解析・SSRF対策：漏れたトークンを使わせないAPI側の防御
- 情報漏洩対策とは：原因別4類型の防ぎ方と発生時の報告義務【2026年10月版】：委託先経由を含む漏えいの防ぎ方
- APIキー管理とは？発行・保管・失効とローテーションの実装を解説：預けた鍵の棚卸しと入れ替えの手順
- GitHub PAT（Personal Access Token）とは？作成方法・classicとfine-grainedの違い・確認と失効【2026年10月】：トークンの種類と失効操作の基本
