エンジニアによるGitHub上へのソースコード流出事案、法的責任や類似事案の防止策を伊藤雅浩弁護士が解説 ツールの利用制限ではなく、利用者のリテラシー向上による対策を

2021年1月28日、三井住友銀行（SMBC）が組織内で使用するシステムのソースコードについて、その公開・流失の可能性がSNSを中心として指摘され、翌29日にはSMBCが、行内システムのソースコードの一部と公開されているソースコードが一致したことを確認したと報じられました ¹。その後、NTTデータの子会社であるNTTデータ ジェトロニクスなど複数社における被害の公表も続いています ²。

あるエンジニアによる不適切な情報の取扱いに端を発すると見られる本事案。本稿では、ITコンサルティング企業においてシステムの設計や開発、プロジェクトマネジメント等に従事した経験を持ち、現在はシティライツ法律事務所でシステム開発等に関する紛争処理や、ソフトウェア知財・法務を専門に扱う伊藤雅浩弁護士に、法的側面から特筆すべき本事案のポイントや、クラウドサービスの利用・リスク管理に関して持つべき考えを聞きました。

扱う情報の重大性への理解不足が流出の原因か

本事案の概要と特筆すべきポイントについて教えてください。

本件は、ソフトウェアのソースコードをホスティングするクラウドサービスであるGitHub（ギットハブ）上で起きています。ソースコードのホスティングというと分かりにくいかもしれませんが、保存・共有に用いるツールで、Google Driveや、Dropboxなどに近い用途のツールだとイメージいただければと思います。

本事案では、あるエンジニアがGitHubに保存したソースコードが、設定上、公開状態になっていたことが問題になりました。したがって、本件は、第三者がサーバー等に不正アクセスしたことによって情報が漏えいしたというものではなく、関係者による情報の取扱いが杜撰だったために、外から見える状態にあった、という事案です。

また、このことが明らかになったのは、Twitterユーザ同士の口論がきっかけだったようです。些細なやり取りから事案が発覚しており、しかも、自身の年収を予測するサービスを利用するために外部サービスにソースコードを解析させていたなどといった事実関係からすると、公開設定にしていたエンジニアは、そもそも自分が業務上取り扱う情報の重大性をよく理解していなかったものと思われます。

当該エンジニア個人の問題以外にも、本事案が発生した背景として考えられる原因などはありますか。

システム開発業界は、多重下請構造になっていることが多く、エンドユーザである発注者が大企業であっても、末端のエンジニアがフリーランスのプログラマであることも少なくありません。エンドユーザは発注する際に、発注先の情報管理について厳しい要求をするわけですが、階層が深くなるにつれて、管理の目が行き届かなくなります。

しかも、以前は、利用できるツールが限られたPC等を与えて、物理的にエンジニアを特定の場所に集めて作業をしていたわけですが、コロナ禍でリモートワークも増えていくとなると、情報管理体制を構築し、適切に運用していくことがますます困難になっています。

ソースコードを流出させたエンジニアに問われる法的責任

ソースコードを流出させたとされる当該エンジニアの行為について、どのような法律に抵触することが考えられますか。

まず、営業秘密の不正使用・開示にあたることが考えられます（不正競争防止法2条1項7号）。

ただし、これが当然に該当するというわけでもありません。今回問題となったソースコードは、当該エンジニア自身が記述したもののようですので、「保有する事業者からその営業秘密を示された」といえるかどうかがポイントとなります。委託を受けて開発したソースコードは、委託元が保有・管理するものであり、手元にあるソースコードは、委託元から「示された」ものであると言えるかもしれません。

他方、「不正の利益を得る目的」または「営業秘密保有者に損害を加える目的」（以上「図利加害目的」）に関しては、果たして自分の年収を知りたいという興味本位程度の目的でGitHubにソースコードを保存したりすることが「不正の利益を得る目的」といえるかは微妙なところです。

仮に、営業秘密の不正使用・開示にあたるとなれば、差止請求（不正競争防止法3条）、損害賠償請求（不正競争防止法4条本文）の対象になります。図利加害目的が認められると刑事罰の対象にもなり得ます（不正競争防止法21条1項4号等）。営業秘密侵害に関する刑事罰は、有体物を対象とした財産犯である窃盗罪（刑法235条）の法定刑と同等以上であって非常に重く、10年以下の懲役もしくは2,000万円以下の罰金あるいはこれらの併科となっています。

不正競争防止法の問題を除いたとしても、当該エンジニアは、委託元との間で守秘義務に関する合意をしていると思われますから、債務不履行（民法415条）にあたる可能性はあります。しかし、一般的な守秘義務を定める条項では、守秘義務の対象を「相手方から開示された情報」などと定めています。先に述べたように、委託業務のなかで新たに開発した成果物は、定義次第では守秘義務条項における「秘密情報」にあたらない可能性があります。余談になりますが、情報成果物の作成を委託するケースでは、今回のようなケースを想定して、守秘義務条項の書き方にも気を付けたほうがよいでしょう。

いずれにせよ、開発したソースコードを誰でも見られるようなところに保存し、現にそれが問題となったという場合には、委託元やエンドユーザに対して不法行為責任（民法709条）を負う可能性は十分にあります。

なお、ソースコードはプログラムの著作物にあたります（著作権法10条1項9号）。業務で使用するシステムで使われるプログラムの場合、開発したソースコードの著作権は、委託元に移転し、最終的にはエンドユーザに帰属することが一般的ですから、このエンジニアに権利が帰属することはまずないでしょう。そのため、無断でGitHub等で公開すれば、著作権侵害（複製権、公衆送信権）にもあたります。

当該エンジニアの雇用企業もしくは委託元企業にはどのような責任が問われることが考えられますか。

当該エンジニアを雇用していた会社はもちろんのこと、当該エンジニアが個人事業主だった場合でも、その委託元は、さらにその元請け事業者やエンドユーザに対し、契約上の責任や不法行為責任を負うことになります。その具体的な内容は、1つ前の設問で述べたことと同様です。

ツールの利用制限ではなく、利用者のリテラシー向上による対策を

SMBCをはじめ、自社のソースコードが流出した企業が、何らかの責任を問われる可能性は考えられますか。

本件だけを取り上げてみれば、エンドユーザであるこれらの企業は被害者であるといってよいです。しかし、一般論として、システムに使用されているソースコードが漏えいした結果、外部の第三者からシステムの脆弱性を突いて不正アクセスが行われる可能性が出てきますので、漏えいをきっかけに自社のシステムが攻撃を受ける可能性がないかどうかを検証し、問題があれば、当該部分の修正をするなどの対応が求められることもあるでしょう。

SMBCやNTTデータなどは、問題が浮上した直後の1月29日、報道において流出の状況等について発信しています ³。こうした被害企業による対応については、どのように評価されますか。

SMBCやNTTデータ ジェトロニクスのほか、以後も続々とGitHubからの情報の流出があったという報告が続いています ⁴。特に今回のケースでは、SMBCらの対応は迅速であり、かつ、「セキュリティーに影響を与えるものではないことは確認済み」とのコメントを出したことは事態の鎮静化を図るうえで意味があったと思います。技術的にみて、当該ソースコードだけからセキュリティ上の脅威となる可能性がなかったのでしょう。

しかし、今回は、たまたま軽微な流出であったため、そのように断じることも可能だったと思われますが、大規模な流出があって影響範囲が読み切れない場合や、与信判断の処理部分など、外部に漏れては困る情報が流出したというような場合には、そう簡単にはいきません。可能な限り事実関係を公表しつつ、問い合わせ対応や再発防止策の策定など、個人情報漏えい事故などと同様の対応が求められます。

今回の事案発生により、GitHubの利用をリスクと捉えることによる、活用の萎縮を懸念する声も見られます。ITツールの利用やリスク管理についてはどのように考えるべきでしょうか。

この点は、2021年2月2日に一般社団法人コンピュータソフトウェア協会（CSAJ）が「GitHubに関する対応とお願い」と題して、非常に明快な文書を公表しています。詳細は、リンク先をご覧いただければと思いますが、ツールの使用を回避するだけではなく、リテラシーの向上や教育を実施することを求めています。また、2月10日には、一般社団法人日本IT団体連盟も「GitHub等の外部クラウドサービス利用に関する対応とお願い」を公表していますが、同じくクラウドサービス利用の委縮に繋がらないように注意喚起しています。

私もこうした事故が生じたからといって、やみくもにGitHubはダメだ、使うな、というべきではないと思います。今後は、GitHubなどのクラウドサービスを使うことは避けられず、その設定方法などのリテラシーを高めるところに注力すべきだと考えます。

今回の事案を考察するうえで参考とすべき過去の事例などはありますか。

弁護士業界においても、かつて、メーリングリストの設定が間違っていたことによって、裁判関係資料が誰でも閲覧できる状態になっていたというインシデントがありました ⁵。つい最近、2021年2月に入ってからも、やはり私たちの業界において、メールの閲覧範囲の設定の変更誤りによって、共有メールの内容が誰でも見られる状態になっており、重要な情報が公開状態になっていたことが明らかになりました ⁶。この種のインシデントは、たまたま公開状態になっていることが判明し、その事実が公表されたために私たちの知るところとなったわけですが、潜在的には非常に多く存在することが想定されます。

また、誰でも見られる状態にあった、という観点では、サーバの権限設定が不十分だったことにより、顧客情報がウェブ上の誰でも閲覧できる状態になり、拡散されたという事案で、被害を受けた個人に対する不法行為責任を認めた事例もあります（TBC事件（東京高裁平成19年8月28日判決・判タ1264号299頁））。

今回のような事案の発生を未然に防ぐためにはどのような対策が考えられますか。

先ほど示したCSAJの文書が参考になります。ツールの使用を制限したりするだけでは悪手でしょう。禁止しても、別の闇ツールに流れていくだけだからです。

SNSでもそうですが、情報を投稿、保存するクラウドサービスの多くは、情報の公開範囲を設定できるようになっています。そうした設定や、ツールの利用規約をよく確認しておくこと、委託先・エンジニアへの教育・指導を徹底していくことが基本的な対策になります。

また、迂遠に思われるかもしれませんが、委託先やエンジニアとの良好な関係を維持するためにも、適切に働くことができる環境や待遇を用意し、高圧的な態度を避けることが今さらながら重要だと感じます。