ホーム
情報セキュリティ, 脆弱性対応
「脆弱性」と契約不適合、そして欠陥-日経新聞サーチライト記事に関して

「脆弱性」と契約不適合、そして欠陥-日経新聞サーチライト記事に関して

日経新聞サーチライトの記事で、「システム欠陥の報道はダメ?　フェリカ巡り議論、日本流「協調開示」岐路」という記事があります。

この記事のなかで、コメントをさせていただきました。

IPAの有識者会議メンバーの高橋郁夫弁護士は「政府側が間に入り開示時期を調整できる点が画期的だった。まずIPAに報告という流れができ、大きな漏洩は起こらず機能してきた」と振り返る。

となっています。このような記事になる際には、ページ数の都合などから、表現として微妙になったりすることがあります。

1 読み替えについて

上の部分については、

IPAの有識者会議メンバーでもある高橋郁夫弁護士は個人的な見解として「政府側が間に入り開示時期を調整できる点が画期的だった。まずIPAに報告という流れができ、脆弱性対応が開発者の責務という動きができるまでに機能してきた

というように読んでください。

私は、有識者会議のメンバーではありますが、その前に、株式会社ITリサーチアートという会社でネットワーク法に関するリサーチャーをしており、その研究成果をもとに有識者委員会でも発言するというスタンスになっています。メディアさんに対する対応でも、最初に、政府の委員会での議論については、守秘義務がかかっているので、答えません、という話をして対応しています。

なので、お約束ですが、私のコメントは、委員会のメンバーというスタンスとは全く別のものでなされたものです。なので、個人的な見解であるということは、読む際、引用の際に(？-この記事を引用することがあるかは？ですが)留意いただけると幸いです。

あと、「大きな漏洩は起こらず機能してきた」という部分ですが、私としては、このようなお話をした記憶がありません。むしろ、この制度の評価としては、

製品の脆弱性対応窓口を明示する開発者が増え、また、PSIRTを置く開発者/企業も増えてきており、その意味で、あるべき姿に向かっていると肯定的に捉えています

という話をさせていただきました。経緯的には、脆弱性修正の要請が、開発者に対して、何か製品の欠陥を指摘するかのように捉えられてきた時代から、

脆弱性対応については、開発者の責務に含まれる

という認識が醸成された時代に移り変わっていると認識しています。開発者によっては、バグバウンティプログラムを構築して、賞金を取得する研究者もでてきていますし、製品の脆弱性対応窓口を明示する開発者が増え、また、PSIRTを置く開発者/企業も増えてきているというのは、そのような時代の変化を示す要素になると思います。脆弱性については、これを発見し、修正するためのインセンティブというのが、開発者に効きにくい構造になっているわけですが、それでも、脆弱性対応のなされた(なされる)ソフトウエアというのは、それ自体、性能が高いものとして市場によって評価されるのが、あるべき姿なのだろうと思っています。

2 脆弱性を「欠陥」と呼ぶなキャンペーン

2.1 欠陥と脆弱性の違い

個人的には、メディアの対応で、脆弱性を「欠陥」と呼べことがあるのはすごく気になっています。上の日経新聞サーチライトの記事でもタイトルからして「システム欠陥の報道はダメ?　フェリカ巡り議論、日本流「協調開示」岐路」と脆弱性をしめすのに、欠陥という言葉を使っています。

メディアの用語というのは、いろいろいなお約束がありますし、読者が、そもそも用語を知らないといけないという話しもありますが、この早期警戒パートナーシップの議論の早期の段階から、脆弱性を「欠陥」とは呼ばないで、と何か機会があるごとにいっています。

欠陥というのは、法律家が聞いたときには、製造物責任法を.思い出すことになります。

同法3条

製造物責任法第3条

製造業者等は、その製造、加工、輸入又は前条第3項第2号若しくは第3号の氏名等の表示をした製造物であって、その引き渡したものの欠陥により他人の生命、身体又は財産を侵害したときは、これによって生じた損害を賠償する責めに任ずる。ただし、その損害が当該製造物についてのみ生じたときは、この限りでない。

となって、欠陥は、それ自体、責任の要件です。

でもって、欠陥は

２　この法律において「欠陥」とは、当該製造物の特性、その通常予見される使用形態、その製造業者等が当該製造物を引き渡した時期その他の当該製造物に係る事情を考慮して、当該製造物が通常有すべき安全性を欠いていることをいう。

と定義されています(同法2条2項)。ソフトウエア自体については、製造物責任法がカバーしないのは、一般的な解釈です。あと、EUの新製造物責任指令((PLD)2024/2853 )が、

「他の動産又は不動産に組み込まれている、又は相互に接続されている場合であっても、すべての動産を意味し、電気、デジタル製造ファイル、原材料、ソフトウェアを含む。」と定義されている（4条(1)）。

というネタもありますが、ここでは、具体的にふれないことにします。

これに対して、「脆弱性」は、「情報セキュリティ早期警戒パートナーシップガイドライン」においては、

脆弱性とは、ソフトウエア製品やウェブアプリケーション等において、コンピュータ不正アクセスやコンピュータウイルス等の攻撃により、その機能や性能を損なう原因となりうるセキュリティ上の問題箇所です。

と定義されています(同Ⅱ 1)。

外部からの脅威によって
セキュリティ上の問題箇所

であって、それ自体が、「通常有すべき安全性を欠いている」というような評価とは、別個のものとして定義されています。

脆弱性があることが、プログラムそれ自体として「通常有すべき安全性を欠いている」といえるのでしょうか。as isで提供されているソフトウエアはどうなのか、ネットワークとは切り離して使うべきソフトウエアはどうなのか、などを考えると、外部からの脅威によって問題をひきおこしうるということが直ちに「欠陥」ということにはならないということはわかるかと思います。この点は、「3 脆弱性なしで出荷する法的義務は？」でもさらに考察します。

また「欠陥」という表現を使うことによって、(欠陥という表現がネガティブな響きを有していることから)脆弱性があるということが望ましくないものと認識され、その報告があっても、対応したくない(対応しない)、という態度につながりやすいように思われます。それは、望ましいものとはいえません。その意味で、「脆弱性」というのは、「欠陥」とは異なるということで、脆弱性という用語をメディアでも使ってもらいたいと思います。

ですが、「脆」という字が常用漢字にはいっていないので、メディアでは使いにくいというような話だそうです。

2.2 言い換えは？

なので、「ぜい弱性」という表現が広まるといいなあと思います。言い換えの表現を選ぶとなると、

弱点

あたりがニュートラルかなあ、という気がします。

「不備」ではどうか、という話しになると、「脆弱性」があることがあるべき性能を欠いているのか、という問題につきあたるような気がします。

3 脆弱性なしで出荷する法的義務は？

そもそも、プログラムの開発義に際して、納品時に脆弱性があったら、契約の趣旨に従った履行の提供といえるのか、という問題があります。

ブログでは、

脆弱性と債務不履行（東京地裁　平30.10.26）
脆弱性と瑕疵の間に（再考）
「契約不適合と保守契約と脆弱性」(契約不適合と保守契約の関係について検討)
ソフトウエア提供者の結果責任に関する判決群－In-Law「ユーザ・ベンダの責任分界と損害の範囲」セッション

などがあります。また、その他の議論では

などがあります。特に「ツボ【8】モデル契約におけるセキュリティ条項」でもふれられていますが、「モデル取引・契約書見直し検討部会民法改正対応モデル契約見直し検討WG ～情報システム・モデル取引・契約書～（受託開発（一部企画を含む）、保守運用）〈第二版〉」は、この点について詳細にふれているので確認したほうがよいように思えます。

(セキュリティ）
第50条　乙が納入する本件ソフトウェアのセキュリティ対策について、甲及び乙は、その具体的な機能、遵守方法、管理体制及び費用負担等を協議の上、ソフトウェア開発業務を開始する前までにセキュリティ仕様を確定させ、書面により定めるものとする。
2.　セキュリティ仕様に関する協議に際しては、甲は、乙に対し、本件ソフトウェアが稼働する環境の機器、ソフトウェア及びネットワークの構成等に関する情報その他セキュリティ仕様を確定するために必要な情報を適時に提供しなければならない。

(略)
4．　甲及び乙は、セキュリティ仕様の確定後から納入物の納入までに、本件ソフトウェアに関して、確定したセキュリティ仕様では対応できないセキュリティ上の脅威又は脆弱性（個別契約の目的を達することができないものに限る。）があることを知ったときは、遅滞なく相手方に書面により通知する。かかる通知書は、第37条第1項に定める変更提案書に該当するものとし、甲及び乙は、第37条第1項各号の事項に加え、セキュリティ上のリスクを検討し、セキュリティ仕様の変更の要否を決定する。
5.　乙は、納入物の検収がなされるまでの期間、本件ソフトウェアに関して、確定したセキュリティ仕様では対応できないセキュリティ上の脅威又は脆弱性（個別契約の目的を達することができないものに限る。）があることを知ったときは、甲に通知するものとする。なお、甲乙間において別途契約を締結しない限り、乙は、納入物のセキュリティ上の影響範囲の分析、納入物に対する対策の立案、実施等の義務を負わない。

(略)

7. 乙は、本件ソフトウェアに関して、確定したセキュリティ仕様では対応できないセキュリティ上の脅威又は脆弱性に関する情報を収集する義務を負わないものとし、乙の主任担当者又は業務従事者が個別契約の目的を達することができないような脅威又は脆弱性があることを知りながら（重大な過失によって知らなかったときを含む。）、甲に通知をしなかった場合を除き、本契約における義務違反を問われない。

同解説によると

重要インフラ・企業の基幹システムの一部を構成するシステムにおいては、ユーザ・ベンダの双方又はいずれか片方が求められるセキュリティ仕様についてクリアすべき基準が業種別のルールや社内規程により確立されておらず、開発プロジェクトを進める上での提案や合意についても手順が不明確な場合な場合が想定される。そのような場合には、セキュリティに関するリスクコミュニケーションを促すため、詳細な規定が必要となる。

とされているものです。

基本的な枠組としては、「セキュリティ仕様」の確定を前提に考えましょうということになります。そして、仕様確定後の脆弱性については、それが、

個別契約の目的を達することができないもの

であるかどうかが問題になります。これを逆からいうと、仮にあったとしても、セキュリティ仕様に反することがなく、個別契約の目的を達することができる脆弱性は、契約においては、契約不適合の責任を問われることはない、ということなります。要するに普通の用語法であれば、

欠陥

であったり、

不具合

であるとは認識されない

ということになります。

あと判決例との関係で言うと、

本件システム発注契約を締結した時点において、その当時の技術水準に沿ったセキュリティ対策を施したプログラムを提供することが黙示的に合意されていたと認められること、本件システムでは，顧客の個人情報を本件データベースに保存する設定となっていたことからすれば，被告は，当該個人情報の漏洩を防ぐために必要なセキュリティ対策を施したプログラムを提供すべき債務を負っていたと解すべきである

とした東京地裁判決平成26年1月23日判決が参考になるかと思います。

要するに開発契約の目的、当時の仕様のレベルその他などの総合的な見地から契約不適合が判断されるということになるかと思います。これを図示します。基本的には、上の脆弱性と瑕疵の間に（再考）の図になります。

セキュリティ仕様に反することがなく、個別契約の目的を達することができる脆弱性については、開発者が任意で対応する部分とあとは、仕様として、対応しようがない場合があって、それについては、契約による責任を問えないことを示しています。契約による責任を問いうる部分については、「欠陥」と呼ぶこともできなくはないですが、そうではない部分も存在すること、また、そもそも、問題が外部からの攻撃によって生じることから、欠陥とは、まったく異なった性格を有するということは理解してほしいと考えます。