13,000枚の社内スクリーンショットが公開GitHubに流出、攻撃者の関与はなし

セキュリティ研究者は、300以上の組織の社内スクリーンショット13,000枚以上が公開GitHubリポジトリに置かれているのを発見した。これらのスクリーンショットは盗まれたものではない。組織が使用していたコーディングエージェントによって、通常の業務中に公開されたものだ。

セキュリティ企業Glowが報告したこの発見は、ここ最近で最も示唆に富むリークの一つだ。通常の前提が当てはまらないからである。侵害も、資格情報の漏洩も、悪意ある内部関係者もいなかった。自動化ツールが指示された通りに動き、その指示には、絶対に社外に出るべきではないファイルをコミットすることが含まれていたのだ。

スクリーンショットが公開リポジトリに入るまで

コーディングエージェントがスクリーンショットを撮るのにはもっともな理由がある。ユーザーインターフェースの変更が機能したかを確認するようエージェントに指示すると、ブラウザを開き、ページを読み込み、画像をキャプチャし、期待される結果と比較する。その画像は証拠である。多くのエージェントは、後でそのステップを確認できるように、画像を作業ディレクトリに保存する。

そこから公開リポジトリに至る道は短い。エージェントの作業ディレクトリがプロジェクトフォルダであり、そのプロジェクトフォルダがgitリポジトリであれば、ディスクに書き込まれたスクリーンショットは、あと1回の`git add`でコミットされる位置にある。エージェントが通常のワークフローの一部としてコミットとプッシュを行い、新しいファイルをフィルタリングするものが何もなければ、スクリーンショットはリポジトリが指すリモートに送られる。

これを何千回もの実行、何百もの組織、数か月にわたって繰り返す。誰も社内スクリーンショットを公開しようとは決めていない。ツールのデフォルトの挙動がそれをやり、チェーンの中のどのステップもチェックしていなかった。

なぜこれは小さなミスではないのか

社内スクリーンショットは、人が思うよりはるかに多くを明かすことが多い。顧客名が並ぶダッシュボード、価格が表示された管理パネル、ステージング環境、バグトラッカー、画面隅のチャットウィンドウなどが映り得る。まだローンチしていない製品の状態が映ることもある。合計すると、300組織からの13,000枚の画像は、それらの企業が何に取り組んでいたかの地図になる。

画像はまた残り続ける。公開リポジトリにプッシュされたコミットは、履歴が書き換えられない限り、現在のバージョンからファイルが削除された後も履歴に残る。したがって、露出は後からのクリーンアップコミットでは修正されない。多くのチームが最初に手を伸ばすステップがそれだ。

なぜエージェントが事態を悪化させるのか

プルリクエスト用にスクリーンショットを撮る人間の開発者は、通常、添付する前にそれを目にする。画像がすぐそこにあり、共有しても安全かどうかをその人が判断する。この判断の瞬間がフィルターであり、ほとんどの場合機能する。

エージェントにはそのような瞬間がない。タスクの完了に最適化しており、成果物を保存することはタスク完了の一部である。ループの中の何も、その成果物が機密かどうかを問わない。ループの中の何も、それを知る術を持たないからだ。エージェントは人間的な意味で不注意なのではない。指示された通りのことを正確に行っているのだ。

これはエージェント設計のいくつかの領域で現れる同じ教訓だ。人間がコマンドを入力するには問題ない権限も、機械の速度で動作し、決して疲れないシステムには問題ないとは言えない。人間が週に一度スクリーンショットをコミットするのはうっかりミスだ。エージェントがフリート全体で毎回それをやるのは、ポリシーの帰結である。

修正策はどのようなものか

これを防げたであろう制御は、奇抜なものではない。スクリーンショットディレクトリに対する`.gitignore`のエントリが最も単純で、エージェントが実行される前に誰かがそれを書いた場合にのみ機能する。特定のパスで画像ファイルをスキャンするpre-commitフックは、ignoreファイルが見過ごすものを捕捉する。一時的な成果物用にリポジトリ外のスクラッチディレクトリをエージェントに与えることは、問題を源から取り除く。

これらのどれも、画像が機密であることを検出することに依存していない。エージェントの出力がどこに行くことを許可されるかを事前に決めることに依存している。それは設計上の決定であり、エージェントを実行するチームが行わなければならない。エージェントにはそれができないからだ。

なぜ数は増え続けるのか

300組織からの13,000枚という数は固定された数字ではない。スキャン時に公開されていたリポジトリのスナップショットであり、より多くのチームがエージェントを採用し、より多くのリポジトリがプッシュされるにつれて増加する。研究者は公開リポジトリをスキャンした。つまり、同じ過ちが起きた非公開リポジトリを含む真の合計は、外部からは知りようがない。

影響を受けた組織はすべてが小規模というわけではない。この発見では300以上が名指しされており、同じエージェントツールを使用するスタートアップから大企業まで及ぶ。これがデフォルト挙動の問題の本質だ。企業規模を問わない。ツールを使うすべての企業が同じデフォルトを継承するからである。

報告書が言っていないこと

この発見は、露出した画像のいずれかが悪意をもって使用されたと主張しているわけではなく、プロジェクト外部の誰かがそれらを精査した証拠もない。害は証明されたものではなく潜在的なものだ。素材は公開されており、誰でも見ることができた。関連事例で害が実証されている場合、たとえば資格情報が公開ファイルに書き込まれた場合、損害は即座に生じる。

また、画像のうちどれだけが意味のある形で機密だったかも教えてくれない。ほとんど確実に、空白のテストページのスクリーンショットも含まれている。しかしリークは平均ではなく、その中で最悪の項目によって評価される。300組織にわたる13,000枚の画像は、最悪の項目が本当に何かを明かすものである可能性が高いことを意味する。

背後にあるパターン

Glowの発見は、類似の報告が集まったうちの一つだ。研究者は、コーディングエージェントが存在しないソフトウェアパッケージを参照することを示しており、攻撃者はその名前を登録することで悪用できる。他にも、エージェントが資格情報やトークンを本来書くべきでない場所に書き込むことを発見している。共通するのは、エージェントが作業の副作用として成果物を生成し、すべての成果物が潜在的なリークであるということだ。

安心できる読み方は、これは修正可能であり、ほとんどが衛生管理の問題だということだ。あまり安心できない読み方は、業界がエージェントの出力を囲むガードレールを構築するよりも速くエージェントを展開しているということだ。エージェントが読むものを監査している企業は、多くの場合、エージェントが書くものを監査していない。

今週やるべきこと

チームがリポジトリに対してコーディングエージェントを実行しているなら、すぐにできる確認を行う価値がある。エージェントの作業ディレクトリがリポジトリ内にあるか、スクリーンショットやログがそこに置かれるか、コミットステップが何かをフィルタリングしているかを確認する。公開されるべきでない画像ファイルについて、現在のツリーだけでなくリポジトリ履歴も確認する。そして、一時的なものにはツリー外のスクラッチパスをエージェントに与える。

それらのどれも新しいツールを必要としない。必要なのは、エージェントの入力と同様に出力も、チームが偶然ではなく意図的に制御するものだと決めることだ。