ディレクトリ チャンネル vol.38
そこで重要になるのが「開発の各工程における脆弱性予防」（長谷川氏）だ。脆弱性に対する認識が低かったころは、機能テストや負荷テストばかりで、セキュリティテストは一切行われずに運用がスタートされることが多かった。Webアプリケーションの脆弱性を突いた大規模な情報漏えいが頻発したのには、そうした背景も一因となったのだろう。対策の必要性が認識され始めてからは、出荷前検査としてセキュリティテストを行うケースが見られるようになってきた。が、これだけではもう不十分だと同氏は語る。 「開発工程には、要件定義から基本設計・機構設計、詳細設計・単体テスト、システム統合・組み合わせテストなどのフェーズが存在する。脆弱性は上流の要件定義から種がまかれ、フェーズごとに成長していくもの。出荷前の段階では大量の脆弱性が発生しており、ここで検査を行ってもコスト的に、優先度の高いものだけをつぶすにとどまる可能性があるのだ。なので今後は出荷前検査だけでなく、開発工程の要所要所で開発者自身が検査してコード修正するほか、要件定義の段階からも、必要なことが抜けていないかなどセキュリティに配慮していくのが望ましい。もちろん、それでも完全に脆弱性をつぶすのは至難の業だが、出荷前検査だけよりも、リスクを大きく減らし、かつコストも抑えることができる」（同氏）。 また実装においては、「先に紹介したような予防的実装のほか、フレームワークを利用するのも有効。用意されたスタイルに沿って開発することで、品質のムラや機能漏れを防ぎ、プログラマは個々のアプリケーションの仕様に専念できるはず。フレームワークにも脆弱性対策が十分に備わっているとは限らないが、フレームワークレベルで対策を施せれば、個々のプログラムに対策を記述せずに済む」（同氏）とのこと。 一方、脆弱性検査も「もはや不可欠な存在」として推奨する。検査方法には、自動検査ツールを用いたブラックボックス検査、手動によるブラックボックス検査、ソースコード検査などバリエーションがあるが、「検査ツールは手間が少なく網羅的に検査が行える。反面、主にセッション問題やアクセス制御問題の検出は苦手な面もある（最近は機能的に克服されつつもあるが）。これに比べて手動検査は人間の価値判断でより深い検査が行えるが、そもそもブラックボックス検査自体にどうしても限界がある。一方、ソースコード検査は脆弱性のあるロジック部分を明確に見つけることができるが、多くの時間がかかるのがデメリット。どれにも一長一短があるので、バランスよく組み合わせるのが理想だ」（同氏）とした。