AIベースのコーディングアプリケーション「ZCode」が、ユーザーの無断でワークスペース全体とGit履歴を暗号化し、外部サーバーへ送信していることがリバースエンジニアリング分析により明らかになりました。北京に本社を置く企業が開発したこのツールは、ログイン状態で動作し、ユーザーの明示的な許可なく大規模なファイルを外部ストレージにアップロードする動作を行っていました。特に、モデル学習の許可やリポジトリインデックス設定をオフにしても、これらの情報収集と送信は止まらず継続されていることが判明しました。これにより、開発者が無意識に入力したパスワードやAPIキーなどの機密情報がそのまま漏洩する可能性があるという深刻な懸念が提起されています。本記事では、今回の情報漏洩事件の具体的な経緯と技術的背景を詳しく見ていきましょう。読者の皆様にとっても、現在使用中のAIツールのセキュリティ状態を再確認するきっかけとなることを願っています。
=
AIコーディングツールZCode、ユーザーの無断でGit履歴をクラウドに流出させた事件

1. リバースエンジニアリング分析で明らかになった秘密のアップロード

開発者のペルスタ氏は最近、ZCodeアプリケーションを詳細にリバースエンジニアリング分析した結果、ログイン状態でワークスペース全体とGit履歴が外部へ送信されている現象を発見しました。このプログラムは、ユーザーの作業内容を暗号化し、Alibaba Cloudのオブジェクトストレージへ直接送信するプロセスを隠蔽していました。調査対象となった300MBを超える商用ワークスペースでも、例外なく暗号化された圧縮ファイルが生成され、外部へ流出していました。驚くべきことに、この過程で数百回に及ぶアップロード試行の記録が内部ログにそのまま残されていたとされています。大多数のユーザーは、自分の貴重なソースコードがリアルタイムでバックアップされているという事実に全く気づいていませんでした。このような現象は単なる作業ファイルのコピーを超え、ユーザーのコンピュータ環境全体をスキャンしているような印象を与えました。プログラムは、ユーザーがプロンプトを入力する前と作業が終了するタイミングに合わせて、定期的に情報を横取りしていました。開発側はAIモデルとのスムーズな連携を長所として掲げていましたが、その裏で行われる過剰な情報収集は大きな論争を呼びました。公開重み付きモデルを使用しているという事実が、周辺で連携されているツールの安全性まで保証してくれるわけではないことが明らかになりました。結局、開発者は利便性という名の下で、自分の作業履歴を外部サーバーに丸ごと提供していた 셈です。
ZCodeがユーザーの同意なしにワークスペース全体を暗号化し、外部サーバーへ送信していることがリバースエンジニアリング分析で明らかになりました。
2. 送信データの大部分を占めるGit履歴

漏洩した情報の具体的な内容を見ると、送信量の大部分がGitディレクトリから由来していることが確認されました。項目別の割合を見ると、Gitの大容量ファイルストレージキャッシュとオブジェクトストレージファイルが送信データの大きな割合を占めていました。現在作業中のウィンドウに表示されているコードだけでなく、過去のコミット過程で既に削除したAPIキーやパスワードまで含まれる可能性があることが最大の懸念点です。まだ世間に公開されていない非公開ブランチ名や内部設定ファイルも、そのまま送信対象に含まれていました。これは現在の作業状態のみを示すものではなく、プロジェクトの歴史全体が他人の手に渡りうることを意味します。実際、Gitのログ記録や設定ファイルには、内部サーバーのアドレスや非公開リポジトリのパスなどの機密情報が満載であるのが常です。開発者が誤ってコミットした後すぐに削除した機密情報であっても、このプログラムが収集した圧縮ファイル内には永久に残り続けます。したがって、表面上は安全に見えるプロジェクトであっても、過去の履歴のために予期せぬセキュリティインシデントに発展する可能性があります。このような危険性は、単なるソースコードの漏洩を超え、致命的な企業機密の漏洩に拡大しうるものです。開発者個人が注意しても防げない問題であるため、より大きな衝撃を与えています。
漏洩した情報の大部分はGit履歴とオブジェクトストレージファイルであり、これらには過去に削除した機密情報まで含まれていました。
3. 復号化不可能な一方向暗号化構造

プログラムが収集したデータは、クライアント側で勝手に開いて確認できないよう徹底的に暗号化して送信される構造をとっていました。クライアントはサーバーから一時的に発行された公開鍵を使用してワークスペースを圧縮し、対称鍵で包むエンベロープ暗号化方式を使用していました。この過程で、暗号化を解除するために不可欠な秘密鍵は、開発会社のクラウドサーバーにのみ保管されていました。ユーザー自身のコンピュータに保存された暗号化ファイルであっても、プログラムやユーザー自身がこれを復号化することはできませんでした。研究者たちが直接ローカル環境のすべての秘密鍵を用いて復号化を試みましたが、すべて失敗するほどセキュリティ対策は堅固でした。このような設計方式は、ユーザーが自分のデバイスでどのような情報がやり取りされているかを透明に確認することを根本的に遮断する結果を生みました。ユーザーは、自分のコンピュータから何かが外部へ送信されているという事実を漠然と感じるだけで、正確にどのような内容が送られたのかを知ることができません。サーバーだけが復号化権限を独占しているため、開発側が望めばいつでもユーザーの過去の作業履歴を覗き見ることができます。これはユーザーのプライバシーを深刻に侵害する要素であり、商用プログラムの透明性に対する根本的な疑問を抱かせます。信頼を基盤として構築されるべき開発環境において、このような一方的な情報独占は大きな不安要素とならないわけがありません。
復号化に必要な秘密鍵がサーバーにのみ存在するため、ユーザーやクライアントは送信された暗号文を直接開いて確認できない構造でした。
4. 設定スイッチでも止められない情報収集
多くのユーザーは、プログラムの設定画面で関連機能をオフにすれば情報収集が止まるだろうと期待していましたが、それは事実ではありませんでした。モデル学習を許可するかどうかを決める設定や、リポジトリインデックス機能を無効にしても、スナップショットキャプチャとアップロード動作は止まらず継続して動作していました。プログラムは、ユーザーが指定した環境設定に関係なく、実行時点から別途サイドカープロセスを起動して情報を抜き取っていました。この過程で、エージェントツール自体の権限設定や内部ループは、このようなホストレベルの送信パイプラインを全く制御することができませんでした。つまり、ユーザーがインターフェースでどれだけセキュリティ設定をいじっても、バックグラウンドで行われる流出を防ぐ術はなかったのです。この事実は、プログラムのユーザーインターフェースが提供する設定が実際の動作方式と一致しておらず、ユーザーを欺いていることを示しています。エージェントツールの権限範囲の外でホストレベルで動作するため、一般的なセキュリティプログラムではこれを検知することすら困難です。ユーザーは、自分が制御できると信じていた領域の外に、別の隠されたプロセスが動いているという事実を知ることは困難です。結局、このような設計は、ユーザーの主権と選択権を無視して一方的にデータを収集しようとする意図が込められていると解釈せざるを得ません。開発者は、自分の作業環境を完全に信頼して任せられるツールが存在しないという現実と直面しました。
ユーザーがインターフェースで関連設定をすべてオフにしても、バックグラウンドプロセスによる情報収集とアップロードは止まりませんでした。
5. チェックポイントロックによる唯一の遮断方法
現時点では、ファイルシステムレベルで特定のディレクトリを書き込み禁止に設定する方法だけが、この無断アップロードを防ぐ唯一の代替案として挙げられています。プログラムがワークスペースをキャプチャして保存しようとするディレクトリを完全にロックすれば、データ生成が不可能になるため、外部送信も自然に遮断されます。しかし、この方式を適用すると、プログラムが提供するコア機能の一つである作業の巻き戻しやチェックポイント機能も一緒に壊れてしまいます。つまり、ユーザーはセキュリティを守るために、プログラムの便利な便利機能を犠牲にするという極端な選択を強いられている 셈です。これすら根本的な解決策というよりは応急処置に過ぎず、プログラムのアップデートによっていつでも無効化される可能性があります。このような強制遮断方式は、正常なユーザー体験を大きく損ない、プログラムの完成度にも致命的な傷を残します。開発ツールが提供する利便性を享受するために、ユーザーの機密な作業履歴を無条件に譲渡しなければならないのは、主客転倒した状況です。開発側がこの問題に気づき、公式な修正バージョンを配布するまでは、一般ユーザーの被害が懸念されます。セキュリティに敏感な企業環境や個人プロジェクトでは、直ちに当該プログラムを削除するのが最も安全な方法かもしれません。ツールの利便性の裏に隠された危険性を正確に認識し、自らの資産を守る知恵が必要です。
ファイルシステムで特定のディレクトリをロックすればアップロードを防げますが、プログラムの巻き戻し機能も一緒に停止するという副作用があります。
6. 透明性欠如のツールへの警戒と展望
今回の事件は、AIベースの開発ツールが急速に普及する過程で生じうるセキュリティ上の欠陥を露骨に示しました。重みが公開されたモデルを使用していることを掲げてエコシステム全体の信頼を得ようとしていましたが、実際には周辺ハネスは完全に非公開で運営されていました。このような密室行政的なプログラム運営は、ユーザーが扱うツールの安全性を疑うきっかけとなります。今後、AIコーディングツールを選択する際には、単にモデルの性能や利便性だけでなく、データ処理過程の透明性を必ず検討すべきです。開発者コミュニティも、ソースコードが公開されていないツールに対しては、より厳格な基準を適用すべきです。セキュリティが生命線であるソフトウェア開発環境において、ユーザーの同意のないデータ収集は信頼を一度に崩壊させる致命的な欠陥です。今後、関連企業はプライバシー保護ポリシーをさらに強化し、透明なソースコード公開を通じてユーザーの不安を解消する必要があります。そうしなければ、今回の事態のように徹底的なリバースエンジニアリング分析によって素顔が暴かれ、激しい逆風を浴びることになります。読者の皆様も、外部と接続されるすべての開発ツールを使用する際は、ネットワークトラフィックを定期的にチェックする習慣を身につけるべきです。自らのコードを守る最も確実な方法は、徹底的な疑いと検証から始まるという事実を忘れないでください。
今回の事件は非公開コーディングツールの危険性を教えてくれ、今後は透明性とデータ処理過程を厳格に検証する必要があります。
よくある質問
=