サイバーセキュリティクラウドのGitHub認証情報流出から考える｜委託先の「開発環境」に顧客データを置かせない仕組み

はじめに
何が起きたのか
なぜ開発基盤に「本来置かないもの」がたまるのか
発注側が持つべき仕組み
まとめ
参考

はじめに

2026年11月12日、Webセキュリティサービスを提供する株式会社サイバーセキュリティクラウドが、開発に使っているGitHub上の管理領域に不審なアクセスがあり、一部顧客の情報が漏えいしたおそれがあると公表しました。きっかけは、従業員が業務で使っていたGitHubの認証情報1件が外部に流出していたことです。

セキュリティ企業でも起きた、という点で話題になっていますが、発注側にとって本当に考えるべきなのは別の点です。それは「自社のデータが、委託先の本番環境ではなく“開発環境”に置かれていないか」という問いです。

この記事では、事案の概要を整理したうえで、なぜ開発基盤に顧客情報や認証情報がたまっていくのか、そして発注側のIT部門やDX担当者が、委託先と自社の両方でどんな仕組みを持っておくべきかを、コンサルタントの視点で考えます。

何が起きたのか

同社の第一報（2026年11月12日）と報道を整理すると、概要は次のとおりです（11月13日時点）。

発端：外部機関からの情報提供で、従業員が業務で使っていたGitHubの認証情報1件が外部に流出していたことが判明
確認：アクセスログを調べた結果、その認証情報を使った第三者によるものと考えられる不審なアクセスが過去に行われていたことを11月5日に確認
漏えいのおそれがある情報：GitHub上に保存されていた、一部顧客の情報（企業名、氏名、メールアドレス等）と、サービス利用に伴う通信関連情報
確認されていないこと：同社は「閲覧・取得された可能性を否定できない」としており、漏えいが確定したわけではありません。対象人数・範囲、流出の原因や経路は調査中です。また、確認できるアクセスログの期間や記録内容に制約があり、認証情報が有効だった期間全体のアクセス状況は確認できていないとしています
サービスへの影響：同社サービスへの不正アクセスや不正操作、二次被害は確認されておらず、サービスは通常どおり提供
対応：流出した認証情報の無効化、GitHub上に保存されていた他サービスの認証情報の確認・変更、権限の見直し、関係する開発端末の隔離とアカウント停止、外部専門機関を含むフォレンジック調査。個人情報保護委員会など関係機関へ報告済みで、委託元の顧客とは連名報告を含め報告方法を相談中

注目したいのは、不審なアクセスが確認されたのがサービスの稼働環境ではなく、ソースコードを管理する開発基盤だったこと（サービスへの不正アクセスは確認されていません）、そしてそこに顧客情報や他サービスの認証情報が保存されていたことです。

なぜ開発基盤に「本来置かないもの」がたまるのか

今回の原因は調査中なので、ここからは一般論です。私がSIer側・発注支援側の両方でプロジェクトを見てきた経験では、GitHubのようなリポジトリには、次のような理由で「本来置かないもの」がたまりがちです。

1. 開発の都合で本番に近いデータが持ち込まれる

不具合の再現や性能試験のために、本番データの一部を抜き出してテストデータとして使う。その抽出ファイルや設定ファイルが、そのままリポジトリに残ります。開発者に悪意はなく、「早く直す」ための行動です。

2. 認証情報がコードと一緒に管理される

外部サービスのAPIキーやデータベースの接続情報を、設定ファイルに直接書いてしまう。今回も同社は「GitHub上に保存されていた他サービスの認証情報」を変更しています。一つの鍵が開くと、別の扉の鍵も手に入る構造です。

3. 個人の認証情報が長く有効なまま残る

アクセストークンやSSH鍵は、作った本人しか存在を把握していないことが多く、有効期限も設定されないまま何年も使われます。端末の感染や誤った公開で漏れても、気づくのは今回のように外部から指摘されたときです。

4. 開発環境は「監査の外」に置かれやすい

本番環境には厳しいアクセス管理と監視がある一方、開発基盤は「エンジニアの道具」として扱われ、ログの保存期間やアクセス権の棚卸しが後回しになります。今回、ログの制約で全期間を確認できていないのは、まさにこの部分です。

発注側から見ると、これらはすべて委託先の内部で起きることで、通常は見えません。だからこそ、見えないことを前提にした仕組みが必要です。

発注側が持つべき仕組み

ニュースの解説記事では「MFAを必須に」「シークレットスキャンを」といった技術対策が並びがちですが、発注側が直接設定できるものではありません。発注側ができるのは、ルールと契約と確認の仕組みで委託先の行動を方向づけることです。

1. 「自社データをどこに置いてよいか」を契約で決める

まず、委託先が自社の個人情報や業務データを置いてよい場所を、契約や個人情報の取扱い覚書で明示します。

本番データを開発・テスト環境に持ち込む場合は、事前申請と承認を必須にする
持ち込む場合はマスキング（氏名・メールアドレス等の置き換え）を原則とする
ソースコード管理サービスに個人情報を保存しないことを明記する
作業終了時の削除と、削除したことの報告を求める

「委託先の管理体制に任せる」のではなく、置き場所を発注側のルールとして渡すのがポイントです。システム刷新時のセキュリティ要件の決め方は、基幹システム刷新におけるセキュリティ要件の記事でも整理していますが、運用・保守フェーズの委託にも同じ考え方が必要です。

2. セキュリティチェックシートに「開発環境」の項目を足す

委託先評価のチェックシートは、本番環境やデータセンターの項目に偏りがちです。次のような開発環境の項目を追加し、年1回の評価で回答を求めます。

ソースコード管理サービスへのログインにSSO・多要素認証を必須にしているか
個人のアクセストークンやSSH鍵に有効期限を設け、棚卸しをしているか
リポジトリ内の認証情報や個人情報を検知する仕組みがあるか
開発基盤のアクセスログを何か月保存しているか
退職者・異動者のアカウントをいつまでに停止しているか

回答が「いいえ」でもすぐに取引停止にする必要はありません。改善計画と期限を出してもらい、翌年に確認する。この繰り返しが委託先管理の実務です。

3. ログの保存期間を「事故後に必要な長さ」で決める

今回、同社は認証情報が有効だった期間全体のアクセス状況を確認できていないとしています。事故が起きたとき、影響範囲を絞り込めないと、対象者を広めに通知するしかなくなり、対応コストも信用の毀損も大きくなります。

発注側は、委託先にも自社にも「最低限このくらいはさかのぼれるように」という保存期間の基準を示しておくべきです。期間はリスクと費用で決めますが、侵入から発覚まで数か月かかる事案も少なくないため、短すぎない設定が望ましいでしょう。ログの保存には費用がかかるので、見積もりや予算にあらかじめ含めておくことも大切です。

4. 自社の開発基盤も同じ目線で点検する

内製化を進める企業では、自社のGitHubやクラウドに同じリスクを抱えています。委託先の開発者を自社の組織に「外部協力者」として招待している場合は、特に注意が必要です。

誰がどのリポジトリにアクセスできるかを四半期ごとに棚卸しする
契約が終わった委託先メンバーのアクセス権を、契約終了日に外す運用にする
リポジトリの所有者を個人ではなく組織にする

「委託先に求めることは、自社でもできている状態にする」ことで、要求にも説得力が出ます。

5. 委託先で事故が起きたときの動きを決めておく

今回のように、委託先から「漏えいのおそれ」の連絡を受けたとき、発注側にも本人通知や個人情報保護委員会への報告の判断が求められます。誰が窓口になり、何を委託先に確認し、どの時点で報告するかを、平時に決めておきましょう。

委託先からの第一報を受ける窓口と、社内のエスカレーション先
委託先に確認する項目（対象データ、件数、期間、ログの有無）
連名報告にするか、単独で報告するかの判断者

まとめ

サイバーセキュリティクラウドの事案は、認証情報1件の流出から、開発基盤に保存されていた顧客情報に漏えいのおそれが生じたものです。原因や範囲は調査中ですが、発注側が学べることははっきりしています。

自社データの「置き場所」を契約で決め、開発環境への持ち込みを管理する
委託先評価に開発環境の項目を加え、毎年確認する
ログの保存期間を事故対応に必要な長さで決め、費用も見込んでおく
自社の開発基盤も同じ基準で点検する
委託先事故の受け方と報告の判断を平時に決めておく

本番環境だけ守っても、データは開発の現場から漏れることがあります。「自社のデータは今どこにあるのか」を委託先と一緒に把握することから始めてみてください。

参考

執筆者プロフィール：SIer（元請け）とITコンサルファーム（発注側支援）、両方の立場でプロジェクトに従事（通算9年）。要件定義からベンダーマネジメントまで一貫して対応し、基幹システム刷新・DX推進プロジェクトに多数従事。