目先の脆弱性（バグ）の修正に追われるのはもう十分？　Black Hatで見た根本的な問題解決のアプローチ：セキュリティ・アディッショナルタイム（24）（3/4 ページ）

セキュアな開発は大企業だけのものじゃない

　もう一つ例を紹介しよう。SAFECodeのエグゼクティブディレクター、Steven B. Liner氏は、かつてMicrosoftで「セキュア開発ライフサイクル」（SDL）を率いてきた人物だ。Liner氏によると、Microsoftが真剣にSDLに取り組み始めたきっかけは、「CodeRed」「Nimda」といったワームの登場だった。インターネット全体に大きなインパクトを及ぼしたことが、それまでセキュリティに前向きとはいえなかったSAFECodeの背中を押し、静的解析をはじめとするセキュリティ検査やプロセスの改善につながったという。

　では、それほど顧客のプレッシャーにさらされることがなく、予算やリソースも少なければ経営層の理解も薄い中小企業の場合は、どうすればSDLを推進できるだろうか？　Liner氏は「SDL That Won't Break the Bank」と題するセッションでそのヒントを紹介した。

「予算や人手がなくてもセキュア開発ライフサイクルは実践できる」と説明したSteven B. Liner氏

　「大事なのは開発者がコードを書くだけではなく、それをセキュアにする責任も担うことだ。一方セキュリティチームの役割は、ツールやトレーニングを提供し、時に相談に乗って、開発者を支援することだ。開発者が『セキュリティは誰かにやらせればいいや』という姿勢を取っていても、またセキュリティ担当者がリリース前の最後の段階になって『これは基準を満たしていないからだめです』と立ちはだかるやり方でも、幸せにはなれない」（Liner氏）

　その上でLiner氏は、「どんな形でセキュアな開発ライフサイクルを実現すべきか」を幾つかのステップに分けて紹介した。

　最初のステップは、意外なようだが「脆弱性対応プロセスを整える」ことだ。「脆弱性は、SDLを定義する上で鍵となるインプットであり、外部からの受付窓口も含めたプロセス整備がSDLの第一歩になる」とLiner氏は言う。そして、下記の順で進めていくべきだとした。

• バグの追跡を行うセキュリティワークフローを整備する
• 深刻度を評価し、優先順位付けを行う
• サードパーティー製のコードもセキュアかどうかを評価する

　なおこの際、必ずしも高価な商用製品を導入する必要はない。簡単なものを活用していけばよく、「フリーで提供されているものを活用してもいい」（Liner氏）。こうした準備ができて初めて、セキュアな設計、セキュアなコーディングへと進み、攻撃にさらされる側面を減らしていくべきだという。

　「ただ、SDLに飲み込まれてしまっていけない。全部をやろうとするのもいいが、現実には難しい。優先順位を付け、大事なところから進めていくべきだ。無理せず、できるところから手を付けていくのも成功のコツだ」（Liner氏）

　こうして徐々に開発プロセスにセキュリティを統合していった後に、プロセス全体を検証して、必要に応じて脅威モデルやデザインに修正を加えていくことをLiner氏は推奨した。また「バグバウンティプログラム」も、レスポンスプロセスやSDLを補完し、改善する役に立つという。

　Liner氏は最後に、Tabriz氏の基調講演と同じように「根本的な原因に取り組み、解決していくことが大切だ」と述べた。このように書いてみると、BlackBerryの取り組みもLiner氏の話もごくごく「当たり前」のことだが、その当たり前を実践するのがいかに重要かを認識させられる。