• 特集
  • 番組
  • トピックス
  • 学び
プレミアムを無料で体験

SMBCのソースコード流出で考える「自覚の無い情報漏洩」。企業が認識すべき新たなリスク

Yahoo!ニュース 個人
230
Picks
このまま本文を読む
本文を読む

コメント


のアイコン

注目のコメント

  • badge
    株式会社レクター代表/日本CTO協会理事 朝日新聞社社外CTO

    大前提として、GitHubはオープンソース、企業での開発問わず広くソフトウェアエンジニアに世界中で用いられている共同開発のためのプラットフォームであり、ソフトウェア開発における生産性向上の入り口として機能するサービスである。マイクロソフトが8000億以上の金額でGitHubを買収し、SaaS戦略の一等地に据えている。

    このようなデファクトスタンダードなサービスであるため、GitHub連携をする開発者ツールは非常に多い。多くの開発者は日常的にGitHubに触れていて、趣味の開発からOSSヘの貢献をおこなっている。

    そのため、これらの活動を分析することでソフトウェアエンジニアとしての能力を見極めようとすることは自然な発想で、そこからFindyのような年収診断サービスが生まれた。これもまた自然な進化であるように思う。

    しかし、このような商習慣から随分と離れたところに、一部の日系企業においてレガシーなインフラ企業の案件で働くプログラマ/SEたちがいる。特に金融機関で長年キャリアを持ってきた方であれば、GitHubを日常的に用いるような開発案件はあまり経験がないということも多いのではないだろうか。

    今回のケースでは、GitHubにあげたことはもとより、自身しか見えない設定すらできていないというレアな状況が起きているのは、それだけ文化のギャップがあったということだろう。

    このケースから推察されるような生産的なソフトウェア開発環境を作る基点でデファクトであるサービスを利用できない環境は日本にはまだ多くあり、また使えている技術者もそのような動向を一から説明して納得をいただいた結果として使えているというギリギリの状況である開発現場も少なくない。

    そのため、エンジニアコミュニティではこれを契機に理解を勝ち得てきたGitHub導入への道筋が遠のくのではないかという恐怖と不安を抱えている。企業が認識すべきリスクは、あまりにも世界のスタンダートからかけ離れた環境での開発環境を提供していると、このような自覚のない情報漏洩が起こるという話であるし、リスクへの対処は実際の開発者の声の届く範囲での経営を行うことではないだろうか。

    追記:
    「オープンソースでないとGitHubを使わない」コメントがあるが全くの事実誤認です。多くの企業でクローズドソースのシステム開発に使われています。


  • NewsPicks Fellow

    GitHubをはじめとする、ソースコードを保管したり解析させたり実行したりするサービスは、オープンソース開発じゃなくても仕事で普通に使われるようになってきたのがこれまでの10〜15年です。

    しかしながら、20年以上の歴史のある会社では普通というほどにはなっていなくても不思議ではありません。本件に関して詳しく追いかけてるわけではないですが、デフォルトで公開設定なんて知らなかったという発言から、そのような常識の違いが見えてきます。

    この記事の趣旨は、知らない人は知らないので教育をしっかりしましょうというものです。教育も大事かもしれませんが、リスクマネジメントの話ですから、費用対効果に応じて多重の対策をしておくべきです。

    ・教育、啓蒙
    ・雇用契約、業務委託契約の守秘義務
    ・そもそもソースコードが流出してもリスクが無いようにする
    ・外部サービスを使わないで開発する
    ・開発に使うネットワークや端末を制限する

    などなど、下にいくほど強固な制限になりますが、同時に非現実的になります。(開発者を採用しにくくなったり)

    ソースコードが流出してもリスクが無いようにするというのは長年培われた業界の落とし所です。多くの会社(といっても常識の違いはあるかもしれませんが)ではこのぐらいまでは現実的にできる対策ということになっているはずです。


  • トヨタ自動車(株) Digital Innovation Garage エンジニア

    オープンソースに関して、
    ①ネガティブな動機から隠す、
    ②ポジティブな動機から公開 を識別して
    古い習慣からの進歩を狙うのが良いと思います。

    ①ネガティブに隠す動機は、例えば
    設計や実装の稚拙さを披露してしまわない様に、隠したくなるかも知れません。

    また、ナンバリング設計が露出すると危険だと考える人もいるかも知れません。(情報処理技術が発達した今、そこは心配しても防御力を高くできないと思います)

    古いソースコードなら、鍵データがベタ書きされた体たらくも心配でしょうか。定数ベタ書きでスケーラブルな設計でないと見えるなら、そこは ワルにとって好都合な情報でしょう。

    ②ポジティブな動機の為には、言うまでもありませんが、コラボレーションを狙います。

    進歩すべきは、
    ①に関しては、
    a.オープンにしても 競争力に影響しないビジネスモデル
    b.鍵はソースに書かない、クラウドネイティブ設計
    c.スケーラブルな設計

    ②に関しては、
    A.ライセンス明記
    B.DevOpsな開発、そのメリット高めるビジネスモデル
    C.アジャイル開発チーム
    D.オープンソース コミュニティ運営

    日本のICTが益々発展する事を切に願います。


アプリをダウンロード

NewsPicks について

SNSアカウント


関連サービス


法人・団体向けサービス


その他


© Uzabase, Inc

新しい記事ページ
を表示しています

ご意見・ご要望はこちらまで

マイニュースに代わり
フォローを今後利用しますか