ソースコードは「社外に出ない前提」で管理していないか。 2026年4月2日22時50分頃、クラウドファンディング大手CAMPFIREのGitHubアカウントに不正アクセスが発生した（CAMPFIRE公表, rocket-boys.co.jp, ccsi.jp）。一部ソースコードが閲覧された可能性がある。個人情報の流出は現時点で確認されていないが、同社は直ちにアクセスを遮断し、調査を進めている。

項目内容
被害企業CAMPFIRE（クラウドファンディング大手）
発生日時2026年4月2日 22:50頃
攻撃対象GitHubアカウント
影響一部ソースコードが閲覧された可能性
個人情報流出未確認
初動対応直ちにアクセス遮断
この事案が示しているのは、GitHubをはじめとするコードホスティングサービスのアカウント管理が、多くの企業で「セキュリティの死角」になっているという事実だ。ソースコードには、APIキー、データベース接続情報、認証ロジック、ビジネスロジックなど、攻撃者にとって宝の山となる情報が含まれている。

事案の経緯——22時50分に何が起きたか

公表されている事実

CAMPFIREおよび関連報道によると、事案の経緯は以下の通りだ。

時系列出来事
4月2日 22:50頃GitHubアカウントへの不正アクセスを検知
4月2日（同日）直ちにアクセスを遮断。影響範囲の調査を開始
調査中一部ソースコードが閲覧された可能性を確認
現時点個人情報の流出は未確認。外部専門機関と連携して調査継続中
注目すべきは、不正アクセスの検知からアクセス遮断までの対応が迅速だった点だ。初動の速さが被害の拡大を防いだ可能性が高い。一方で、「一部ソースコードが閲覧された可能性」がある以上、ソースコードに含まれていた情報次第では二次被害のリスクが残る。

ソースコードが閲覧されると何が起きるか

ソースコードの閲覧自体は、個人情報の流出とは性質が異なる。しかし、攻撃者がソースコードから得られる情報は深刻だ。

情報の種類リスク
APIキー・シークレット外部サービスへの不正アクセス
データベース接続情報顧客データへの直接アクセス
認証・認可ロジック認証の迂回方法の特定
ビジネスロジック競合による模倣、脆弱性の特定
インフラ構成情報本番環境への攻撃経路の特定
コメント・TODO未修正の脆弱性やセキュリティ課題の把握
つまり、ソースコードの閲覧は「次の攻撃のための偵察活動」として機能する。今回の事案で個人情報の流出が確認されていないのは幸いだが、ソースコードの内容によっては追加の対策が必要になる。

ソースコード管理で企業が見落としがちな3つのリスク

リスク1：GitHubアカウントの認証が脆弱なまま放置されている

多くの企業で、GitHubアカウントのセキュリティ設定は開発者任せになっている。パスワード認証のみでMFA（多要素認証）が未設定、退職者のアカウントが残存、個人アカウントで業務リポジトリにアクセスしている——こうした状態は珍しくない。

GitHubは2023年にすべてのユーザーに対してMFAを必須化したが、Organization（組織アカウント）レベルでのMFA強制設定を行っていない企業はまだ多い。個人が自分のアカウントでMFAを無効化していれば、組織全体のセキュリティが崩れる。

よくある問題：

  • Organization全体でのMFA強制が未設定
  • 退職者・契約終了した外部ベンダーのアクセス権限が残存
  • 個人のGitHubアカウントで業務リポジトリにアクセスしている
  • Personal Access Token（PAT）の有効期限が無期限
  • SSO（シングルサインオン）が未導入で、アカウント管理が分散

リスク2：ソースコードにシークレット情報がハードコードされている

APIキー、データベースパスワード、外部サービスの認証情報がソースコードに直接書き込まれている——いわゆる「ハードコード問題」は、開発者の85%が経験したことがあるという調査結果がある（GitGuardian, 2025 State of Secrets Sprawl）。

問題は、これらの情報がGitの履歴に残ることだ。ファイルからシークレットを削除しても、コミット履歴を遡れば閲覧できる。ソースコードが閲覧された場合、現在のコードだけでなく過去の履歴からもシークレットが漏洩するリスクがある。

典型的なハードコードの例：

  • `.env`ファイルがそのままコミットされている
  • コード内にAPIキーが文字列リテラルとして記述されている
  • テスト用の認証情報が本番の認証情報と同一
  • ドキュメントやコメントに接続情報が記載されている

リスク3：リポジトリの公開設定とアクセス権限が適切でない

GitHubのリポジトリは、デフォルトの公開設定が作成時の選択に依存する。意図せずPublicリポジトリとして作成され、社内のソースコードがインターネットに公開されたままになっている事例は後を絶たない。

また、Private リポジトリであっても、アクセス権限の粒度が粗い場合はリスクになる。全エンジニアがすべてのリポジトリにRead/Write権限を持っている状態は、1つのアカウントが侵害されただけで全リポジトリが閲覧可能になることを意味する。

見落としがちなポイント：

  • Publicリポジトリに社内コードが含まれていないか
  • Fork（フォーク）によってプライベートリポジトリのコードが公開リポジトリに転写されていないか
  • GitHub Actionsのワークフローファイルにシークレットが露出していないか
  • 全員がAdmin権限を持つOrganization設定になっていないか

「自社のGitHub、セキュリティ設定を最後に確認したのはいつですか？」

ソースコード管理の見直しは、セキュリティ対策の中でも最も後回しにされがちな領域です。まずは現状のリスクを可視化するところから始めましょう。

無料セキュリティ相談を予約する

※ 営業電話はしません ｜ オンライン対応可 ｜ 相談だけでもOK

今すぐ実行すべき対策3ステップ

ステップ1：GitHubアカウントのセキュリティ設定を総点検する（今日中）

最も優先度が高いのは、アカウントの認証強度とアクセス権限の確認だ。以下のチェック項目を今日中に確認してほしい。

チェック項目確認方法対応
Organization全体でMFAが強制されているかSettings → Authentication security「Require two-factor authentication」を有効化
退職者・契約終了者のアカウントが残っていないかPeople → メンバー一覧不要なアカウントを即座に削除
Personal Access Tokenの有効期限が適切か各メンバーのSettings → Developer settings無期限のPATを有期限に変更、または削除
SSO/SAMLが導入されているかSettings → Authentication securityEnterprise/Business契約であればSSO設定を推奨
外部コラボレーターの権限が適切かSettings → Member privileges最小権限の原則で再設定

ステップ2：ソースコードのシークレットスキャンを実行する（今週中）

リポジトリ内にシークレット情報がハードコードされていないか、ツールを使って一斉スキャンする。

ツール特徴費用
GitHub Secret ScanningGitHub標準機能。Push時にシークレットを自動検出Advanced Security契約に含む
GitGuardianコミット履歴全体をスキャン。350以上のシークレットパターンに対応25名まで無料
TruffleHogGit履歴全体をスキャン。OSS版あり無料（OSS）
gitleaks軽量なシークレットスキャナー。CI/CDに組込み可能無料（OSS）
スキャン後の対応手順：
  1. 検出されたシークレットをリスト化
  2. 該当するAPIキー・パスワードを即座にローテーション（変更）
  3. `.gitignore`に機密ファイルを追加
  4. 環境変数やシークレット管理サービス（AWS Secrets Manager、HashiCorp Vault等）への移行
  5. CI/CDパイプラインにシークレットスキャンを組込み、今後のコミットを自動チェック

ステップ3：リポジトリの公開設定とアクセス権限を見直す（今月中）

リポジトリの棚卸しを行い、公開設定とアクセス権限を最小権限の原則に基づいて再設定する。

対策実施内容
リポジトリの棚卸し全リポジトリの公開/非公開設定を一覧化。意図しないPublicリポジトリがないか確認
アクセス権限の再設定チーム単位でリポジトリへのアクセスを管理。「全員がAdmin」を排除
ブランチ保護ルールの設定mainブランチへの直接Push禁止、PR必須、レビュー必須を設定
監査ログの有効化Organization Audit Logを有効化し、アクセス履歴を記録・監視
GitHub Actionsの権限確認ワークフローファイルにシークレットが露出していないか確認。OIDC連携を推奨

まとめ

CAMPFIREのGitHubアカウント不正アクセス事案は、ソースコード管理がセキュリティの死角になり得ることを改めて浮き彫りにした。個人情報の流出が確認されていないのは幸いだが、ソースコードの閲覧自体が次の攻撃の足がかりになるリスクは残る。

中小企業が今日から取るべきアクションは3つだ。GitHubアカウントの認証設定の総点検、シークレットスキャンの実行、リポジトリの公開設定とアクセス権限の見直し。 ソースコード管理は開発者だけの問題ではない。経営リスクとして向き合うべきテーマだ。

関連記事：サイバーセキュリティ完全ガイド 2026年版 関連記事：API認証セキュリティガイド OAuth/JWT 関連記事：DevOps CI/CD導入ガイド 関連記事：導入事例一覧

ソースコード管理のセキュリティ、見直しませんか

「GitHubのセキュリティ設定を確認したことがない」「シークレットスキャンを実施したことがない」——その状態は、鍵をかけずにオフィスを空けているのと同じです。まずは現状のリスク把握から始めましょう。

ソースコード管理の無料セキュリティ相談を予約する

※ 営業電話はしません ｜ オンライン対応可 ｜ 相談だけでもOK

よくある質問（FAQ）

Q1. CAMPFIREの不正アクセスで、自分のアカウント情報は影響を受けますか？ A. CAMPFIRE社は現時点で個人情報の流出は確認されていないと公表しています。ただし、CAMPFIREのサービスを利用している方は、念のためパスワードの変更とMFA（多要素認証）の設定を推奨します。調査は継続中のため、同社の続報を確認してください。

Q2. 中小企業でもGitHubのセキュリティ対策は必要ですか？ A. はい。GitHubを利用している企業であれば、規模を問わずアカウントの認証強度とリポジトリの公開設定は確認すべきです。特に外部ベンダーに開発を委託している場合、ベンダーのGitHubアカウントが侵害されれば自社のソースコードも影響を受けます。委託先のセキュリティ体制も確認してください。

Q3. GitHubを使っていなければ、この問題は関係ありませんか？ A. GitLabやBitbucket、Azure DevOpsなど他のコードホスティングサービスを利用している場合でも、同様のリスクは存在します。アカウントの認証設定、シークレットのハードコード、リポジトリの公開設定——これらはプラットフォームを問わず共通の課題です。また、ソースコードをローカルのファイルサーバーのみで管理している場合でも、そのサーバーのアクセス制御が不十分であれば同じリスクがあります。

参考情報

  • CAMPFIRE 不正アクセスに関する公表（rocket-boys.co.jp, 2026年4月）
  • サイバーセキュリティ総合情報サイト ccsi.jp 関連報道（2026年4月）
  • GitGuardian「2025 State of Secrets Sprawl」レポート
  • GitHub「Securing your organization」公式ドキュメント