GitHub情報漏洩から学ぶAI時代のセキュリティ対策

GitHub情報漏洩は、公開リポジトリにうっかりAPIキーを置いた、という古い話だけではありません。AIコーディング、MCP、VS Code拡張機能、CI/CD、チャットツールがつながることで、漏洩の入口は増えています。

この記事では、GitHub情報漏洩をAI時代の開発リスクとして整理し、何を置いてはいけないのか、漏れたらどうするのか、事前にどの仕組みで止めるのかを解説します。結論として、削除ではなく無効化、事後確認ではなくpush前ブロックが重要です。

GitHub情報漏洩で何が問題になるのか

GitHubに漏れて困るのは、ソースコードそのものだけではありません。APIキー、アクセストークン、DB接続文字列、.env、秘密鍵、本番データのサンプル、MCP設定、CI/CDのシークレットが含まれると、攻撃者はサービスに直接アクセスできる可能性があります。

特にAIコーディングでは、AIが便利な設定例を出し、そのままコミットしてしまうリスクがあります。AIは動くコードを作ることは得意ですが、秘密情報をどこに置くべきか、会社の運用ルールに合っているかは人間が決める必要があります。

漏洩は公開リポジトリだけの問題ではない

非公開リポジトリだから安全、という考え方は危険です。社員アカウント、外部委託先、CI/CD、拡張機能、マルウェア、誤設定を通じて、非公開リポジトリの情報も漏れる可能性があります。GitHub上に置いてよい情報かどうかは、公開/非公開だけで判断できません。

AI時代には、ローカルPCも重要な攻撃対象になります。Claude CodeやCursorのような開発支援AI、MCP、VS Code拡張機能は、開発者のローカル環境にある認証情報へ近づきます。便利な拡張を入れる前に、何にアクセスするのかを確認する必要があります。

GitHubのsecret scanningとpush protectionを使う

GitHub公式ドキュメントでは、secret scanningやpush protectionが用意されています。push protectionは、対応するシークレットをpushしようとしたときにブロックし、理由を表示して修正を促します。これは、漏れてから探すのではなく、履歴に入る前に止める仕組みです。

組織利用では、リポジトリ、Organization、Enterpriseレベルでpush protectionを有効化し、バイパスした場合のアラートや監査ログも確認します。さらに、自社固有のトークン形式がある場合はcustom patternを検討します。AIがコードを書くほど、機械的に止める仕組みが重要になります。

漏れた可能性がある鍵は削除ではなく止める

GitHubからファイルを消しても、履歴、フォーク、キャッシュ、ローカルコピー、攻撃者側の保存先に残っている可能性があります。漏れた可能性があるAPIキーやトークンは、まず無効化し、再発行し、利用ログを確認します。削除はその後です。

この順番を間違えると、表面上はきれいになっても、攻撃者が古いキーを使い続ける可能性があります。インシデント対応では、どのキーを誰が止めるのか、どのサービスのログを見るのか、顧客や社内にどう報告するのかを事前に決めておく必要があります。

AIコーディング時代の実務対策

AIでコードを書く場合、AIに秘密情報を貼り付けない、.envを読み込ませない、本番データをサンプルとして渡さない、生成された設定ファイルをそのままコミットしないことが基本です。さらに、AIが追加した依存関係、GitHub Actions、MCP設定、外部通信もレビューします。

開発チームでは、AI利用ルールをCLAUDE.mdやREADMEに書き、commit前にsecret scanning、push protection、依存関係チェック、レビューを通す運用にします。AIで開発速度が上がるほど、漏洩防止は人間の注意力ではなく仕組みで担保するべきです。

Claude Code側の安全運用は、Claude CodeのSecurity Guidance記事で詳しく解説しています。

社内ルールとして決めておくこと

GitHub情報漏洩を防ぐには、個人の注意に頼らないルールが必要です。まず、リポジトリに置いてはいけない情報を明文化します。APIキー、パスワード、DB接続文字列、.env、本番データ、顧客情報、MCP認証情報は、ソースコードと同じ場所に置かないことを基本にします。

次に、漏れたときの対応手順を決めます。誰がキーを無効化するのか、どのサービスのログを見るのか、GitHubの履歴をどう扱うのか、顧客影響を誰が判断するのかを事前に決めます。漏洩時にゼロから考えると、初動が遅れます。

AI利用ルールも必要です。AIに本番データを貼らない、秘密情報を含むファイルを読ませない、AIが生成した設定ファイルをそのままcommitしない、MCP設定はレビューする、といったルールをプロジェクトに書きます。

最後に、自動チェックを標準化します。ローカルのpre-commit、GitHubのsecret scanning、push protection、CIの依存関係チェックを組み合わせます。AI時代のセキュリティは、速く作ることを止めるのではなく、速く作っても漏れない仕組みを先に置くことです。

GitHub ActionsとAI連携の落とし穴

GitHub情報漏洩では、リポジトリ内のファイルだけでなくGitHub Actionsも確認対象です。CI/CDでは、デプロイキー、クラウド認証情報、パッケージ公開トークンなどが扱われます。AIがworkflowファイルを変更したときは、権限が広がっていないか、外部アクションを不用意に追加していないかを確認します。

AIに「デプロイできるようにして」と頼むと、便利なサンプルを参考にしながらworkflowを作ることがあります。その中に過剰な権限、古いaction、固定されていないバージョン、secretの出力が含まれると危険です。動くことと安全であることは別です。

MCPや外部AIツールとGitHubを連携する場合も同じです。読み取りだけでよいのか、書き込みやPR作成まで許可するのか、組織全体へアクセスできるのかを確認します。AIツールへ広いGitHub権限を渡すほど、便利さと同時に漏洩時の影響範囲も広がります。

実務では、GitHub Actions、MCP、AI開発ツール、ローカルPCをまとめてセキュリティ対象として扱います。ソースコードだけを守っていても、周辺ツールから漏れる時代になっています。

実務で活かすための次アクション

この記事のテーマであるGitHub情報漏洩対策は、読んで理解するだけでは十分ではありません。AI関連の情報は変化が速いため、自分や自社の業務にどう影響するかまで落とし込む必要があります。ニュースやモデル名を覚えるより、どの判断を変えるべきかを確認することが重要です。

まず、リポジトリに置いてはいけない情報を明文化し、既存リポジトリをsecret scanningで確認します。この段階では完璧なルールや大規模な導入計画は不要です。小さく現状を把握し、どこに依存があり、どこにリスクがあり、どこならすぐ改善できるかを見える化します。

次に、push protection、custom pattern、CIチェック、AI利用ルールを組み合わせて漏洩前に止めます。AIツールは便利ですが、性能、料金、セキュリティ、運用負荷のどれか一つだけで判断すると失敗しやすくなります。導入判断は、実際の業務サンプルと運用条件を使って行うのが安全です。

最後に、GitHub Actions、MCP、VS Code拡張機能、AI開発ツールの権限変更を継続的に確認します。一度決めたAI運用は固定ではありません。モデル、料金、規制、ツール連携、社内利用状況が変わるため、定期的に見直す前提で運用すると、AIの変化に振り回されにくくなります。

読後のチェックとして、この記事の内容をそのまま社内ルールにするのではなく、自社の業務、扱うデータ、担当者のスキル、予算、リスク許容度に合わせて調整してください。AI活用では、一般論を知ることより、自分たちの運用に翻訳することが成果につながります。

必要に応じて、この記事を社内メモやチェックリストに分解し、担当者、確認頻度、判断基準まで落とすと実行しやすくなります。

よくある質問

GitHubから秘密情報を消せば大丈夫ですか？

大丈夫ではありません。履歴やコピーに残る可能性があるため、まずキーを無効化・再発行し、利用ログを確認する必要があります。

非公開リポジトリならAPIキーを置いてもよいですか？

置くべきではありません。非公開でもアカウント侵害、拡張機能、CI/CD、外部委託先から漏れる可能性があります。秘密情報はsecret managerや環境変数で管理します。

AIコーディングで一番気をつけることは何ですか？

AIが生成した設定やコードをそのままコミットしないことです。secret scanning、push protection、差分レビューを必ず通してください。

参考視聴・公式情報

参考動画: ウェブ職TV

GitHub Docs: Secret scanning

GitHub Docs: Push protection