TOP /  セキュリティ/認証 /  オープンソースの脆弱性で不正アクセス、その責任は誰が負うのか?

オープンソースの脆弱性で不正アクセス、その責任は誰が負うのか? | セキュリティ/認証

講演資料を見るには、 プライバシーポリシーに同意して、送付先メールアドレスをご入力しご請求ください。

またご入力いただきました情報は、当該イベントの主催・共催・協賛・講演企業とも共有させていただき、 当社及び各社のサービス、製品、セミナー、イベントなどのご案内に使用させていただきます。

メールアドレス


法人様向けの資料のため、フリーアドレスをご利用の場合は、会社名、お名前を入力してください。
会社名
お名前

オープンソースの脆弱性で不正アクセス、その責任は誰が負うのか?  (西村あさひ法律事務所 仁木 弁護士)

アジュールパワーが考える今後のIoT(仮)  (アジュールパワー株式会社 (調整中))

ソフトウェア品質保証におけるテクマトリックスの取り組み(仮)  (テクマトリックス株式会社 (調整中))

オープンソースの脆弱性に対処する方法/WhiteSorceによる診断事例  (GDEPソリューションズ株式会社 (調整中))

MosPをWhiteSourceで診断してみた  (株式会社マインド 屋代 和将様)

講演資料を見るには、 プライバシーポリシーに同意して、送付先メールアドレスをご入力しご請求ください。

またご入力いただきました情報は、当該イベントの主催・共催・協賛・講演企業とも共有させていただき、 当社及び各社のサービス、製品、セミナー、イベントなどのご案内に使用させていただきます。

メールアドレス


法人様向けの資料のため、フリーアドレスをご利用の場合は、会社名、お名前を入力してください。
会社名
お名前

セミナー全体の評価と、参加者からのコメント

参加者によるこのセミナーの評価は、
3.6 でした!(5点満点中)
セミナー名 オープンソースの脆弱性で不正アクセス、その責任は誰が負うのか?
講演企業 西村あさひ法律事務所 、アジュールパワー株式会社 、テクマトリックス株式会社 、GDEPソリューションズ株式会社 、株式会社マインド
開催日 2018年01月25日
匿名の参加者
コメントなし
その他のIT関連業 40代 男性 の参加者
コメントなし
製造業 20代 男性 の参加者
コメントなし
製造業 40代 男性 の参加者
弁護士さんのOSSリスクの説明が倍くらい詳細に欲しかった。
企業に対してITを提供する企業(ベンダー、SIerなど) 50代 男性 の参加者
コメントなし
製造業 50代 男性 の参加者
WS活用事例を提示してもらえた。
企業に対してITを提供する企業(ベンダー、SIerなど) 50代 男性 の参加者
コメントなし
匿名の参加者
コメントなし
企業に対してITを提供する企業(ベンダー、SIerなど) 30代 男性 の参加者
もう少し弁護士の話が多ければよかった。
企業に対してITを提供する企業(ベンダー、SIerなど) 40代 男性 の参加者
コメントなし
企業に対してITを提供する企業(ベンダー、SIerなど) 30代 男性 の参加者
コメントなし
株式会社アシスト 橋本隆志さん
コメントなし
匿名の参加者
知識不足でむづかしかった。
その他のサービス業 40代 男性 の参加者
コメントなし
匿名の参加者
コメントなし
医療業・福祉業 30代 男性 の参加者
コメントなし
企業に対してITを提供する企業(ベンダー、SIerなど) 60代以上 男性 の参加者
実例が少なく概念的なことはわかるが効果が実感できない。
企業に対してITを提供する企業(ベンダー、SIerなど) 40代 男性 の参加者
コメントなし
匿名の参加者
コメントなし
製造業 60代以上 男性 の参加者
コメントなし
匿名の参加者
コメントなし
企業に対してITを提供する企業(ベンダー、SIerなど) 30代 男性 の参加者
タイトルにあげている「OSSの脆弱性で不正アクセス、その責任はだれが?」という部分のご説明、事例をもう少し多く紹介していただきたかったかなと思います。
匿名の参加者
コメントなし
匿名の参加者
コメントなし
製造業 40代 男性 の参加者
コメントなし
匿名の参加者
リスク管理ツールという視点から話をしていたからかと思いますが、リスクの視点が強かったような気がします。
出版・放送・その他メディア 40代 男性 の参加者
コメントなし
企業に対してITを提供する企業(ベンダー、SIerなど) 40代 男性 の参加者
コメントなし
製造業 40代 男性 の参加者
コメントなし
教育業 40代 男性 の参加者
コメントなし
匿名の参加者
FA向け制御機器+ソフトの開発、製造、販売を業務としていますが、ユーザから、AIの組込要求が高まっています。これから、AIの組込みにトライするに先立って、OSSに関する予備知識を得たく、参加させていただきました。ありがとうございました。
消費者に対してITを提供する企業(Webサービス、ゲームなど) 30代 男性 の参加者
机上に配布済みの資料の中に本セミナーの資料があるなら「プログラム」紙面に「※配布資料はございません。」と書かないで欲しかった。メモが大変だったので。
企業に対してITを提供する企業(ベンダー、SIerなど) 30代 女性 の参加者
OSSのライセンスについて、弁護士の方の視点でのお話を伺えてよかったです。
匿名の参加者
コメントなし

オープンソースライセンスの類型化から
⾒える法的リスク
⻄村あさひ法律事務所
弁護⼠ 仁⽊ 覚志
2018年1⽉25⽇
近年のOSSの状況

2013年頃から、急増。MIT、Apache、GPLが⼤半を占める
(https://github.com/blog/1964-open-source-license-usage-on-github-
com)
2
Licenses by Name
近年のOSSの状況
The following licenses have been approved by the OSI. The parenthesized expression following a license name is its SPDX
short identifier (if one exists).




















2-clause BSD License (BSD-2-Clause)
3-clause BSD License (BSD-3-Clause)
Academic Free License 3.0 (AFL-3.0)
Adaptive Public License (APL-1.0)
Apache License 2.0 (Apache-2.0)
Apple Public Source License (APSL-2.0)
Artistic License 2.0 (Artistic-2.0)
Attribution Assurance License (AAL)
Boost Software License (BSL-1.0)
BSD License: See 3-clause BSD License and 2-clause BSD License
BSD+Patent (BSD-2-Clause-Patent)
CeCILL License 2.1 (CECILL-2.1)
Computer Associates Trusted Open Source License 1.1 (CATOSL-1.1)
Common Development and Distribution License 1.0 (CDDL-1.0)
Common Public Attribution License 1.0 (CPAL-1.0)
CUA Office Public License Version 1.0 (CUA-OPL-1.0)
EU DataGrid Software License (EUDatagrid)
Eclipse Public License 1.0 (EPL-1.0)
Eclipse Public License 2.0 (EPL-2.0)
eCos License version 2.0

 1/22時点で、Open Source Initiative(OSI)が認定しているだけでも83件の
OSSライセンスが存在(https://opensource.org/licenses/mit-license.php)
3
AIとOSS

特に、AIのプログラムはOSSとして公開されていることが多い。代表的な
ものは下記のとおり。
プログラム名
開発元
ライセンス条件
Chainer MIT License
TensorFlow Google Apache License 2.0
Caffe BVLC BSD License
CNTK Microsoft MIT License
Torch7 Facebook BSD License
amazon-dsstne

Preferred Networks, Inc Amazon Apache License 2.0
単なるコモディティ化を超えて、AIのプログラムが社会インフラとして積極
的に共有化される「⺠主化」のフェーズに移⾏したと評価する者も。
4
OSSの定義
 以下の10要件。原⽂はhttps://opensource.org/osdに掲⽰されて
いる。
1. 再頒布の⾃由
無料で再頒布することを制限してはならない。
2. ソースコード
ソースコードが含まれており頒布が許容されていなければならない。
3. 派⽣ソフトウェア
派⽣ソフトウェアの作成と、同じライセンスの下で頒布することが許容
されていなければならない。
4. 作者のソースコードの完全性(integrity)
ソースコードとパッチファイルを頒布する場合に限り、ライセンスによ
って変更されたソースコードの頒布を制限することができる。
5. 個⼈やグループに対する差別の禁⽌
特定の個⼈やグループを差別することは禁⽌される。
5
OSSの定義
6. 利⽤する分野(fields of endeavor)に対する差別の禁⽌
特定の分野でプログラムを活⽤することを禁⽌してはならない。
7. ライセンスの分配(distribution)
再頒布の際に追加的なライセンスへの同意を義務付けてはならない。
8. 特定製品でのみ有効なライセンスの禁⽌
特定のソフトウェアに依存してはならない。
9. 他のソフトウェアを制限するライセンスの禁⽌
頒布の際に⼀緒に頒布される他のソフトウェアを制限してはならない。
10.ライセンスは技術中⽴的でなければならない
ライセンス中に、特定の技術やインターフェースの様式に強く依存する
ような規定があってはならない。
6
OSSライセンスの類型

OSSの代表的なライセンス条件はコピーレフト概念の適⽤状況によって、⼤
きく、①コピーレフト型、②準コピーレフト型、③⾮コピーレフト型に分類
できる。
 コピーレフト(Copyleft)とは、著作権(Copyright)に対する概念。ソフトウェ
アの著作権者が、その著作権を保持したまま、公衆に対して⾃由な利⽤、改
変、頒布を許諾し、⾃由なソフトウェアの流通を図る考え⽅。
オリジナルソフトを オリジナルソフトと
改変した部分の 結合したソフトウェアの
ソースコード開⽰ ソースコード開⽰
コピーレフト型 要 要
準コピーレフト型 要 不要
⾮コピーレフト型 不要 不要
カテゴリ
7
OSSライセンスの類型

代表的なライセンス条件を分類すると以下のとおり。
カテゴリ
ライセンス
ライセンス作成者
コピーレフト型 GNU General Public License
(GPL)
Free Software Foundation (FSF)
準コピーレフト型 Mozilla Public License (MPL) Mozilla Foundation
GNU Lesser General Public Eclipse Public License (EPL)
License (LGPL)
⾮コピーレフト型
FSF
Eclipse Foundation
BSD License University of California, Berkeley
Apache License Apache Software Foundation
(ASF)
MIT License Massachusetts Institute of
Technology
ISC License Internet Systems Consortium
Artistic License Larry Wall ⽒
8
OSS利⽤に伴うリスク
 OSSライセンス違反のリスク
 特許に関するリスク
 脆弱性
 その他
9
OSS利⽤に伴うリスク
 OSSライセンス違反のリスク
 多くの訴訟案件がGPLライセンス違反。もっとも、⾃主的に改善された
例も多く、訴訟に⾄ったものはごく⼀部か。

FANTEC事件(2013年)
• 原告Harald Welte⽒/被告FANTEC GmbH
• FANTECが配布したメディアプレーヤーにGPLv2のOSSが含まれてい
たが、開⽰されたソースコードには当該OSSが含まれていなかった
• Free Software Foundation Europe主催のコンプライアンスハッキン
グワークショップで発覚
• 原告勝訴
損害賠償請求(弁護⼠費⽤含む)認容
ソースコードの開⽰が命じられる
下請のサプライヤーの保証責任に依存するのは不⼗分。FANTECに最
終的な責任ありと判⽰
10
OSS利⽤に伴うリスク
 OSSライセンス違反のリスク ー CopyLeft(伝播性)の問題

伝播性の範囲
動的リンクの場合は、GPL・LGPLに従う必要はない? ⇒ NO
FAQ(https://www.gnu.org/licenses/gpl-faq.html.en#GPLStaticVsDynamic)
• Does the GPL have different requirements for statically vs dynamically linked modules with
a covered work? (#GPLStaticVsDynamic)
No. Linking a GPL covered work statically or dynamically with other modules is making a
combined work based on the GPL covered work. Thus, the terms and conditions of the
GNU General Public License cover the whole combination. See also What legal issues
come up if I use GPL-incompatible libraries with GPL software?
• Does the LGPL have different requirements for statically vs dynamically linked modules
with a covered work? (#LGPLStaticVsDynamic)
For the purpose of complying with the LGPL (any extant version: v2, v2.1 or v3):
(1) If you statically link against an LGPL'd library, you must also provide your
application in an object (not necessarily source) format, so that a user has the
opportunity to modify the library and relink the application.
(2) If you dynamically link against an LGPL'd library already present on the user's
computer, you need not convey the library's source. On the other hand, if you
yourself convey the executable LGPL'd library along with your application,
whether linked with statically or dynamically, you must also convey the
library's sources, in one of the ways for which the LGPL provides.
11
OSS利⽤に伴うリスク
 特許に関するリスク
OSSライセンスは、特許までも⾃由に使えることを、当然には意味しな
い。



GPLv2では、OSSを頒布した者が受領者に対して特許を⾏使できるか否かに
ついて明⽂無し。
GPLv3では、受領者に対する必須特許のライセンスを明記。MPL、Apache
License等も特許ライセンスを明記。
GNU GENERAL PUBLIC LICENSE Version 3
(https://www.gnu.org/licenses/gpl-3.0.ja.html)
Each contributor grants you a non-exclusive, worldwide, royalty-free patent
license under the contributor's essential patent claims, to make, use, sell, offer
for sale, import and otherwise run, modify and propagate the contents of its
contributor version



他⽅、MIT、BSD License等では特許ライセンスが明記されていない。
また、上記の特許ライセンスは、OSSを頒布した者以外の特許ライセンスを
含むものではない。
特にOSSはソースコードが公開されている以上、侵害⽴証が容易
(RedHatがNPEであるIP Innovationに特許侵害訴訟を提起された事例)
12
 脆弱性
OSS利⽤に伴うリスク
多発するOSSの脆弱性問題


2014年のOpenSSLのHeartbleed、DNS、Apache Struts2…
ベンダーが負うべき責任の⽔準(東京地裁平成26年1⽉23⽇判決)

ベンダーが開発した受注システムのセキュリティの脆弱性に起因して顧客の
クレジットカード情報が流失し、ユーザが損害を被ったという事案

被告は、OSSであるEC-CUBEをベースとしてシステムを構築

判⽰内容
① 流出の原因はSQLインジェクション
② (契約書に明記されていなくても)その当時の技術⽔準に沿ったセキュリティ
対策を施したプログラ⼛を提供することが黙⽰的に合意されていた
③ 経産省が2006年2⽉にSQLインジェクション対策を実施することを求める注
意喚起を発し、IPAが対策としてバインド機構の採⽤⼜はエスケープ処理を
実施する必要があることを明⽰ ⇒ 上記②の債務不履⾏を認定
④ 結果の予⾒容易性・回避容易性を共に肯定し、重過失を認定

13
ご清聴ありがとうございました。
仁⽊覚志 ⻄村あさひ法律事務所
(s_niki@jurists.co.jp)



弁護⼠
94年⼤阪⼤学⼯学部卒
94年から01年まで(株)IHIにおいて航空機エンジンの開発
に従事。
06年に弁護⼠登録ののち、14年までパナソニック(株)の
知的財産権部⾨に所属。14年5⽉より⻄村あさひ法律事務
所に所属。
本資料中、意⾒に関する部分は個⼈の⾒解であ
り、所属する組織の⾒解ではありません。
本資料の無断複製・転載を禁じます
©2018 仁⽊覚志
14

他のカテゴリから探す

IT業界の改革にご協力いただけませんか?

本サイトは、株式会社オープンソース活用研究所がプロデュースする、中小IT企業による”本気”の情報提供セミナー「マジセミ」の結果レポートページです。「マジセミ」は、次を目的として活動しています。

我々はITエンジニアが、今よりももっと「誇り」と「喜び」をもって仕事をし、今よりももっと企業や社会に貢献できる、そんなIT業界を創りたいと考えています。

そのためには、技術をもった中小のIT企業がもっと元気になる必要がある。その為には、技術をもった中小のIT企業を、もっと皆様に知って頂く必要がある、と考えました。

株式会社オープンソース活用研究所
代表取締役所長 寺田雄一

本当かウソか、あなたが見極めてください。

もし、我々のこの活動にご賛同していただけるのであれば、ぜひ下のセミナーに参加してください。

「なんだ、結局ただの売り込みセミナーじゃないか」

もしそう感じたら、アンケートなり、あなたのFacebookなりに、そのままお書き頂き、拡散して頂いて構いません。

参加者からのお褒めの言葉、お叱りの言葉が、我々中小IT企業を成長させ、それが日本のIT業界を変えていくのだと、強く確信しています。

あなたの行動が、日本のIT業界を変えるのです。

「マジセミ」のFacebookページ

今後のセミナー情報などを提供させていただきたますので、「マジセミ」のFacebookページに「いいね!」をお願いします。

日本のIT業界を変えるためのアクション、ありがとうございました!

関連するセミナーの講演資料
オープンソースで実現するシングルサインオンの概要(Offce365連携から、会員統合、ソーシャル連携、多要素認証まで) デジタル革命時代の「攻めと守りの認証/ID管理」(基調講演:NIST SP800-63-3 などに見る、サイバーセキュリティ対策の国際動向/みずほ銀行など採用、パスワード不要のFIDO最新動向) 【東京開催】オープンソース「OpenAM」によるシングルサインオンの概要 ~ IDaaS等との比較、導入時の注意点 ~ 【福岡開催】オープンソース「OpenAM」によるシングルサインオンの概要 ~ IDaaS等との比較、導入時の注意点や体験談も ~ オープンソース(OpenAM / Keycloak)によるシングルサインオンの概要と、商用製品やIDaaSとの比較 WordPressサイトを常時SSL化する方法と、常時SSL化による新たな脆弱性問題 クラウド活用+リモートワークのためのIDライフサイクル管理の重要性(基本機能無料のIDaaS SKUID+LDAP Managerでの解決策) 悪意のリモートワーカーを前提にしたセキュリティ対策(情報セキュリティガイドラインをどう改定すればよいのか?) 【SIer向け】顧客企業の「認証・ID管理」の課題を理解し、オープンソース(OpenAMなど)を活用した「刺さる提案」をするために Googleが推奨しているWebサイトの常時SSL化によって、逆に生じるセキュリティ問題があることをご存知ですか?