2021年1月28日に、SMBC他のソースコードが流出する、という騒ぎがありました。
その結果、Twitterのトレンドに上がったり、ニュースにあがったりと、結構な騒ぎになりました。
幸い、今回の漏洩ソースは、それほど大事になるような内容までは含まれていなかったそうで、比較的早く鎮火しました。
・・・とはいえ、一歩間違えば大変になったことであり、一方でその理由が相当おマヌケであったりと、ツッコミどころが満載な事件でもありました。
もう、大概まとめられたり、記事にはされていますが、恐らく今後は漏洩対策の必要性やらの事例にひっぱりだされそうなので、情報源になりそうな記事やキーワードをメモりつつ、自分の今の感想も書いておきます。
まとめサイト・記事
さぶれインパクト
（サ〇ドインパクトとかけたという、なんつー命名だ・・・）
45歳プログラマーさん、警察庁とNTTとSMBCのソースコードを世界に無償公開してしまう
（当時の本人の発言等が残っているため、本人の意識や考えが推察できます。）
【悲報】三井住友銀行 SMBCのソースコード流出 艦これユーザーのさぶれさん 誤ってgithubで公開してしまう
（同じくTwitterのまとめ）
GitHub上に三井住友銀の一部コードが流出、「事実だがセキュリティーに影響せず」
（日経クロステックの記事）
NECもソースコード流出を確認、GitHubで 三井住友銀、NTTデータに続き
（IT Media newsの記事）
GitHubは悪者か？ SMBCのソースコード流出から学ぶ、情報漏えいのリスク
（リスクに関する考察記事。）
問題の原因となったポイントの整理
さて、ここからは私の感想メモ。
今回の事件で、問題の原因となったポイントが複数あり。
それらを箇条書きにするとこんな感じか（多分、人によってはもっとあると思う）。
- なぜ、これらのソースコードを持っていたのか。
- ソースの管理ができておらず、アップロードしたいものかどうかも確認することなくアップロードしていた。
- 本人に法律や契約の知識が欠けており、かつモラルにも欠けていた。
- 個人情報が特定できることをSNSに書いていた。
- Githubの使い方を理解していなかった。
他にも、そもそも発覚の原因となった問題発言やその根底のある思想も今回の場合原因となったが、発火点はまあ千差万別ですし、セキュリティ面での考察にはあんまり関係ないので今回は省略です。
なぜ、これらのソースコードを持っていたのか
そもそも、ソースコードを持っていなければ漏洩もクソもないので、これさえ無ければ、ってとこです。
通常、お客様先で開発する場合は、ソースコードの持ち出しは厳禁なところが基本ですし、昨今ではUSBデバイスすら利用できないようにしてあったりします。
一方、委託契約で開発してもらう場合、または在宅勤務でローカル環境を使う場合は、納品しても手元にソースコードは残ります。
今回の事件では、本人も「SMBCのコードがなんで混在していたかすらわかりません」としらばっくれているため、真相ははっきりしませんが。
プログラムの開発・管理体制によって、不正持ち出しによるものなのか、開発環境で作ったソースが残っていたか、に原因が分かれそうです。
（そうは言っても、委託開発で納品したソースなんてアーカイブして仕舞っておくし、そもそも個人の端末に残させないけどなぁ・・・。）
ソースの管理ができておらず、アップロードしたいものかどうかも確認することなくアップロードしていた
本人のツイートを見ると、「SMBCのコードがなんで混在していたかすらわかりません」や「正直に言うと、覚えていません。 ここにあるコードがいつどこで作ったとか それこそ、今まで食べてきたパンの枚数くらいわかりません。」、「Javaフォルダに入っていたファイルをすべてアップしたから、まぁそんな感じですね。」などという（痛い）発言が見られるので、まあソース管理なんてできていなかったんですね。
よくそんなものをアップロードしようなんて思ったな・・・（汗）。
ここの問題は、そもそもアップロードしていいものかどうかを確認しないままアップロードしてしまっていること。
なにしろ、何のプログラムか確認すらしていないから、SMBC他のソースコードの漏洩に繋がったわけで。
場合によっては、本人が作ったもの以外のソースコードも混じっていた可能性がありますね。
多人数開発の場合、共通機能だったり一部の機能は別の人間が書いていて、それを受け取って開発したりします。
それらを含めて年収計算したとしても、それは本人以外のコードが評価されて高く出てた可能性もあるんですがどうなんでしょうかw
今でもたまに開発をやったりする私に言わせれば、ソース管理がろくにできない開発者なんて、ナンボコードを書いたところで評価は高くないですよ？
今回のやらかしに関する発言を見てると、現場でソースのデグレード事故何回か起こしていそう。
それって開発の足ひっぱるだけなんで、年収300万が妥当に見えてしまうw（流石に安過ぎとは思うけれども。）
本人に法律や契約の知識が欠けており、かつモラルにも欠けていた
この事件の顛末で特に特異なのが、発覚した後の本人があまりにも呑気です。
当初、「特に問題ない」と思っていた節が多くのツイートで見られます。
普通の技術者なら、指摘された段階で真っ青になって対処するようなことを、リプライの発言に押されて渋々対応した、といった感じにみえます。その日の夜も、大分余裕をかまして寝てますし、なんなら翌日も朝食の写真をアップしてるくらい呑気です。
逆に怖えよｗ
法律の専門家ではありませんが、このケースでは著作権法と不正競争防止法に問われる可能性を考えました。
ソースコードは著作物であり、こういった開発では、「納品時に著作権は発注元に移る」という契約にしていることが多いです（ていうかそうじゃないの見たことないかも）。
本人は商用利用じゃないから問題ないと言ってますが・・・いや、あるよ？
他人の著作物を、無料であっても勝手に一般公開しちゃダメだよ？
お金出してわざわざ開発したソースコードを勝手に公開されて、それを他者に利用されてしまったら、れっきとした損害になると思うよ？
不正競争防止法では、秘密に対する「守秘義務」が規定されています。
発注元が納品されたソースコードを会社の資産として「社内限り」や「関係者限り」に指定しているなら、「秘密」に指定されているといえると思いますので、これに引っかかるんじゃないかと思います。
NDAの守秘義務などは会社間の問題かと思いますが、会社と従業員の間でも「誓約書」などで縛ってると思うのですがどうなのでしょうかね（これらに関して、退職後とのことなので、時効が適用されるかどうかはちょっとわかりません）。
今回の当事者は、少なくとも以上のことを考察した上で大丈夫と踏んでいるようには見えない、といった点が問題です。
こういったことは、通常は雇用主側がある程度教育するものなのですが。
ここが、零細企業のＳES契約主体の会社で見かける「教育していない問題」なのかもしれません。
個人情報が特定できることをSNSに書いていた
SNSで実名で投稿すること自体は、私としてはそこまで問題があるとは思いません。
そういった場合、自分の発言に責任を持っていますし、それ故に慎重な発言になります。
私も、このブログでもTwitterでも特に名前を隠してはいませんし（単に、無名で誰も興味もたないだけだよんｗ）。
今回の場合、匿名のつもりで割と無責任な発言をしつつ、過去の発言を漁ると、本来は書く必要のない情報まで暴露してしまっていた、という点が問題を大きくしています。
Githubの情報も、公開する気が無かったのならば、関連する情報をネット上に載せなければあるいは発覚しなかったのではないか、といったところです。
（そういった意味では、大量のコードの中に同様に不用意にアップロードされたソースとか結構ありそうだなぁ）
Githubの使い方を理解していなかった
私もGithubはアカウントを持っていますが、リポジトリ作成時の設定はデフォルトで公開状態となっています。
昔は無料ユーザは公開のみでしたが、最近は無料ユーザでも非公開を選択できるようになっています。
「Githubの使い方がよくわかっていなかった」と釈明していますが、アカウント作ったときに原則公開になることがメッセージで出てたと思います（ただし英語）。
クラウドで「うっかり公開状態になっていた」の情報漏洩事件と同じ構図ですね。
もっとも、外部のサービスを利用するなら、公開状態にしておかないと参照できなかった可能性がありますが。
事件の根本原因と対策は？
ソースの持ち出し制限はできるか？
今回の事件は、悪意はないもののソースを持ち出してしまっていて、それを不用意にアップロードしてしまっていたことが根本的な原因となっています。
もし、本人が最初からソースコードを持ち出して他者へ渡すつもりであったなら、それは可能であった、ということでもあります。
こう考えると、そもそもソースコードを持ちだせてしまったことが問題ではあります。
しかし、これは開発環境がどうだったか、によって大きく変わります。
委託、請負といた契約の場合、ソフト開発会社で作業することもあります。
（というか、委託、請負なのに発注元ベンダーで作業するのって、冷静に考えて違和感あるの私だけ？）
その場合、ソースコードの管理はあくまでソフト開発会社の責任で、発注元は管理することができません。
開発が一旦終わった後も、瑕疵担保期間の対応、保守や改修といった理由でソースは残されますし、場合によっては環境も残ったりします。
発注元が本当にソースの流出を防ぐための施策をするとなると、自組織内で環境を構築し、かつソースやデータを持ち出せない仕組みを導入した上で、その環境で開発してもらう必要があります。
ソフト開発会社に開発を丸投げする場合、発注元は契約等で縛ることはできても、技術的にはソフト開発会社で開発を担当する人が持ち出してしまうことを完全に制御することは難しいと思われます。
社員教育は？ＳES契約等の問題点はないか？
今回は産業スパイなどではなく、あくまで「うっかりミス」であることもポイントです。
このケースでは、無知な点がツッコミどころ満載なことも、Twitterで盛り上がってしまった要因のように感じます。
いやだって、普通は「Githubで業務で開発したソースコードが公開状態になっている」なんて指摘されたら、普通大慌てで対応するもんだろう？
それを、そのことの重大さをよりによって本人が一番理解していなかった、という点が問題を大きくした感があります。
モラルとしても、客のソースコード等は勝手に公開はもとより、持ち出すこともご法度ということが頭にないことも大きいでしょう。
ニュースなどでは、色々な漏洩事件が報道されているハズなのですが、それらについても知らなかったのかもしれません。
法的知識もかなり的外れです。
著作権が関係することくらいは知っていたようですが、そもそも業務で作成した著作権がどこにあるのか、ちゃんと理解していたかどうかは疑問です。
「自分が書いたコードは自分に著作権がある」わけではなく、契約次第となりますが、通常の開発では開発したソースコードは発注元に著作権が移ります。
もちろん、他人の著作物を他人が勝手に公開してもいけません。
また、今回は不正競争防止法が関連する可能性もありますが、その点については全く触れられていません。
多分、知らないんじゃないですかね、この法律自体を。
こうなってくると、「知識不足によって、やってはいけないことが分からない」という状況になります。
こういったことは、プロなら知っていて当たり前、ではあるのですが、それでもこういう事態にならないよう、通常は社員教育としてやります。
人間忘れたり、法律も改正されたり新たに作られたりするので、面倒でも年１回くらいは教育したほうがいいでしょう。
今回の漏洩ソースは数年前のものらしく、事件当時勤めていたＦ社さんで開発したものではないようですが、この会社に入社した時や年間での教育は、恐らくやってなかったから知らなかったのだろう、と思います。
資本金300万円程度の中小企業やベンチャーに余力が無いのは分からなくもないですが、そんなこと言っていてこういう事件を起こしたら、ビジネスどころじゃなくなると思うのですけどね。
ちなみに、開発する対象によっては、別の法律が関与することもあります。
私は元自衛官ですが、ソフトウェアを民間に委託開発することはありました。
こういったプログラムのうち、モノによっては納品後に「秘密」指定されるものがあったのですが、もし「秘密」指定後にプログラムが漏洩したら、「自衛隊法」に引っかかり、ガチで刑事事件の実刑判決になる可能性があるからね？
さて、今回は特にSMBCさんが目立ってしまいましたが、ではSMBCさんが彼を教育していなかったのが問題ではないのか？ということになりますが。
これは、当時の契約状況によります。
彼がもし、SMBCの従業員、もしくはその子会社の従業員だったとしたら、SMBCさんは当然教育をすべきでしたし、開発環境もソース漏洩など起きないような環境を用意すべきだったと言えるかもしえません。
しかし、もし委託やSES契約であった場合、話は違ってくるでしょう。
委託の場合は、開発自体を依頼して丸投げするので、受託した会社が責任もってやる必要があります。
面倒くさいのがSES契約です。
個人的には、この契約形式は大嫌いです。
「SES契約にはメリットもある」とは聞きますが、開発で散々SES契約で派遣されていた身からすれば、はっきり言って「発注側」と「受注側」の会社としてはメリットあるかもしれませんが、当の働いている人間にはメリットらしきものは存在しませんでしたよ。
っていうか、単にしわ寄せを現場の個人に押し付けてるだけだろ、アレ。
それを、さも「スキルのあるプロフェッショナルに適した契約」と言い、現実はアホみたいに安く買いたたくから、開発要員は安月給で使い捨てにされている、という現実があります。
本当にSES契約が素晴らしいものなら、私だって開発辞めてないよ？
まあ、これがSES契約で働く労働者の悲哀では済まなくなりそうなのが、今回の事件から見て取れるのですが。
SES契約の場合、契約としては「準委任契約」に該当するそうです。
その上で、「客先で常駐する」といったことが行われるケースが多いです。
これは、傍目（他の業界）から見れば「派遣契約」に見えるかもしれませんし、現場で働く実態としてはさほど変わりません。
では「派遣契約」にすればいいと考えるのですが、「派遣契約」の場合、人の管理は派遣される側が負う責任が相対的に大きくなります。
また、派遣する側もライセンスが必要だったりするため、小規模の事業所では取得が難しいこともあるようです。
このため、派遣される側は管理責任の縮小および必要時のみの労働力の確保を、派遣する側はライセンス等を取得しなくて済む、という点でメリットがあり、利用されています。
しかし、実質的には「偽装請負」になっていることも多く、請負や委任の契約なのに、派遣先の社員に休日出勤や残業を強要されるなんてザラでした。
このような環境では、そもそも現場で働く労働者に、順法精神もクソも育つわけもなく、そういったことを学ぶモチベーションも沸きません。
二束三文で安く買いたたいておいて、「何がプロフェッショナルだ」ってことです。
また、SES契約の場合、派遣される側は管理責任が小さい代わりに、契約上はその人に「教育」を施す立場ではなく、義務もないということになります。
そういったことは、やるとしても派遣する側ということになります。
しかし、肝心の派遣する側は小規模であることが多く、会社の運営といっても派遣した人に応じて派遣先からもらうお金の何割かを会社に入れる程度のことしかできないので、あまりスケールできません。
このため、小さな会社では実質何もしておらず、会社の経営者も「雇っているのはプロだから」と言い訳していることが大半です。
（まあ、私も今いる会社では受けたことはないんですが、「だってお前、情報処理安全確保支援士じゃん？」ってツッコまれそうだし、それこそ知ってて当然（むしろ指導する立場）なので、特に気にしたことないんですけどね。）
今回のようなケースでは、「都合がいいから」といってSES契約を利用した結果、実際はモラルや法的知識の方は不十分であったにも関わらず、適切な指導を受けないまま人が働いている、という状況が作り出した事件かもしれない、と元開発者は思ったりします。
管理や教育・指導コストの削減を進めた結果そういう状態になってしまったのであれば、まあ自業自得ですし、本懐だったんじゃないでしょうか。
しかし、今後は「管理への関与を減らす＝リスクが増える」ということが増え、顕在化してくるんじゃないかと思います。
（少なくとも、そう思えるくらいには数年前の開発現場の人の扱いは酷かった。）
派遣元の会社がきっちり管理・教育・指導できるところと契約するか、偽装請負を止めて派遣契約にして自社で管理・教育・指導するかといったことをすることが、契約に関する法律や短期的なコストの問題以上に重要になってくるのも遠くはないのかもしれませんね。
まとめ（まとまらない）
個人的な感想のメモで、結局内容がまとまってないのですが。
オチとしては以下かなと。
- ソースコードや設計書などの漏洩の原因となる持ち出しに対し、技術的な制約でコントロールする
- 技術者に必要な教育・指導を行う
「産業スパイもいるので、ソースコードや設計書を持ちだせないようにすればOKなのではないか」と言われれば、身も蓋もないのですが。
そうはいっても、長年プロジェクトに携わっていた人であれば、仕組みや仕様、ノウハウなどは全部頭に入ってしまいますよね。
そして、その人の脳内にあるものを消すことはできず、したがってそういった持ち出しまで含めると、止めるのなんて不可能なわけです。
そういったものも含めると、今回のような「悪意ない漏洩」もリスクの一つになってきます。
IT技術者はITに関するプロであって、必ずしも法律等に詳しい訳ではなく、頭の中にある内容を漏らすことが特許や著作物を侵害する恐れがある、といったことまで知らないこともあります。
今までは、人の管理・教育の責任の所在をうやむやにして、結局誰もやらないということが多かったと思いますが、今後はそうも言ってられなくなるんじゃないかなぁ、と考えさせられてた事件ではありました。