ソフトウェアのセキュリティ対策は開発プロセス上で行うべし：カットオーバー直前の監査は逆効果

ソフトウェア開発の各工程でセキュリティの検証および修正作業を徹底すれば、解析の価値と効果を高められる。

≫ 2008年12月22日 07時30分公開

[Wayne Ariola，TechTarget]

　セキュリティのためのコード監査には、1つ大きな問題がある。この監査によって解決される問題よりも、引き起こされる問題の方が多くなりがちなことだ。

　1回の監査調査ですべての問題を洗い出そうとすると、開発者を途方に暮れさせることになる。開発チームに、既知の問題がずらりと並んだリストを提供するだけで、実際の改善にはほとんどつながらないという結果になりやすい。

　実際、ソフトウェア開発ライフサイクル（SDLC）の終わり近くに監査ツールを使い、潜在的な問題が大量に検出されると、プロジェクトマネジャーは、そのコードを修正するためにプロジェクトを遅らせるか、コードをそのままにした状態で市場にリリースするかを判断しなければならないという苦しい立場に立たされる。

　しかも、既知の脆弱性がある製品を市場にリリースすると、企業は非常に深刻なリスクにさらされる。脆弱性が1つでも悪用され、その脆弱性が以前に検出されていたにもかかわらず修正されていなかったという確かな証拠がある場合、企業は多大な金銭的代償を払うことになるだろう。管理の在り方を厳しく糾弾されることは言うまでもない。

　集中管理型のポリシーベースのセキュリティアプローチを取れば、セキュリティ脆弱性を防ぐことができる。なぜなら、開発プロセスの最終段階でセキュリティの確保を図るのではなく、企業が求めるセキュリティ要件に沿ってコードが作成されていくからだ。ポリシー管理、ワークフロー管理、ワークフロー最適化を利用して、開発プロセスの中で、自動化されたセキュリティ対策を進めることで、開発チームはプロジェクトの進ちょくやチームの生産性に支障をきたすことなく、コードのセキュリティを大幅に向上させることができる。

　例えば、静的解析は開発リソースの消耗を招く傾向があり、静的解析をSDLCの後半に監査として行うと、この傾向に拍車が掛かるばかりだ。静的解析を行うタイミングがSDLCの中で後の方になるほど、検出された問題に関連するコードを開発担当者が覚えていて、問題を素早く理解して修正できる可能性は低くなる。開発プロセスの中でのセキュリティ対策として「各開発工程の作業とできるだけ近いタイミングでセキュリティの検証および修正作業を行う」ことを徹底すれば、解析の価値と効果を高められる。

　こうしたセキュリティ対策の一環として静的解析を行うことで、以下の2つの明確なメリットが期待できる。

開発者がより良いプログラミング習慣を取り入れるようになる

　潜在的なセキュリティ問題を修正するための作業が、開発者がコードで実現しようとしていたこととの関連においてより良く理解される。このため、開発者が自分の失敗から学び、最終的に習慣として安全なコードを作成するようになる可能性が高い。

開発者が問題をより迅速かつ容易に修正できる

　開発者は、問題が報告されたときにコードをまだ新鮮に記憶していれば、そのコードについて、「どのような動作を意図していたか」「記述の仕方はどのような理由で選んだか」「セキュリティ要件を満たすように変更を加える場合、どのような影響を考慮しなければならないか」などを思い出そうとして時間を浪費せずに済む。当然のことながら、同じ問題を何週間も何カ月も後になって知ると、同じ結果に到達するのにはるかに多くの労力が必要になる。

　開発プロセスの中でのセキュリティ対策の要となるのが「ポリシー管理」だ。ポリシーに関する企業の目的の整合性を損なうことなく、個別プロジェクトごとに簡単にポリシーを構成することや、個別プロジェクトのポリシーと全社的ポリシーの両方を簡単に展開／更新すること、迅速な問題調査と報告のためにそれらの適用を自動化することが可能でなければならない。

　一連のポリシーを注意深く定義し、実装すれば、開発者の持つ関連するセキュリティIQの向上につながるナレッジベースが構築される。

　策定したポリシーを適用する上では、「ワークフロー管理」が必要になる。ワークフロー管理では、開発生産性を高め、持続可能なプロセスの基盤となるワークフローの定義、自動化、監視が行われる。

　また、品質ポリシーに関する作業は、静的解析プロセスを持続可能でスケーラブルなものにし、チームの既存ワークフローの不可欠な部分としてうまく組み込めるように最適化しなければならない。自動化、反復性、一貫性が実現されないと、企業が展開しようとする品質への取り組みは効果が落ちてしまう。

　ワークフローを最適化する方法の1つは、「セキュリティのための静的解析を、メトリクス分析やピアコードレビューなどほかの分析とともに行う」ことだ。そうすれば、より厄介な、あるいはより複雑なシナリオにまず重点的に取り組ませることで、開発者の時間をより有効に活用できる。

　例えば、コードの特定部分が高い循環的複雑度を持ち、深刻度の高いセキュリティ問題も抱えていることが分かれば、そうした大きく複雑な問題の対策に開発者を動員することが先決となるだろう。実際、これは、ピアコードレビューで議論されるべき事項に集中的に対処するのにコード解析が役立つことを示す格好の例だ。

　ワークフローの最適化方法には、ほかにも次のようなものがある。

報告された各問題への対処を、問題個所を担当した開発者に直接任せるとともに、ポリシーに規定された優先順位に応じて問題の優先順位を設定する：
これにより、重大な問題への対処がタイムリーに行われる
集中型の構成管理を行う：
これにより、ルールセットが一貫して適用され、優先事項やプロセスの変化に合わせて簡単に更新できる
自動リファクタリングをなるべく使用する：
これは、チームができるだけ早くルール違反を正すのに役立つ

本稿筆者のウェイン・アリオラ氏はParasoftの戦略担当副社長として、事業開発チームとSOA／Webソリューションチームを統括している。ハイテクおよびソフトウェア開発業界の戦略コンサルティングを15年経験している。Parasoftで働く前はFasturnで事業開発担当シニアディレクター、PricewaterhouseCoopersで主席コンサルタントを務め、後者では戦略改革業務のリーダーとして認められていた。カリフォルニア大学サンタバーバラ校でBA、インディアナ大学でMBAを取得。