＊以下はCheckmarx社によって書かれた下記URLの記事を翻訳したものです。
　https://www.checkmarx.com/2017/09/25/need-automated-security-agile-software-environment/

Sep 25, 2017 By Sarah Vonnegut

昨今のビジネスサイクルでは競争力を維持するために、かつてないほど迅速かつ革新的な成果をあげることが求められています。多くの企業がリリースのスピードを上げ始めたときに、ウォーターフォール型開発モデルがもはや機能していないとすぐに気づき、より俊敏さを備えたアプリケーション開発手法を考案して適用することで対処したのです。それらの手法の1つであるアジャイルソフトウェア開発は、ほぼ間違いなく一番評価の高い手法であり、世界中で数々の企業によって採用されています。

アジャイルソフトウェア開発: 新しい開発モデル

アジャイルソフトウェア開発で一番大切なことはスピードであり、ビジネスの観点において大規模で長期的な目標に合致するよう2週から4週ごとに、スプリントと呼ばれる短期間の目標を継続的に設定して達成することが特徴です。スプリントは、職能横断型の小さな開発チームによって完遂されます。この開発チームは短期的な目標に合致する日次または週次のタスクを完了させるために、毎日スクラム会議を開きます。アジャイルなプロセスでは、作業のふりかえり/調整/改善を何度も繰り返し行うことを奨励し、チームワーク/成果責任/自己組織化という考えを重要視します。

アジャイルな開発環境には数え切れないほどのメリットがあります。例えば、これまでにない速さで製品をリリースできることはもちろん、顧客のフィードバックや一般市場の要求に対して一段と適切に素早く対応できることや、開発者がより積極的かつ献身的に作業に取り組める点が挙げられます。アジャイルな開発工程を導入した多くの企業は、アジャイルな手法から得られるこれらのメリットによって大きな成功を収めています。

アジャイルソフトウェア開発におけるセキュリティの現状

アジャイルな開発プロセスにはさまざまなメリットがありますが、このプロセスを適用する数多くの企業にとっては、残念ながらセキュリティが大きな課題となっています。

その理由の1つとして、アジャイルな開発工程におけるセキュリティ上のプロセスや検査の欠如があります。セキュリティは設計や計画などSDLCの序盤で検討されることもありますが、大抵の場合はリリースの直前、すなわちSDLCの終盤近くで実施されるセキュリティテストまで棚上げされます。その結果として、質の低いコーディングやセキュアなコーディングに関する知識不足により、セキュリティ上の問題が生じやすいSDLCの中盤においてセキュリティ対策がすっぽりと抜け落ちてしまうのです。

その代わりに、多くの企業はセキュリティ上の問題を見つけて修正するために、SDLCの本当に最後の段階になって手動テストや動的セキュリティ検査（DAST：Dynamic Application Security Testing）に頼ります。その結果はどうでしょう？アプリケーションは、十中八九セキュリティ上に大きな問題を抱えたままリリースされることになります。このセキュリティ上の問題はペネトレーションテストやDASTでは検出できなかったものか、リリースを遅らせるほど深刻ではなく、リリース後に急いでパッチを提供することで対応すると判断されたものになります。修正が必要なほど深刻と考えられるバグはリリースを遅らせ、また開発の早い段階で発見された場合と比べ修正費用が増大します。

アジャイル開発を行っているかどうかを問わず、前述の話は多くの企業に当てはまります。しかし、迅速なリリースによって生み出される潜在的なリスクの高さや、そのようなリスクを低減するセキュリティプロセスの連携不足などが原因となり、アジャイルな開発を行う企業において特に大きな問題になりやすいです。

アジャイルな開発環境においてセキュリティ検査の自動化が必要な理由

アジャイル開発が浸透した現代において、より上手にセキュリティ検査をアジャイルなプロセスに組込む必要があります。セキュリティチームは、アジャイルな開発プロセスが機能しなくなるほどの大幅な変更を加えるべきではない点を理解することが重要です。つまり、セキュリティ検査を実施するために、アジャイル開発の速度を緩めることはできません。しかし、セキュリティとアジャイル開発とを緊密に連携できるいくつかの方法が存在します。そのベストな方法の1つに、開発時におけるセキュリティ検査の自動化があります。

自動化は、アジャイルな手法における主な考え方の1つです。これは、アジャイル開発を行う企業にとって「効率性」が非常に重要になっているという点からも理にかなっているでしょう。代わり映えのない定形的な作業を自動化することによって、開発者は一段と複雑かつ観念的で創造性に富んだ作業に集中することができます。もちろん、自動化はソフトウェア開発に限ったことではありません。まさにこの理由で、製造ライン、自動車、ドローンなどのあらゆる場所で自動化が導入されています。

セキュリティ検査も例外ではありません。セキュリティ欠陥のそのほとんどは、この20年で目にしてきたXSS、SQLインジェクション、CSRFをはじめとするOWASP Top 10などで“おなじみ”の脆弱性と同じです。セキュリティ検査はコーディング作業から完全に切り離されているため、多くの開発者は単純にこれらの脆弱性についての理解が十分ではありません。例えば、コードのチェックイン前に開発者によるセキュリティ検査を行い、問題箇所を修正できるよう即座に検査結果を提供するようなセキュリティ検査を開発工程に統合することで、適切なタイミングでセキュリティ検査を行えるだけではなく、開発者はセキュアなコーディングについて理解を深めることができるのです。

ほとんどの開発者は滞りなく業務を進めたいと考えますが、セキュリティに関しては多くの開発者がその重要性や自分たちがどれほどセキュリティに影響を及ぼす可能性があるのか、という点について学ぶ機会がありません。しかし、チームリーダが従来のセキュリティ検査よりも、テスト駆動開発工程の一貫として新たなセキュリティ検査に価値を見出すことで、セキュリティ検査は重要ではないと捉えることや、セキュリティ検査が開発業務の範囲外である、というような根拠のない迷信から解放されます。

そのうえ、開発工程でセキュリティ検査を自動化することは、継続的な監視を行ってレベルの高い可視化を実現し、アジャイルなプロセスの中でセキュリティ検査を実施する際に、より適切な箇所を選択する助けになります。これは、開発者とセキュリティ担当者の連携を促す新たな一歩であり、将来的により良い関係を築くことができます。

これまでとは異なり、セキュリティ検査は大きく分厚い壁ではなくなっています。静的コード解析ツールは飛躍的に進歩しており、CheckmarxのCxSASTをはじめとした多くのツールは、従来のセキュリティ検査の考え方とアジャイル開発の考え方における違いによって生じる、さまざまな問題を解決するために必要なソリューションを提供します。これらのツールは開発者のIDEに構築することで、検出された脆弱性やその最善の修正方法についてのレポートをすぐに作成できます。これにより、簡単かつ手軽に問題を修正でき、セキュリティ担当者と開発者間における一段と調和の取れた統合環境の構築を実現します。

もちろん、ありとあらゆるものを自動化する必要はありませんが、アジャイルな環境でDASTや手動検査を行うことは必要です。各企業において、リスクとアジャイルな環境に求められる開発スピードとのベストなバランスを見極めることが重要となります。セキュリティ対策は、現在もそしてこの先も常に企業にとって重要な役割を果たします。適切なツールを選び、セキュリティチームと開発チームを密に連携させ、開発工程へのセキュリティ検査の組込みに前向きに順応しさえすれば、アジャイルな開発環境であっても「セキュリティ」を確保することは可能なのです。

参考情報

• An Introduction to IAST
   

Sarah Vonnegut

Checkmarx社でソーシャルメディアを担当しながら、コンテンツチームで編集とライターを兼務。知名度の低いアプリケーションセキュリティの問題に光を当て、コンテンツを通し、このセキュリティリスクに溢れた世界でハッカーの常に先をゆく重要性を企業のセキュリティ担当者に訴えていく努力を続けている。