私は個人的にMatasano blogの大ファンで、このグループに大きな敬意を払っている。私は米国時間6月28日に彼らのブログを覗いていて、Dave Goldsmithの「Web 2.0 Vulnerability Reporting Continued（Web 2.0界で脆弱性の報告の続き）」という記事に気付いた。
この記事の中で、Daveは彼の脆弱性報告を機能の要望と同じように扱った、酷いベンダーとのやりとりの個人的な経験を詳しく話している。ばかげた話のように聞こえるだろう。Daveとベンダーとのやりとりを見てみて欲しい。
ステップ1：私は脆弱性の報告を送った。私は脆弱性について電子メールで簡潔に説明し、再現のための手順も含めた。
彼らの返事はこうだ。
David、助言に感謝します。ご意見は伺いました。
私はそれに次のように返事をした。
そちらのセキュリティ上の脆弱性に対する対応のガイドラインについて教えてくれませんか。脆弱性の修正を行う期限の目安などはあるのでしょうか。
彼らの返事はこうだ。
David、われわれは常に将来のアップデートに対する新しい新しいアイデアや修正事項は歓迎していますが、ルールとして実現の可能性や時期にはコメントしないこととしています。
私は次のように返事をした。
私はどうやってこの脆弱性が修正されたことを知ることができるのですか。
彼らからの返事はなかった。
素晴らしいではないか。私自身、いくつかのベンダーを相手に同様の経験をしたことがある。これは、研究者には興味深い問題だ。
おそらく、読者の倫理感は次のように告げるはずだ（もし倫理観を持っていればの話だが）。
- 将来悪用されるだろう脆弱性について情報を公表したくない。
- 悪用されるだろうと分かっている脆弱性をそのままにしたくない。
ここに、難しい状況が生まれる。Daveは、彼の勧告が対象としていた企業（37signals）によるブログ記事について書いている。この記事では、機能の要望に対しノーという方法について議論している。37signalsのブログ記事には次のようにある。
- はっきりしたノー。その機能が製品の方向性と合致していない場合、方向性を変えることはせず、その旨を伝える。
- 柔らかいノー。その機能は将来追求するつもりのないものだが、そう断言したくはない場合、「アイデアに感謝する、将来のバージョンではその機能を検討する」と言う。
興味深い。Daveは37signalsのスタッフから柔らかいノーとはっきりしたノー（無視されるという形で）を受け取ったことになる。
これは問題だ。これは脆弱性を取り扱う場合に、許される方法ではない。私は企業はどうやって脆弱性を扱うべきかについて考えなくてはならない。問題はもちろん、私は実際にそういう権限を持つ立場にはなく、企業がどうすべきかと発言することしかできないということだが、幸い私の意見を尊重してくれる人たちもいる。私は個人的に過去に開発に関わったことがあり、ソフトウェア開発に欠陥という概念があるのも知っている。納品時のアプリケーションの数でボーナスを決めるということもできるだろう。これは機能ベースの欠陥についての話だが、脆弱性も欠陥だと見なすことはできないだろうか？
多くの企業は、セキュリティを事業目的の1つに挙げているが、もう一歩前に進んでいい時期だ。脆弱性を欠陥であると考えるのだ。プログラマーはこれをよく理解できるだろう。もちろん、ただ彼らにこれを任せることはできない。これは安全なコードの開発については学校でははっきりとは教えられていないからで（残念ながら現在でもそうだ）、どこかで彼らを訓練する必要がある。まず彼らにセキュリティ上の脆弱性について理解する時間を与える。そして、会社の方向性を定める、安全なSDLCの手順を作成するのだ。
進歩主義でいくべきだ。単に開発者に欠陥（脆弱性）についてくどくどと話すだけでなく、セキュリティホールが生じなかった時間が延びたり、セキュリティ査定で問題が見つからなかったりした場合には報償を与えてはどうだろう。
これはまだ個人的なアイデアだが、何かを変えていく必要がある。
この記事は海外CNET Networks発のニュースをシーネットネットワークスジャパン編集部が日本向けに編集したものです。海外CNET Networksの記事へ
