ツボ【8】モデル契約におけるセキュリティ条項
2020年12月，モデル契約第2版公表
ソフトウェア開発のモデル契約書として広く知られた「経産省モデル契約」は，2007年に「第1版」がリリースされました。その後，IPA（独立行政法人情報処理推進機構）のもとで，2019年12月に民法改正対応版がリリースされました。さらにその後，民法改正と直接関わりのない論点についての検討を経て2020年12月に「第2版」がリリースされました。
私は，モデル取引・契約書見直し検討部会（いわゆる親会）のもとに設置された「民法改正対応モデル契約見直し検討WG」の委員会メンバーとして民法改正版と第2版の作成に関わりました。このnoteでは，第2版で大きく変わった条項のうち，「セキュリティ」に関する条項について簡単に説明をします。モデル契約を改訂する過程では，さまざまな論点について検討がなされたものの，実際に（民法改正の影響を受ける部分以外で）条項が修正された箇所は少なく，解説部分の補充にとどまったところがほとんどでした。大きく変わった箇所としては，「セキュリティ」と「プロジェクトマネジメント義務／協力義務」の部分でしょう（後者は本稿の対象外ですが，いつか書きたいと思います。）。
なお，本稿は，2021年3月10日にEGセキュアソリューションズの徳丸浩先生のセミナーに読んでいただいて，その準備をする過程でまとめたものです。このnoteの内容はセミナーでもお話する予定ですが，ご関心のある方は，下記リンクからお申し込みください。
https://www.eg-secure.co.jp/seminar/operatingrisk/
セキュリティ条項の契約上の位置づけ
ソフトウェア開発委託契約で，独立してセキュリティに関する条項を設けることは決して多くないと思われます。というのも，開発委託契約がカバーするのは，ソフトウェアの完成までであることが通常で，セキュリティに関する事項といえば，セキュリティの仕様をどう決めるか，ということにとどまるでしょう。汎用的に使われる契約書にセキュリティに関する事項を記載するとしても何を書いてよいかよくわからないの実態です。
しかし，そのソフトウェアの脆弱性を突いたインシデントが起きたという場合，開発したベンダーの責任が問われる可能性があります。また，セキュリティインシデントの場合には，通常のバグ以上に，影響も大きくなりがちです。よって，セキュリティ仕様を決めたり，それにそって実装することが重要なのはいうまでもありませんが，契約書は基本は債権債務を定めるものなので，セキュリティに関する債権債務といわれてもピンときにくいところです。実際に，第1版では下記のように見出しを除くと1ツイートに満たない81文字の簡単な条項が置かれるにとどまっていました。
第50条【セキュリティ】
乙が納入する本件ソフトウェアのセキュリティ対策について、甲及び乙は、その具体的な機能、遵守方法、管理体制及び費用負担等を協 議の上、別途書面により定めるものとする。
しかし，第2版になると，約16倍の1310文字の詳細な規定になりました（オプション条項含みます。また，A案，B案が併記されていますが，これはA案の文字数です。）。
セキュリティ仕様の曖昧さによる問題
あくまでセキュリティはソフトウェアの仕様の一つに過ぎないものの，機能仕様（ボタンを押したら・・するといった仕様）と違って，非機能仕様であるセキュリティについては仕様書の作成だったり，確認・合意プロセスがおろそかになることが少なくありません。その原因として，モデル契約と同時に公開された「セキュリティ仕様策定プロセス」（上記IPAのリンク先にあり）8頁では，ユーザーの課題として次のようなことを挙げています。要は丸投げしているケースが多いのです。
多くのシステム開発契約でセキュリティ仕様の合意がなされていない原因として、ユーザー側には「ITベンダーを信頼している」、「そのための時間を買っている」、「複雑でよくわからない」、「サイバー攻撃とは無関係」といった考えが散見される。
しかし，明確な仕様の合意がないまま「ベンダーがしっかりやっているだろう」と思って事故が起きた場合はどうなるでしょうか。この点が問題となった裁判例として有名なのがいわゆるSQLインジェクション事件（東京地判平26.1.23判時2221号71頁）です。
詳細は上記リンク先の拙ブログをご覧いただくとして，本件では，SQLインジェクション攻撃によって顧客のクレジットカード情報が漏えいしたサイト運営者が，サイト開発者に損害賠償を求めたという事案で，SQLインジェクション対策を講じることが（仕様書には記載がないが）ベンダーの契約上の義務であるかどうかが争われました。
裁判所は，「その当時の技術水準に沿ったセキュリティ対策を施したプログラムを提供することが黙示的に合意されていた」と述べ，その当時（2009年）時点においてすでにSQLインジェクションの脅威とその対策が知られており，経産省などから注意喚起もなされていたことから，これを講じていないことが債務不履行（しかも，責任限定条項が適用されない重過失）に該当すると判断しました。
確かに，裁判所は本件事案の解決のために「技術水準に沿ったプログラムを提供せよ」と述べましたが，技術水準といわれても，ソフトウェアの性質，金額などによって区々であり，一概に決められるものではありません。事後的にセキュリティ対策が「黙示的に合意」されていたとして，その内容を第三者に判断されてしまうのは，ユーザー・ベンダー双方にとって予測可能性を害することになるため，セキュリティ仕様を明確に合意しておくことは双方にとってメリットのあることなのです。
このように，セキュリティ仕様は実務的に曖昧に取り残されがちで，事故が起きたときには深刻な影響が生じやすいことから，第2版の策定にあたっては，セキュリティに関する条項や，仕様策定プロセスを見直すこととなりました。また，見直しにあたっては，技術的事項を含むことから，検討WGのもとにさらに「セキュリティ検討PT」を設けて検討が行われました。
セキュリティ検討PTの成果物は充実しており，「セキュリティ仕様策定プロセス」のほか，実際のガイドラインの例として「情報システム開発契約のセキュリティ仕様作成のためのガイドライン～Windows Active Directory編～」が公開されています。
セキュリティ条項の概要
大幅に拡充されたセキュリティ条項（モデル契約50条）は，前述のセキュリティ仕様策定プロセスに沿って行われることが想定されています。具体的には，外部設計工程にてセキュリティ仕様を書面で定めること（1項），その際にはユーザーが仕様確定のために必要な情報を提供すること（2項）などを定めています（条項は長いので，末尾に引用しておきます。）。
上記の図からは読み取りにくいかもしれませんが，セキュリティ仕様を策定するにあたっては，公表された基準（図の右側）を参照しつつ，それを雛形・チェックシートのように使って，実装するもの，しないものをユーザー・ベンダーで協議して，セキュリティ仕様書（図の左側）に落とし込みましょう，とされています。
実装することが推奨される「デフォルト緩和策」については，実装しないとする場合には，連絡協議会の議事録に記載することを定める条項も提案されています（50条のオプション条項。以下参照）。
（50条オプション条項第2文）その際、甲が当該ガイドラインに示された対策の一部を講じない判断をしたときは、その判断（対策を講じないことにより軽微とはいえない影響が生じることが予測できる場合には、その影響を含む。）について、第21条（外部設計検討会）所定の連絡協議会において確認したうえ、第12条第6項の議事録に記載するものとする。
もっとも，ソフトウェアの開発は，長期に渡って行われることが多く，仕様が確定した後，ソフトウェアの運用が開始するまでの間に，構成するシステムの中で新たな脅威が見つかったりすることがあります。その場合，ユーザーとしては，当然そのような対策も積極的に提案して仕様に織り込んでもられるものと期待したくなりますが，ベンダーとしては境界のはっきりしない責任を負うことになりかねません。そこで，ベンダーは，当然にはその種の脅威に対応することまでは求められないものの，脅威を知ったときは，ユーザーにその旨を通知して必要に応じて変更管理手続に乗せることなども定めています（4項）。
（50条4項第1文）甲及び乙は、セキュリティ仕様の確定後から納入物の納入までに、本件ソフトウェアに関して、確定したセキュリティ仕様では対応できないセキュリティ上の脅威又は脆弱性（個別契約の目的を達することができないものに限る。）があることを知ったときは、遅滞なく相手方に書面により通知する。
セキュリティ仕様では対応できないインシデントの責任
ベンダーは，こうしてプロセスに沿って確定した仕様どおりのソフトウェアを提供しなければなりません。定められた仕様どおりに開発・設定されていなければ，契約不適合責任を負うことになります。
他方で，インシデントが生じないことを保証するものではないことは当然です（6項）。特に，仕様策定当時に知られていなかった脅威についての対策まで求められることはなく，そういった対策がとられていなかった場合に開発委託契約の契約不適合責任を負うことはありません（これはあくまで開発委託契約の場合であり，継続的にサービスを提供するSaaS利用契約等の場合は話は異なるでしょう。）。ソフトウェアの提供を受けた後に継続した対策を求める場合には，保守契約等の別の契約を締結することになるでしょう。
また，仕様が確定した後（納品までの間）に，積極的に新たに生じた脆弱性に対する情報提供の義務までもは負わないものの，重大な過失によって知らない場合にはその責任を問われ得ることとしています（7項）。つまり，容易に知ることができる脅威が明らかになったというような場合（例えば，前掲SQLインジェクション事件にあったようなSQLインジェクション対策等）については，知らなかったことによって免責されるとは限らないでしょう。
〔参考〕モデル契約 50条（セキュリティ）
以下は，モデル契約の50条（A案）を抜き出したものです。冒頭のIPAへのリンクには，詳細な解説もついていますので，参考にされるとよいでしょう。
第50条【セキュリティ】 （注）〔〕内はオプション条項
1. 乙が納入する本件ソフトウェアのセキュリティ対策について、甲及び乙は、その具体的な機能、遵守方法、管理体制及び費用負担等を協議の上、ソフトウェア開発業務を開始する前までにセキュリティ仕様を確定させ、書面により定めるものとする。
2. セキュリティ仕様に関する協議に際しては、甲は、乙に対し、本件ソフトウェアが稼働する環境の機器、ソフトウェア及びネットワークの構成等に関する情報その他セキュリティ仕様を確定するために必要な情報を適時に提供しなければならない。
○. 〔甲及び乙は、セキュリティ仕様の作成のために参照するガイドラインについて合意した場合、ガイドラインの名称、バージョン及び当該ガイドラインを参照して本件ソフトウェアに適用すべき事項をセキュリティ仕様に盛り込み、第22条（外部設計書の確定）所定の手続により確定するものとする。その際、甲が当該ガイドラインに示された対策の一部を講じない判断をしたときは、その判断（対策を講じないことにより軽微とはいえない影響が生じることが予測できる場合には、その影響を含む。）について、第21条（外部設計検討会）所定の連絡協議会において確認したうえ、第12条第6項の議事録に記載するものとする。〕
3． 確定したセキュリティ仕様は、システム仕様書の一部を構成するものとし、その変更が必要となった場合は、第37条（変更管理手続）によってのみこれを行うことができるものとする。
4． 甲及び乙は、セキュリティ仕様の確定後から納入物の納入までに、本件ソフトウェアに関して、確定したセキュリティ仕様では対応できないセキュリティ上の脅威又は脆弱性（個別契約の目的を達することができないものに限る。）があることを知ったときは、遅滞なく相手方に書面により通知する。かかる通知書は、第37条第1項に定める変更提案書に該当するものとし、甲及び乙は、第37条第1項各号の事項に加え、セキュリティ上のリスクを検討し、セキュリティ仕様の変更の要否を決定する。
5. 乙は、納入物の検収がなされるまでの期間、本件ソフトウェアに関して、確定したセキュリティ仕様では対応できないセキュリティ上の脅威又は脆弱性（個別契約の目的を達することができないものに限る。）があることを知ったときは、甲に通知するものとする。なお、甲乙間において別途契約を締結しない限り、乙は、納入物のセキュリティ上の影響範囲の分析、納入物に対する対策の立案、実施等の義務を負わない。
6. 乙は、甲に対し、システム仕様書に記載されたセキュリティ仕様に従って本件ソフトウェアのセキュリティ対策を講じる義務を負うにとどまり、本件ソフトウェアに関してセキュリティインシデントが生じないことを保証するものではない。
7. 乙は、本件ソフトウェアに関して、確定したセキュリティ仕様では対応できないセキュリティ上の脅威又は脆弱性に関する情報を収集する義務を負わないものとし、乙の主任担当者又は業務従事者が個別契約の目的を達することができないような脅威又は脆弱性があることを知りながら（重大な過失によって知らなかったときを含む。）、甲に通知をしなかった場合を除き、本契約における義務違反を問われない。
この記事が気に入ったらサポートをしてみませんか？