「それは、本当に安全なんですか？」　セキュリティ専門家が「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のものでもないけれど、もしかすると我々のものでもないかもしれない、というリスクがあります。

なので、これはちょっと注視する必要のある状況ではないかと思います。

そのほかのリスク　いきなり規約が変更される可能性がある

アウトプットを利用するリスクに関してはこんなものですが、ほかにもいくつかリスクがあると考えています。

1つは、いきなり規約変更がされる可能性があること。これはSaaSあるあるなのですが、GitHub Copilotを使い始めの頃、何ヶ月か前までは、確か、「ユーザーが訴訟に遭ったらその費用をある程度肩代わりするぞ」と書いてあったのですが、最近消えました。（※）

※ 後日GitHub社に確認したところ、GitHub Copilot の著作権に関する補償に関しては、記載場所が変更されただけであり継続して提供されるとのことです。各種契約における補償の条件に関しては GitHub 社にお問い合わせください。

個人的にも、「この約束はさすがにむちゃじゃない？」と思っていたので、現実的な落としどころに収まったんじゃないかなとは思っているのですが、将来的に、ユーザー側が不利になる規約変更は当然あり得ます。

なぜなら、我々もSaaS提供企業側としてユーザーの不利になる規約変更はやりかねないからですね。人のことは言えないわけです。なので、こういうリスクを盛り込んでおく必要はあると思います。

要は、ちょっと厳しい規約変更が起きたら、我々はその段階で、Copilotを手放す覚悟をしなくてはいけないということです。

そのほかのリスク　プログラミングに新しいパラダイムをもたらしにくくなる

最後は、私の妄想に近いのですが、個人的にはすごく大事なリスクだと思っています。

Copilotは、GitHub上のパブリックコードを学習ソースにしています。であるにもかかわらず、今GitHub上には、Copilotが吐き出したソースコードがどんどん増えていっているはずなんです。

ジェネレーティブAIの教師データとして、ジェネレーティブAIのアウトプットを使う、要は再帰的に学習させるのは精度が落ちる、ご法度だと私は理解しているのですが、Copilotはそれをせざるを得ないはずなんですね。

Copilotが自分の吐き出したコードしか学習しなくなるのであれば、もしかするとCopilotは新しいことをあまり学べなくなるんじゃないかと思いました。

一方で我々ユーザー側は、Copilotがめっちゃ便利なので、どんどんCopilotに依存することになります。ということは、Copilotが提案する、新しさのないコードを無条件で受け入れるリスクがあるんじゃないか。

つまり、我々は今後、プログラミングに新しいパラダイムをもたらしにくくなるんじゃないかというリスクを提言しておきたい。これは、議論してみたいなと思っています（笑）。

これからの開発者に求められること

ということで、最後になりますが、それでもfreeeはCopilotを導入します。これはもう先ほど言ったとおり、さまざまなリスクを上回るメリットがある。我々は、競争力を維持するためになんとしても開発チームの生産性を上げなければいけないんですね。なので、さまざまなリスクよりも生産性向上を優先しました。

ですが、今まで語ってきたように、開発者はちょっとCopilotを前提として、考え方を変えていく必要があると思います。なので我々も、PSIRTとしてはちょっと役割も違っていると思うのですが、今後Copilotを使う開発者にはこういうスタイルで、意識を持ってくださいと伝えようと思っています。

まず1つは、Copilotが提案してきたコードをきちんと吟味できるだけの高い技術力は維持してください。Copilotの言いなりにならないというのが1つ。

もう1つは、Copilotは古いコードしか提案してこないリスクがあるので、新しいことに自らチャレンジする強さが必要ですよ、という点。

この2つは、これからの開発者に必要なものだと思っています。ちょうど15分、ありがとうございました。

（会場拍手）