真の顧客はだれ？

SQLインジェクション対策もれの責任を開発会社に問う判決 | 徳丸浩の日記

なんとも微妙な話である。

また、SQLインジェクション脆弱性が（要求仕様に明記されていないにもかからわず）受注者の重過失であると認定した点にも注目する必要があります。今後は、開発会社は自衛のため、せめて「安全なウェブサイトの作り方」に載っている脆弱性くらいは、顧客から要求がなくても、対策しておくべきでしょう。
発注者の立場に話を戻すと、今回紹介したような判例があったとしても、脆弱性対策を発注仕様に盛り込むべきです。そもそも脆弱性がなく、侵入もされないことが望ましいことは言うまでもないからです。
また、原告は、20万円の追加対策を指示しなかったことを過失と認定され、過失相殺として損害賠償金額を3割減額されました。20万円ケチったために、1,000万円近く損したことになります。

SQLインジェクション対策もれの責任を開発会社に問う判決より

ちなみに「安全なウェブサイトの作り方」というのは IPA のこれのこと。

安全なウェブサイトの作り方：IPA 独立行政法人情報処理推進機構

私はこの判決は受注者（開発会社）側に厳しすぎるのではないかと思う（せめて両成敗で5割引き）。が，そういう判決が出たのであれば致し方ない。私たちエンジニアは自衛する必要がある。

前提条件。

今回のケースはある製品に対して発注者と受注者が存在する（内製品，自社製品ではないということ。もちろん FOSS でもない）。私たちエンジニア（開発者）から見れば発注者とはすなわち「顧客」である（これは「最終顧客」とは異なる）。そして，開発途中の「試作品（prototype）」ではなく「製品」を納入している。

製品であれば一定の「品質」が求められる。求められる品質がどのようなものであるかは **最終的には** 顧客が決定する。これは重要なポイントである。

随分昔にこんなことを書いた。

ソフトウェアにおける「開発」と「製造」は何が違うのでしょうか。品質という観点で考えると，あるはっきりとした違いがあることが分かります。それは，製造によってアウトプットされたソフトウェアは顧客の要求を過不足なく満たしていることを保証している，ということです。これには二つの意味があります。ひとつは「顧客の要求」が製造可能なレベルまで具体化されていることで，もうひとつは具体化された「顧客の要求」からの逸脱（Deviation）がないことです。
「逸脱がない」ことは「バグがない」こととは違います。ソフトウェアの性質上「バグがない」プログラムを作ることは（それが大規模であればあるほど）至難の業です。しかし「逸脱がない」プログラムを作ることは「バグがない」プログラムを作るよりもはるかに楽です。何故なら「逸脱がない」プログラムを目指すことでエンジニアの責任範囲が有限になるからです。顧客は「要求」に対して責任を持ち，作り手であるエンジニアたちは要求に対して「逸脱がない」ことで自らの責任を果たします。責任を分担しているわけです。

コーディング規約の勘所 -- 戯れ言++より

顧客が作りたい製品にどんなセキュリティ・リスクがあるか知りうるのは開発者である。でも開発者は顧客の作りたいものが「どんな製品なのか」「誰がどうやって使うのか」分かっていないとセキュリティ・リスクを評価できない。どちらか一方に責任を押し付けては成り立たないのだ。

まず開発者側。

（既にやっているところには言わずもがなだが）

小さい会社でも必ずセキュリティ・リスク評価ができる（できれば専任）者を置くこと。評価者はセキュリティの専門家でなくてもいいが，得意分野においてセキュリティ・リスクを見積もれる程度の知識と（できれば）経験が必要。テスト工程での評価であれば「結果（evidence）」も提示する必要がある。

更に，セキュリティ事例（脆弱性情報やセキュリティ事故例）を社内で共有する体制を作ること。大きい開発企業には当然セキュリティ・セクションがあるが，個々の従業員はそのセクションに頼りっぱなしで「セキュリティ？専門家が決めることでしょ」みたいなところも多い。少なくとも IPA や JPCERT/CC のセキュリティ関連のアナウンスは全社レベルで共有すべきだし，メディアが報道するような大きなセキュリティ事故についても共有できていればリスク感覚を磨く訓練に使える。

開発者は「顧客にはセキュリティ評価はできない」という前提で取り組む（実際にはできるとしても「できない」ものとして取り組む）べき。たとえば，今回のケースで考えるなら，相手が「管理者パスワードを初期の admin/password から変更しなければならない」という知識がない前提で導入マニュアルを作る，といったことである。

次に顧客側。

（これまた既にやっているところには言わずもがなで申し訳ないが）

製造プロセスに対し，必ず「セキュリティ・リスク評価」の評価者を置くこと。昔と違い，もはや「セキュリティ・リスク評価」をしない（できない）開発者は論外。「セキュリティ・リスク評価」の評価者は個別のセキュリティ知識は必ずしも要らないが，少なくとも評価の観点を押さえられる人であること。かつ，開発者側にも顧客側にも意見が通る人でないと難しい（会社でいえば中間管理職クラス）。

もうひとつ。これが一番大事なのだが，顧客は開発者の製造プロセスに積極的に関与すること（関与するコストを惜しんではいけない）。顧客が「ソフトウェアの中身は分からないから」とか言って丸投げするプロジェクトは大抵失敗する。

今回のケースは顧客が開発者に対し業務委託契約を結んでいたらしいが，この「業務委託」ってやつが曲者で，これを勘違いする顧客が何も考えずに開発者に丸投げするケースは多い。

開発や製造プロセスは人を育てる（中には人を壊すプロジェクトもあるけどね）。ワンオフの製品ならば顧客も一緒に「成長」すべき。

真の顧客はだれ？

開発者は顧客の「思い（design）」を知らないし，顧客は「思い」を表す「言葉（code）」を持たない。欠けてる者同士が補い合っていかなければものは作れない。暗黙的に「相手は分かっているだろう」などと思わないことである。お互いのバックグラウンドが違うんだから分からなくて当たり前なのだ。

「顧客の言葉と技術者の言葉は違う」 -- 戯れ言++ （これまた10年以上前に書いた記事）

（ついでに言うと，仕事上のコミュニケーションに「空気が読める」ことは不要。というか「空気が読める」ことは邪魔になることが多い。「空気が読める」人は相手に「分かっているだろう」と誤解される恐れがあるからだ（そして実際に分かっていない）。「空気が読める」ことと「信頼を託せる」ことと「相手が好みかどうか」はそれぞれベクトルが異なる）

今回の SQL インジェクションのようなケースは特にそうだが，セキュリティ要件は設計段階から全体最適で組み込んでいかないと，あとから気づいて組み入れようとしても結構な手戻りになることが多い。なので「セキュリティ・リスク評価」の評価者は，製造プロセスの要件定義・設計・製造・検査・導入すべての工程で開発者に「セキュリティ・リスク評価」を行わせ，その評価をするべきである。早く気付けば時間のロスもお金のロスも少なくて済む（開発者を切り捨てる判断も含めてね）。

製品の真の顧客は「最終顧客」であることを双方が忘れず，常に「未然防止」に気を配っていけば，今回のような問題はほぼ回避できる。