教訓はなぜ生かされなかったのか．
http://itpro.nikkeibp.co.jp/article/OPINION/20060206/228646/
答：馬の耳に念仏．
ワコールからの督促があったにもかかわらず，SQLインジェクションを防止することができなかったのだろうか。
古典的なバグだが，それだけに完全に防ぐのは簡単ではない．特に現場の技術力が低くなるとスパゲティプログラムが量産され，防ぐのが事実上不可能になる．今回の一件もそんなとこじゃなかろうか．
あとは使っているプラットフォームだな．
たとえばプログラミングのイロハも知らない素人が，以下のような本を参考にPHPで書けば穴だらけのサイトになるのは当然だろう．*1
http://takagi-hiromitsu.jp/diary/20060202.html#p01
- 作者: WINGSプロジェクト,山田祥寛
- 出版社/メーカー: インプレス
- 発売日: 2004/09/22
- メディア: 単行本
- 購入: 22人 クリック: 470回
- この商品を含むブログ (26件) を見る
「開発した2000年8月当時，SQLインジェクションは広く知られた脅威ではなかった。
私がSQL初心者だった頃，ちょっと弄くって遊んでただけでそのリスクは理解できたぞ．SQLインジェクションという呼び名を知る前の話です．SQLの文法を読めば初心者にだって分かる簡単なトリックに過ぎません．
建物に例えるなら，建築当時はあまり知られていなかったサムターン回しという手口による侵入が頻発するようになったようなもの。日々新しいセキュリティ・ホールが発見されている。あらゆるケースをすべて網羅して穴をふさぐことはできない」（NECネクサソリューションズ 多田氏）。
ある意味で間違いではないが，だからこそリスク面も考慮してプラットフォームを選定したり，穴が避けられないのであれば，その部分を人間の警備員が巡回するなどしてカバーするのである．いずれにせよ，こそ泥に入られたら警備会社としては言い逃れはできない．
ベンダー選定および時に，セキュリティ対策をどう取るのかについても提案を依頼し，選定の用件とするとともに契約にも織り込む必要がある。
無駄だって．
技術があれば言われなくったって対処する．それがプロの技術者だ．
技術が無ければいくら言われたって対処できない．それが一山いくらの技術者モドキだ．
コスト削減の名の下に一山いくらで発注してきて，今になって「品質第一」と言われても対処できるわけがない．
ベンダーによっては，開発が終了したシステムについて，なるべく手をかけないようにしようとする傾向があることも知っておく必要がある。
「手をかけない」というわけではなく，「手をかけずに済むように最初から品質を作り込んでおく」だけです．
かつての社内システムであれば，稼動後にコストをできるだけかけないようにすることは合理的な行動だったのであろう。
それは今でも同じだ．
今回のようなトラブルは手離れの良いシステムでは稼働後はたまにセキュリティパッチをあてる程度で済むが，手離れの悪いシステムでは手の施しようが無くなる．*2
日々価値を生み出すプロセスである。変化への対応を織り込んだ，サービスとしての利用が最も適切な契約形態だろう。
いわゆるXPなどのアジャイル開発は正にコレである．それが次世代の開発スタイルだというのも同感だが，それはSQLインジェクションの話とは，ほとんどなんの関係もない．
なんだか，この記事はXPやアジャイルを少し囓った記者が，SQLインジェクションと無理矢理こじつけたように見える．
