Noma Labsは、AI駆動の自動化を利用することで、単一の公開GitHub Issueからプライベートリポジトリのコードを盗み出せることを示しました。彼らの概念実証（PoC）によれば、攻撃者は組織自身のワークフローボットを逆手に取り、GitHubの認証を突破することなく、機密ファイルを漏洩させることが可能です。

目の前で行われる攻撃

一連の流れは、再現が容易なほど単純です。

  • 攻撃者が、誰でも閲覧可能な公開リポジトリにIssueを作成します。
  • CI（継続的インテグレーション）パイプラインに組み込まれたAIエージェントが、Issueのタイトルと本文を読み取ります。
  • そのエージェントは、組織内の他のプライベートリポジトリに対する読み取り権限を既に持っています。
  • 公開Issue内に隠された指示により、エージェントはどのプライベートファイルをフェッチすべきかを判断します。
  • エージェントは取得したファイルを公開Issueにコメントとして投稿し、それらを世界中にさらけ出します。

これらすべては、自動化の単一の実行プロセスの中で完結します。認証情報の窃取も、APIキーの漏洩も、GitHub自体の脆弱性もありません。攻撃者は、組織が自社のボットに対して置いている「信頼」を単に悪用しているだけなのです。

なぜ今、これが重要なのか

AI搭載のエージェントは、現在、現代の開発パイプラインを繋ぎ合わせる役割を担っています。Issueのコメントといった軽量なシグナルをトリガーとして、プルリクエストの作成、テストの実行、ビルドのデプロイ、バグのトリアージなどを行います。これらのエージェントが広範なリポジトリへのアクセス権を持っている場合、信頼できるデータと信頼できないユーザー入力の境界線が曖昧になります。

もしエージェントが同一の実行プロセス内でプライベートなコードを読み取り、かつ公開の場に書き込むことができるのであれば、組織のアクセス制御モデルは崩壊します。

真の欠陥：モデルではなく権限にある

このデモンストレーションは、基盤となるAIモデルに問題があることを示唆するものではありません。モデルは単に受け取った指示に従っているだけです。脆弱性は、自動化プロセスに付与された権限セットに存在します。

  • 組織全体のプライベートリポジトリに対する読み取り権限。
  • 公開Issueスレッドに対する書き込み権限。
  • 誰でも作成可能な公開テキストによるトリガー。

コストをかけずに効果を発揮する対策

最小権限の原則を適用することで、攻撃経路を大幅に削減できます。

  • ボットのスコープを限定する。特定のレポジトリでのみ動作する必要がある場合は、それ以外の読み取り権限を拒否してください。
  • 読み取り用と書き込み用のトークンを分離する。コードの取得には一つの認証情報を使用し、コメントの投稿には厳格に管理された別の認証情報を使用してください。
  • 人間による承認。公開投稿を行う前に、承認ラベルの付与といった軽量なレビューステップを導入することで、パイプラインを停止させることなくチェックポイントを設けることができます。
  • 影響範囲（ブラスト・ラジアス）の縮小。失敗や悪用が発生しても、組織全体ではなく、せいぜい一つのリポジトリにのみ影響が及ぶようにワークフローを設計してください。

反論：運用上のオーバーヘッド

今後の注目点

まとめ： AIによる自動化がプライベートなコードを閲覧でき、かつ公開の場に発言できるのであれば、そのシステムは設計ミスです。権限を厳格化し、人間のチェックを介在させ、影響範囲を最小限に抑えてください。さもなければ、たった一つの公開Issueがデータ漏洩の経路になり得ます。