「それは、本当に安全なんですか？」　セキュリティ専門家が「GitHub Copilot」の全社一斉導入時に考えたあれこれ

freee株式会社 PSIRT マネージャーのただただし氏

ただただし氏：freee株式会社のただただしと申します。

今日は、「GitHub Copilot 導入時に考えたセキュリティのあれこれ」ということで、Copilotのセキュリティリスクについて語るわけですが、考えてみたら、GitHubの中の人を前にこんなことをしゃべるのは相当大胆な話だと思います。最後にいいことで締めるのでちょっと我慢してください。

自己紹介をいたします。ただただしと申します。PSIRTという組織でマネージャーをやっています。PSIRTというのは、プロダクト専門のセキュリティチームです。

そこでプロダクトの安全を守る仕事をしているわけですが、いろいろなことをやりつつ、この1、2年ちょいちょい話題に上がっていますが、freeeの大規模な全社障害訓練の仕掛け人なんかをしたり。

あとは、freeeは先日OSSポリシーを公開したんですが、それを策定していたり。ほかには、定年制度を廃止したりとかですね。エンジニアとは特に関係ないこともしています。

あとは、インターネット老人会のみなさんには、「tDiary」の作者といえばだいたい通じる、そんなところです。

「Copilotを全社一⻫導入するぞ！」に「ちょっと待て！」と言うのがセキュリティチームの役割

さっそく進めていきますが、うちも多分に漏れず、CTOが「Copilotを導入して生産性爆上げしようぜ」という感じで、導入するぜという話になりました。

セキュリティチームがあるというのはどういうことか。こういう偉い人が暴走してしまったら、羽交い締めをしてでも止める権利がある。それが我々セキュリティチームの仕事なんですね。ということで、導入はちょっと待ってくださいと。そのCopilot、本当に安全なんですか？　というところから始まるわけです。

なぜセキュリティチームがきちんといるかというと、freeeという会社は、会計ソフトの会社と呼ばれたりするのですが、最近は、「統合型のクラウドERPの会社です」と言うようになりました。

これはどういうことかというと、「中小企業のあらゆる電子データを集めて、経営に役立つプラットフォームにしよう」というのが我々の現在のミッションなのですが、そういうところで、会計だけでなく人事労務もあるので。従業員のみなさんの個人情報なんかもあります。

あとは、諸々の経営情報が我々のデータベースに一気に集められているので、当然ながら、そのデータの扱いにはシビアにならざるを得ないわけです。

なので、「お客さまのデータをなんとしても守るぞ」という意志を強く持って、我々セキュリティチームは活動しています。そのため、おいそれと簡単に「新しいサービスが良さそうだから入れてみようぜ」とか、そういう軽い気持ちで導入するわけにはいきません。

GitHub Copilotに潜むリスクその1　入力したコードが教師データにされないか？

ということもあって、Copilotにはどんなリスクがあるのかをきちんと分析してみましょう、ということになりました。

大きく分けて2つのリスクがあると考えます。Copilotに入力する際のリスク。それからCopilotで出力を利用する際のリスクという2つの面を考えました。

まずは、Copilotへ我々のソースコードをインプットするリスクについて考えます。

これは実はシンプルで、だいたい2つ考えられるんですね。我々のプロダクトを構成するソースコードのリポジトリのデータや開発者が入力していくさまざまなコード、それからスニペットが、今後Copilotの学習元にされるんじゃないかというリスク。

もう1つ、そうやって入力した我々のソースコードがCopilotを通じて他社に漏洩するリスクも当然ながら考えられると思うんです。

これらについては、もうすでにGitHub側からきちんと回答が提示されていて、まず、「学習元のソースコードは、パブリックなものに限りますよ」と明言されています。つまり、我々企業はたいていの場合プライベートリポジトリを使っているわけですが、「プライベートリポジトリは学習されませんよ」と書いてあるんですね。

それから、「for Business」。ビジネス用のライセンスの場合、「テレメトリ、プロンプト、候補は、GitHub側に保存されませんよ」と書いてあります。学習しないだけでなく、保存もしませんよということですね。

ということで、基本的にそのあたりのリスクはあまり気にしなくてよいということがわかります。

エンジニアの生産性向上＞ソースコード漏洩リスク

一応、「GitHubもこう言っているし、まぁ、大丈夫でしょう」ということなんですが、「そもそもソースコードはどれぐらい大事なものなの？」というのは考えておく必要があります。

実はfreeeは、扱うデータによってセキュリティレベルを決めています。一番上は、企業の財務データや個人情報。より非常にセンシティブな個人情報なんかはセキュリティレベルSとタグづけて、非常に厳重な管理をしています。

それよりも少し緩めでいいものはセキュリティレベルA。次にB。Cは、いわゆる公開情報ですね。我々はソースコードをセキュリティレベルBに置いています。つまり、公開情報よりは多少大切にしなきゃいけないデータレベルのものです。

これはなんでかというと、実はソースコードはそんなに大事じゃないんじゃないかという考え方がベースにあります。ソースコードが仮に漏れたとしても、それは単に、現在のプロダクトのスナップショットに過ぎなくて、本当に大事なのは、そのプロダクトをメンテナンスしたり拡張し続けていく開発チームそのものです。

開発チームのほうが財産としては重要で、仮にソースコードが漏れるリスクと天秤にかけたところで、エンジニアの生産性向上が爆上がりするのであれば、これは優先して採用すべきだろうということなので、ソースコードをCopilotにインプットするレイヤーにおいては、あまりリスクはないよねと考えました。

GitHub Copilotに潜むリスクその2　Copilotが提案してくるコードは本当に安全なのか？

一方で、アウトプットを使うリスクはそこそこあります。

まずは、Copilotが提案してくるコードは本当に安全なんですか？　ということを考える必要があります。

ここにあるスクリーンショットは、Copilotが「SQLインジェクションを含んだコードを提案してきたよ」というツイートなんですが、おそらくこれはですね、フェイクです（笑）。

なぜかというと、このツイートは7月なんですが、GitHubは2月にCopilotがそういう危険なコードを吐かないようにAIベースの脆弱性フィルタリングシステムを組み込んだと発表をしています。

なので、今我々は「CodeQL」を使って静的解析もしているのですが、それよりおそらくCopilotの方が進んだ脆弱性フィルタリングをしているので、こういうものはおそらくないと思います。

とはいえ、ファイルをまたがったり、システムをまたがったりする、いわゆるMisconfigurationと呼ばれる脆弱性は、当然Copilotは考慮してくれないはずなので、このあたりを見抜く力が我々にはやはり必要かなと思います。

次のリスクですね。これは現在進行形ですが、「GitHub、Copilotの学習データに勝手に使いやがったな」というので集団訴訟に直面していますね。要はライセンス違反をしているという指摘がある。「我々が作ったOSSのコードのライセンスを守らずに勝手に使っているんじゃないの？」というかたちで集団訴訟に直面しています。

このあたりは当然、問題になるのですが、Copilot側はそれを回避するために、public codeにマッチする提案はしないという設定を設けています。

これをすると何ができるかというと、要は、学習したソースコードをまるっとコピーして提案してくることはなくなるということです。

なので、仮に誰かの著作物を学習元にしていても、それのデッドコピーが提案されることは今のところはないと考えてよさそうです。

それから、これも最近アメリカで行われている裁判で判例があったものなのですが、これはもともとは「AI-Created Art」と書いてあって、いわゆる画像系の生成AIの出力に著作権はあるかという訴えに対して、「ないです」という判決が出たというものですね。同じようにCopilotも生成AIなので、同じ判例が適用されるおそれがあります。

つまり、我々がCopilotの提案だけで書いたコードは、我々の著作物ではないという可能性があります。

GitHub側がなんと言っているかというと、提案とコードの所有権はユーザー側、我々側にあり、GitHub側にはない。「GitHubは、Copilotが吐き出したコードの著作権を放棄します」と言っているのですが、この判例を見る限りは、GitHubのものでもないけれど、もしかすると我々のものでもないかもしれない、というリスクがあります。