アジャイルソフトウェア開発とセキュリティ保証

アジャイルソフトウェア開発とは、迅速かつ適応的にソフトウェア開発を行う 手法の総称であり、2001年に定義されたアジャイルソフトウェア開発宣言¹⁰を以 下に引用する。

アジャイルソフトウェア開発宣言

✓ ✏

「私たちは、ソフトウェア開発の実践あるいは実践を手助けをする活動を通じ て、よりよい開発方法を見つけだそうとしている。この活動を通して、私たち は以下の価値に至った。

プロセスやツールよりも個人との対話を、包括的なドキュメントよりも動くソ フトウェアを、契約交渉よりも顧客との協調を、計画に従うことよりも変化へ の対応を、価値とする。すなわち、左記のことがらに価値があることを認めな がらも、私たちは右記のことがらにより価値をおく。」

✒ ✑

アジャイルソフトウェア開発は適応的な開発であり、リリースサイクルも週単 位以下と非常に短期間である。これに対して、従来のウォーターフォール型の開 発は計画重視の開発であり、数ヶ月から数年の開発期間を想定する。変更コストが 増大しないという前提で、事前計画よりも柔軟性を重視する。アジャイルソフト ウェア開発においても、計画、要求分析、設計、実装(コーディング)、テスト、文 書化 が実施される。現実的には実装(コーディング)とテストが主体となり、チー ム作業による意思の疎通が重んじられ、結果として文書化が少ない。

アジャイルソフトウェア開発の代表的な手法には下記が知られており、また広 く現場でも実践されている。

反復(イテレーション) 小さな作業対象、短い開発期間で開発を行う。リスクを 最小化しようとしている。

テスト駆動開発(TDD: Test-driven Development) テストファーストデザイン、

テストケースを最初に用意し、そのテストが通るようにコーディングを進 める。

リファクタリング 外部インターフェースや振る舞いの変更は行わないコードの最 適化を行う。

継続的インテグレーション 絶えず稼働する状態をキープする 機能駆動型開発（FDD: Feature Driven Development）

また、次のような定式化されたアジャイルソフトウェア開発手法がある。

エクストリーム・プログラミング(XP: eXtreme Programming) 5つの価値、

19のプラクティス[1]

10http://www.agilemanifesto.org/

スクラム(Scrum) バックログによる要求管理、スプリントとよぶ反復[3]

表2.7にウォーターホール型開発とアジャイル型開発の比較を示す。アジャイル 型開発で必要なセキュリティ保証の手法は図2.4の開発フローに適合する、高速、

軽量な仕組みである。その実行に何日もかかるような脆弱性スキャナではなく、コ ンパイラのようにコマンド実行で即座に実装とデザインの問題点を指摘するツー ルが必要である。

表2.7: ウォーターホール型開発とアジャイル型開発の比較     ウォーターホール型開発 アジャイル型開発

開発コード量 膨大 少ない

開発者 100−1000名 数名ー20名

開発の中心 計画 コード（テスト、ソース）

文書化 充実 不十分

リリースサイクル 半年、数年 週

モデル駆動開発 適 不適

モデル駆動テスト 適 不適

セキュリティテスト手法 確立(成熟度モデル) 未整備

すべてのウォーターフォール型の開発がアジャイルソフトウェア開発に移行で きるわけではない。少なくとも、アジャイルソフトウェア開発の実践にはいくつ かの条件がある。小さなチーム、顧客との直接的なコミュニケーションなどが条 件としてとりあげられるが、それが可能となるのは、開発し保守すべきコード量 が重要であると考えられる。実際にアジャイルソフトウェア開発が実践されてい るWebアプリケーション開発では、フレームワークの整備が進んでおり、アプリ ケーションの実装は、その振る舞いを実現するための最小限のコードで実現する ことが可能である。つまり、フレームワークにより、Webアプリケーションで必 須な機能の大半がサポートされており、開発者は個別のアプリケーションのロジッ クに注力すれば良い。

図2.4にアジャイルソフトウェア開発プロセスの一例を示す。この図からわかる ように、従来のウォーターフォール型のソフトウェア開発とは開発の流れが全く 異なる。これが可能となるのは、アプリケーションドメインに特化したフレーム ワークの存在が大きい。

この場合、ウォーターフォール型で重要であった上流工程は、フレームワーク に吸収されていると考えることができる。フレームワークはセキュリティガイド ラインを示すが、それはフレームワークを用いたアプリケーション実装のセキュ リティに関する注意点であり、Webアプリケーションの持つべきセキュリティ要 求のすべてを規定するものではない。

図 2.4: Agile開発モデル

2.3.3 アジャイルソフトウェア開発のセキュリティに関する関連研究

ここでは、アジャイルソフトウェア開発とそのセキュリティ保証の問題ついて、

関連研究をまとめる。

Beznosovらは、従来のセキュリティ保証の手法26個のアジャイルソフトウェ

ア開発との整合性を４つのタイプ（整合、開発手法に無関係、自動化で対応可能、

非整合）に分類した[19]。その中で、明確に不整合と分類された手法は12個あ り、半数近くの手法がアジャイルソフトウェア開発に適さないとしている（表2.8 参照）。その後、Keramatiはセキュリティ保証手法のアジャイルソフトウェア開 発手法への適用性の定量化を試みている。具体的には９つの指標（単純さ、カス タマーとのやりとり、モデリングや文書化の負担、変更への耐性、実行速度、非 形式性、教育、反復性、柔軟性）について５段階で評価することで、ジャイルソ フトウェア開発手法との整合性を数値化した[45]。また、Al-AhmadらはCLASP のセキュリティ保証手法のXPのマッピング方法を提案している[6]。プロセスで 見た時のアジャイルソフトウェア開発とセキュリティ保証手法の不整合の原因は、

文書化と第三者によるテストやレビューである。

セキュリティの問題に対応できるようにアジャイルソフトウェア開発手法を拡 張する提案としては、以下の研究がある。

Nicolaysenらが実施したケーススタディでは、アジャイルソフトウェア開発手

法を採用している開発現場において、たとえそれがWebアプリケーションのよう に攻撃が想定される場合でも、セキュリティの確保にむけた特定の手法が用いら れていなかった。そこで、アジャイルソフトウェア開発手法(ここではScrum)に

セキュリティを組み込む方法として２つの拡張を提案している。ひとつはバック ログにセキュリティ要求を加えることで、チーム全体でセキュリティの問題を共 有すること。もうひとつは、セキュリティ機能の実装をテスト駆動開発で進める ことである[53]。

Erdoganらも同様に Scrumに対してセキュリティ保証の手法を追加した手法

EAST(Extended Agile Security Testing )を提案している[33]。EASTではバッ クログに対して、ミスユースケースを作成しセキュリティ要求を洗い出し、受け 入れテストに反映させる。また、セキュリティに関する判断を文書化し蓄積する ことでチーム内でセキュリティの知識を共有する。

Bostrom らはXPを拡張し、アブユースをセキュリティ要求を獲得し利用する

手法を提案している[21]。テスト駆動開発によるセキュリティテストについての 可能性については、Tappenden らが HTTPunit を用いて攻撃をテストケースと して作成することで、テスト駆動開発とセキュリティテストの統合を提案してい る[62]。同様に、Kongsliは受け入れテスト・ツールSeleniumを用いたセキュリ ティ・テストを提案している[46]。

以上から、アジャイルソフトウェア開発にセキュリティ保証を取り組むには、手 法の軽量化が重要であることがわかる。また、反復型の開発では、セキュリティの 要求や課題を継続して取り扱える仕組みが重要である。セキュリティテスト駆動 によるセキュリティ機能の実装もアジャイルソフトウェア開発と整合性が高い。

2.3.4 セキュリティ保証手法とアジャイルソフトウェア開発との整

合性の分類

最新のセキュリティ成熟度モデル、BSIMM第5版(2013)で列挙されているセ キュリティ保証の手法について、[19]と同様の分析をおこなった結果を付録Aの 表A.1–表A.12に示す。BSIMMは比較的大きなソフトウェア開発組織をターゲッ トとしているため、ソフトウェアのセキュリティを扱う専門部隊、SSG(Software Security Group)や専属のQA(Quality Assessment、品質保証)チームが想定され ている。

開発チームの外部にこうした組織の存在が必要となると、アジャイルソフトウェ ア開発との整合性が失われる。したがって、アジャイルソフトウェア開発の場合 は、開発チームへのセキュリティのトレイニングと、開発チーム内で十分にセキュ リティ問題に取り組める体制、以上を効率的にサポートできるセキュリティ保証 手法（ツール）が必要である。

次に問題となるのが、文書化に依存するセキュリティ手法である。これについ ては、文書化の負担を低減する手法の導入が必要である。

表2.8: セキュリティ保証手法とアジャイルソフトウェア開発との整合性[19]

開発フェーズ  手法           整合性分類

       整合  自動化   不整合   独立

Requirements Guideline  独立

Specification analysis 不整合

Review 不整合

Design Application of specific architectural approaches 独立

Use of secure design principles 独立

Formal validation 不整合

Informal validation 不整合

internal review 整合

external review 不整合

Implementation Informal correspondence analysis 不整合

Requirements testing 自動化

Informal validation 不整合

Formal validation 不整合

Security testing 自動化

Vulnerability and penetration testing 自動化

Test depth analysis 不整合

Security static analysis 自動化

High-level programming languages and tools 独立

Adherence to implementation standards 独立

Use of version control and change tracking 独立

Change authorization 不整合

Integration procedures 独立

Use of product generation tools 独立

Internal review 整合

External review 不整合

Security evaluation 不整合