発注時のセキュリティコンサルティング

Webアプリケーションのセキュリティは発注者の責任? 開発会社の責任?

Webアプリケーションの開発を他社に委託する場合、「専門家に高い費用を払って開発してもらうのだから、当然セキュリティのこともきちんとしてくれるべきだ」とお考えではないでしょうか。無理もない感覚だと思いますが、現実には、脆弱性の責任は発注者にあるというのが通説です。

その証拠を示しましょう。経産省が産業界と取りまとめた「情報システム・モデル取引・契約書（受託開発（一部企画を含む）、保守運用）＜第一版＞」（以下、モデル契約書と略記）P82には、以下のような記述があります。

なお、本件ソフトウェアに関するセキュリティ対策については、具体的な機能、遵守方法、管理体制及び費用負担等を別途書面により定めることとしている（第50 条参照）。セキュリティ要件をシステム仕様としている場合には、「システム仕様書との不一致」に該当し、本条の「瑕疵」に含まれる。

セキュリティに関する仕様を書面として定義しない限り、瑕疵にはあたらないと書かれています。さらに、「第50条」を読むと、以下のように書かれています（モデル契約書P103から引用）。

（セキュリティ）
第50 条 乙が納入する本件ソフトウェアのセキュリティ対策について、甲及び乙は、その具体的な機能、遵守方法、管理体制及び費用負担等を協議の上、別途書面により定めるものとする。

こちらは契約書の記述となるわけですが、やはり具体的な機能や遵守方法を書面（仕様書）により定めるとしています。受託開発の場合、仕様は発注者が示すものですから、セキュリティ仕様を発注者が示さない状態で脆弱性が混入した場合、責任は発注者に生じることになります。

RFPでWebサイトの安全性は7割決まる

発注仕様が脆弱性対策上重要であることを説明しましたが、その発注仕様はどの段階で示すべきでしょうか。答えは、RFP（Request For Proposal; 提案依頼書）です。RFPよりも後の段階では、既に見積もりを元にベンダー選定が終わっているため、後からセキュリティ仕様を出したのでは見積もり金額が変わってしまいます。ベンダー選定後の追加見積もりでは、コストに対する厳しい要求も通りにくいのです。

セキュリティ施策も含めたコストでコンペを実施することにより、トータル費用を削減することが賢明でしょう。

残り3割は検収で決まる

Webサイトの安全性の7割がRFPで決まるとして、残り3割は何で決まるでしょうか。答えは検収です。まだ、セキュリティ要件を検収時にチェックすることは、一部の企業などでは実施しているものの、まだ一般的ではありません。その理由は、セキュリティの検収に費用や技術が必要になるからです。しかし、検収時にセキュリティ要件をチェックしないということは、開発会社におまかせということであり、発注者としての責任を果たしているとは言えません。

RFPのセキュリティ要件が「難しい」理由

RFPに話を戻します。RFPにセキュリティ要件を書き込めばよいとはいえ、現実に書いてみると中々難しく、参考になる文書も見あたらないのが現状です。先述のモデル契約書も、仕様書に書けとは書いているものの、セキュリティ仕様の実際については曖昧な記述です。RFPのセキュリティ仕様記述が難しい理由として、以下が挙げられます。

参考のためPCI DSS（クレジットカード加盟店向けのセキュリティスタンダード）を見ても、さまざまなセキュリティ施策についての要求はあるものの、脆弱性対処についてはOWASPなどのベストプラクティスから引用した脆弱性名の列挙（6.5項）に過ぎず、検証に関する要求として、Webアプリケーションのレビュー（6.6項）や、Webアプリケーションのペネトレーションテスト（11.3.2項）で補う形になっています。検証についても具体的なレベルに関する記述はなく、専門家の知見に任せている状態です。

HASHコンサルティングが安全なWebサイトの発注をお手伝いします

上記のような課題に対して、すっきりした解決策はまだないというのが現状です。長期的には、発注者・受注者（開発会社）がともにセキュリティの知識を身につけることや、建築業界のように法的な整備が必要になるのではないかと弊社は考えます。HASHコンサルティングは、発注時のセキュリティコンサルティングという形で、安全なWebサイトの発注をお手伝いします。例えば、以下のような施策が可能です。

以下の参考資料（ブログ記事、講演資料）もご参照下さい。

費用はプロジェクトあたり30万円（税抜き）から。詳細はお問い合わせ下さい。