← 国内の記事一覧へ

セキュリティノート

サイバーセキュリティクラウドGitHubに不正アクセス、顧客情報漏えいの恐れ

分類:攻撃手法認証情報の悪用対象技術開発基盤・CI/CDインシデント種別不正アクセスインシデント種別個人情報漏えい

要点

発表された事実

  • サイバーセキュリティクラウド(東証グロース、4493)は2026年11月12日、ソフトウェア開発に使うGitHub上の同社管理領域への不審なアクセスを確認し、保存されていた個人情報に漏えいの恐れがあると発表した(サイバーセキュリティクラウド)。
  • 外部機関からの情報提供で、従業員が業務で使っていたGitHubの認証情報1件が外部に流出していたことがわかった。アクセスログを調べ、その認証情報を使った第三者によるとみられる過去の不審なアクセスを11月5日に確認した(同)。
  • 確認できるアクセスログの期間や記録内容に制約があり、認証情報が有効だった期間全体のアクセス状況は確認できていない(同)。
  • 漏えいの恐れがあるのは、一部の顧客に関する情報(企業名、氏名、メールアドレス等)と「サービス利用に伴う通信関連情報」。範囲と対象者は調査中(同)。
  • 本件に起因するサービスへの不正アクセスや不正操作、二次被害は確認されておらず、サービスとセキュリティ機能への影響もないとしている(同)。

わかっていないこと

  • 認証情報が流出した原因と経路(端末の感染か、どこかへの誤掲載かなど)。
  • 流出した認証情報の種類(パスワード、個人用アクセストークン、SSH鍵など)と、有効だった期間。
  • 「通信関連情報」の具体的な中身と、対象となる顧客・人数。
  • GitHub上に保存されていた他サービスの認証情報が悪用されたかどうか。
  • 外部専門機関によるフォレンジック調査の結果。

関係しそうな既知の手口

  • (考察)開発基盤の認証情報を足がかりにした侵入は国内でも続いている。ラクスルやShippioでは認証情報の悪用が、チームスピリットでは開発用サーバーへの侵入が公表された。

この記事では、公式発表・報道で確認できた内容を「事実」、筆者の推測や意見を「考察」として分けて書いています。確認できなかった情報は書いていません。

何が起きたか(時系列)

日付出来事出典
不明従業員のGitHub認証情報1件が外部に流出サイバーセキュリティクラウド
不明(過去)流出した認証情報を使ったとみられる不審なアクセス同
2026-11-05外部機関からの情報提供を受けてログを調べ、不審なアクセスを確認同
2026-11-12第一報を公表(適時開示)同、適時開示PDF

発表内容の整理

事実(11月12日の第一報による)

項目内容
対象開発に使うGitHub上の同社管理領域
きっかけ外部機関からの情報提供(従業員のGitHub認証情報1件の流出)
漏えいの恐れがある情報一部顧客の企業名、氏名、メールアドレス等/サービス利用に伴う通信関連情報
件数・対象者調査中
サービスへの影響確認されていない(通常どおり提供)
実施済みの対応流出した認証情報の無効化、GitHub上の他サービスの認証情報の確認・変更、関連する認証情報と権限の見直し、関係する開発端末の隔離とアカウント停止
調査社内のセキュリティエンジニアと外部専門機関によるフォレンジック調査
報告個人情報保護委員会などに報告済み。委託元顧客の報告は連名報告を含め相談中

出典:サイバーセキュリティクラウド「当社開発環境における情報漏えいのおそれに関するお知らせとお詫び(第一報)」(2026-11-12)

考察

  • 本来ソースコードを置く場所に、顧客の企業名や氏名、通信に関する情報が置かれていたことが今回の被害範囲を広げている。テスト用のデータや設定ファイル、ログをリポジトリに入れてしまう運用は珍しくなく、どの種類のファイルだったのかが今後の焦点になる。
  • 同社が「GitHub上に保存されていた、他のサービスに関する各種認証情報」を変更したと書いていることから、リポジトリ内に他サービスの鍵やパスワードもあったことがうかがえる。漏れた認証情報が1件でも、そこから読める秘密情報が多ければ影響は連鎖する。
  • ログの保存期間の制約で「有効だった期間全体」を確認できていない点は、GitHubの監査ログやクローン履歴の保持期間を事前に延ばしておく重要性を示している。
  • WAFなどを提供する企業の開発環境である以上、顧客は自社の設定情報やWAF経由の通信情報が含まれていないかを気にするはずで、「通信関連情報」の具体的な説明が求められる。

利用者・運用者がいまできること

  • 顧客企業:同社からの個別連絡を確認し、同社サービスに登録している管理者アカウントのパスワード変更や多要素認証の有無を見直す。同社を装った不審なメールにも注意する。
  • 開発組織一般:GitHubの個人用アクセストークンやSSH鍵の棚卸しを行い、有効期限と権限範囲を絞る。組織単位でSSOと多要素認証を必須にする。
  • リポジトリに顧客データや本番の秘密情報を置かない。シークレットスキャンを有効にし、過去の履歴に残った秘密情報も無効化する。
  • 監査ログを外部に転送し、保持期間を長めに確保しておく。

参考リンク

原文をGitHubで読む ↗

あわせて読む

ギフティ「giftee」 ― 認証基盤への不正アクセスで主要機能を停止