■
そのださんのはてなから。
というか、セキュリティ機能はすでにライブラリとして組み込まれていて、例えばユーザー入力を受け取るところでは受け取り関数をコールするだけなんだけど、その関数の中ではサニタイジング処理などなどが行われているようになってないと、余計な（といってはイカンけど）工数はかかるし、開発予算を増やしてもらわないとならんし、ってことはつまり、対策できない、ということなので（苦笑）。新しい攻撃手法が開発されたら、セキュリティライブラリを再度リンクするとかすると対策が組み込まれるとか、そういう仕組みになっとると開発ラクチンだと思うんだけどなあ。
おそらくそのとおりで、.NET Frameworkってのは、まさにそのセキュリティ機能をプロパティの形で実装していたりします。とはいえ、ライブラリそのものがセキュアに（まだ完全に）倒れていないから、たとえばプロパティの設定を忘れると非セキュアなアプリケーションができちゃったりするのがイタイところではありますが。
つか、マジな話、世の大半の開発者は“必ず（仕様書の）意図したとおりに動作するもの”の開発が至上命令であり、それはどんな手段を使っても（トリッキーなプログラミングや一部レガシーな手法の使用とか）実現しなければならないわけで。
ところが一方で、セキュアにするためのプログラミング方法はもとよりメンテナンスしやすいモジュール化されたプログラミングや、見通しのよいプログラミングといった、いわゆる基礎体力が欠如した“なんちゃって開発者”は増える一方*1。祐記さんのところで話に出た（http://d.hatena.ne.jp/K2Da/20031021#p1）ような、いわゆるリーマンプログラマですね。この層が厚いかぎり、今の開発環境のままでは結果的にバグやホールが混入しやすいアプリケーションが生まれてしまうのは避けられない。
でも、リーマンプログラマがIT産業*2を下支えしているのが現状なのだから、それじゃライブラリをセキュアにしましょうというのは、世の趨勢というものなんじゃないかと。
この項、ちょこちょこ推敲します。
