Software 脆弱性法制化

水無月ばけら @bakera

どんな強力なシステムでもリソースは有限なので、リソースを食いつぶして止まることはあり得ます。ただ、今回はハードウェアのリソースには余裕があるはずなのに、ソフトウェアの問題で止まったという話です。これはソフトウェアの欠陥と言って良いと思います。 #librahack

水無月ばけら @bakera

その欠陥について契約上の責任を負うかどうかという話はまた別で、「契約には性能要件がないので性能が低くてもOK」という主張はありえるでしょう。ただし、それはあくまで契約上の責任の有無の話です。 #librahack

ちゃっぴ @tyappi

tyappi 法的観点での欠陥というとまず連想するのは「製造物責任法 (PL 法)」 第二条 第二項 http://bit.ly/aDZ721 であり、以前指摘がありましたが、software はこの製造物責任法の範囲外であるとされています。 #librahack

あろＴＡＫＥ！(ときどき執事＆メイド) @aro_take

#librahack 契約書に書いているのは恐らく瑕疵がどうのこうのくらいでしょうね。だから意地でも欠陥を認めないし認めたくないのでしょう。個々の挙動に関してまで契約には書いてないはずですし、仕様書に書いて承認していたとしても、顧客は素人で判断できないから欠陥なのは確定では？

ちゃっぴ @tyappi

Software は「製造物責任法」の対象となっていないため、技術的常識で欠陥であろうともそれ自体では法的には責任は生じないというのが私の理解です。 #librahack

水無月ばけら @bakera

つまり、技術的に「欠陥がある」という話と、契約上「債務不履行」もしくは「瑕疵がある」という話とは、必ずしもイコールではないのです。「欠陥があるソフトウェアを提供したが契約上の瑕疵ではない」ということはあり得ます。 #librahack

たりき @Vipper_The_NEET

@tyappi ソフトウェア単品ではその通りですが，プリインスコとかパッケージでHWとセットとかの場合はPL法の対象になるという学説が主流ですお #librahack

あろＴＡＫＥ！(ときどき執事＆メイド) @aro_take

だから不具合と言わずに「改善策」という言葉に落ち着く。お互い解った上で実利を取るのが日本的。是非は別だが。 QT @bakera: つまり、技術的に「欠陥がある」という話と、契約上「債務不履行」もしくは「瑕疵がある」という話とは、必ずしもイコールではないので #librahack

ちゃっぴ @tyappi

技術的に致命的な欠陥であるとされる脆弱性ですが、これ自体が法律に触れるわけではなく、別に制定されている法律に触れるから問題とされているというのが私の理解です。 #librahack

たりき @Vipper_The_NEET

参考はこちら http://www.law.co.jp/okamura/PL_Law/index.htm ソフト単品とかインスコメディアは対象外，プリインスコとかHWと一体なら対象，と。細かくはメーカーが同じとかありますが三菱ハードなので大丈夫かと。 #librahack

水無月ばけら @bakera

SQLインジェクション等の脆弱性にしても同様で、これは明らかに欠陥と考えられますが、必ずしも契約上の瑕疵にならない場合があります。契約の仕方によっては、脆弱性の修正は追加費用となる場合もあります。 #librahack

たりき @Vipper_The_NEET

@bakera 瑕疵担保責任を回避するような契約でしょうか。ちょっと想像つかない('A`) #librahack

ちゃっぴ @tyappi

例えば、SQL injection の脆弱性があると DB に個人情報が保存されていた場合、個人情報漏洩の危険性がある。Service 提供者は個人情報保護法に違反するので対策を行わなければならない。 #librahack

ちゃっぴ @tyappi

SQL injection の脆弱性があると潜在的には他の法案に違反する可能性もあるのですが、例としてお考えください。現状ではこんな感じで運用されていると思います。 #librahack

水無月ばけら @bakera

@Vipper_The_NEET たいていの契約では瑕疵担保責任の有無と瑕疵担保期間を明確に定めます。瑕疵担保責任がない契約は見たことがありませんが、期間の短い契約はあり、その後に発覚したものは追加費用ですね。 #librahack

たりき @Vipper_The_NEET

@bakera あー，期限切れですね，納得。 #librahack

あろＴＡＫＥ！(ときどき執事＆メイド) @aro_take

恐らく「当時想定し得なかった」という条件つきでしょうね。新たな攻撃手法とか。 QT @Vipper_The_NEET: @bakera 瑕疵担保責任を回避するような契約でしょうか。ちょっと想像つかない('A`) #librahack

水無月ばけら @bakera

@Vipper_The_NEET また、ある問題が「瑕疵」なのかどうかでもめるケースもありますね。SQLインジェクションは瑕疵であることが明白なのでほとんど問題にならないと思いますが、脆弱性の種類によっては「瑕疵ではない、仕様だ」と主張される場合も……。 #librahack

たりき @Vipper_The_NEET

@aro_take それもありえますね。当時の技術水準というかセキュリティ水準では予測しえなかった場合は免責されてしかるべきと思います。 #librahack

水無月ばけら @bakera

@Vipper_The_NEET ……なので、「この脆弱性は瑕疵だろ」「いや瑕疵じゃない」ともめないように、何があったら瑕疵なのかはっきり分かるような契約の仕方をすることが望ましいですね。 #librahack

ちゃっぴ @tyappi

@bakera 現状では脆弱性に対する法的な扱いはそうなんですよね。なので、発注者側は問題のないような契約および仕様を開発事業者と取り結ぶ必要がある。 #librahack

ちゃっぴ @tyappi

今回の問題は DoS です。DoS となると少なくとも刑事的責任は生じない場合が圧倒的多数でしょうから、法的には発注者と開発事業者間での契約に従って判断されてしまうと思います。 #librahack

たりき @Vipper_The_NEET

脆弱性の修正に関する，何らかの影響を与える法令，かあ。そういやあんまり気にした事なかったな・・・普通に契約内なら修正するもんだと('A`) #librahack

ちゃっぴ @tyappi

なので、この場合発注者が開発事業者と取り交わす契約内容に問題があった。つまり、発注者側に問題があることになるでしょう。これって大きな問題だと思うんですが。 #librahack

ちゃっぴ @tyappi

個人的には software の脆弱性に限っては開発事業者側の責任を問えるような法整備が必要なのではと感じています。 #librahack