« 「ハードウエア・ファースト」の企業の実績と自信:日経ITProの記事より | トップページ | ソフトウエアエンジニアリングの知識体系SWEBOKの改訂の概要:日経ITProの記事より »

2014年7月15日 (火)

開発完了後にコードを見ることはない:オープンソースといえども

 オープンソースソフトウエアが意外と安全ではない理由(上) - オープンソースソフトウエアが意外と安全ではない理...:CIO Magazineという記事はオープンソー
スという開発方法に関する興味深い側面をついた記事である。少し引用する。

 十分な知識を持つ大勢のプログラマーがコードを精査し、バグを洗い出して迅速に修正できるかどうかにかかっている。これを簡潔に表したのが「Linusの法則」である。「目玉の数さえ十分あれば、どんなバグも深刻ではない」というものだ。

 では、Heartbleed問題では、どのようだったか。少し引用する。

 しかし残念なことに、このコードに入れておくべきチェック処理を抜かしてしまった。特定の変数に正しい値が入っているかどうかのチェックだ。さらには、このアップデートのリリース前にOpenSSL開発チームのあるメンバーがコードを検証した時にも、この変数のチェックがないことを見逃してしまった。こうして生じたのがHeartbleedのバグだ。
 1人のレビュー、あるいは数人のレビューでも、発見すべきバグがあると認識していなければ、こうしたささいなミスを簡単に見逃してしまう。

 この記事を読む限り「Linusの法則」が成り立たなかったように書いている。しかし本当にそうなのだろうか?
 あるコードに「機能的な」バグがあったとする。その場合、たぶん「Linusの法則」は成り立つのではないか?今回のHeartbleed問題は、「セキュリティ上の」バグであったということがポイントであろう。
 つまり、「Linusの法則」はバグの種類によって、成り立つ場合と成り立たない場合があるのだ。
 私自身の経験から考えても、「機能的に」動いたソフトのコードを後で見ることはない。つまり「機能的に」動くようにするということが開発だとしたら開発完了後は誰もソースを見ないのだ。目玉の数は開発完了後には0になるのである。動いた後でも、セキュリティの脆弱性に関する目玉があればいいのだが、そんなことは期待できないということだろう。
 一方、悪用する側での目玉は、開発の目玉がなくなってからひっそりと動き出す。つまり、オープンソースの開発方法は、「機能」開発では非常に素晴らしい方法だったが、ことセキュリティの脆弱性に関しては、オープンであることがかえって危険性を増すことになるのかもしれない。

« 「ハードウエア・ファースト」の企業の実績と自信:日経ITProの記事より | トップページ | ソフトウエアエンジニアリングの知識体系SWEBOKの改訂の概要:日経ITProの記事より »

パソコン・インターネット」カテゴリの記事

技術」カテゴリの記事

開発業務」カテゴリの記事

コメント

コメントを書く

(ウェブ上には掲載しません)

トラックバック

この記事のトラックバックURL:
http://app.cocolog-nifty.com/t/trackback/568535/59985205

この記事へのトラックバック一覧です: 開発完了後にコードを見ることはない:オープンソースといえども:

« 「ハードウエア・ファースト」の企業の実績と自信:日経ITProの記事より | トップページ | ソフトウエアエンジニアリングの知識体系SWEBOKの改訂の概要:日経ITProの記事より »

2017年8月
    1 2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30 31    

公告

  • Google Adsense
無料ブログはココログ