今後の課題

の警告がレポートされてしまい、個別の問題の修正が難しくなる。個別の問題に 対応するためには、逆にミクロな視点で、問題箇所の周辺の実装を理解して、コー ドの修正を正しく行う必要がある。

こうした、特定の問題を深掘りする機能として、3.3.3節と4.1.5節でトレース 機能について簡単に説明した。提案手法では、コマンド実行により対象のアプリ ケーション全体を一度に処理している。そして、修正対象のエラーや警告につい て、その関連情報を詳しくダンプすることで、問題の詳細な理解を行うのがトレー ス機能である。

こうした課題に対応するのが、個別の問題を柔軟に取り扱える、セキュリティテ スト手法である。一つの方法は、前節でも指摘したように、セキュリティ保証の 機能をAPIとして整備し、テストスクリプトで柔軟に問題を扱える仕組みを実現 することである。つまり、セキュリティ保証の作業を適切な粒度でAPI化（手続 き化）し、ライブラリとして提供することで、アプリケーションテスト環境にセ キュリティ保証に組み込む。

次に、セキュリティ検証モデルの可視化についての課題と、今後の研究方針につ いて整理する。アプリケーションが大規模になると、制御フローモデルやデータ フローモデルも巨大になる。その結果、生成されたモデルを開発者は簡単には確 認できなくなる。現在は表の形でHTMLのレポートを生成しているが、HTML5 を用いた検索機能を追加しているため、個別の遷移やデータの流れを表で確認す ることは容易である。しかしながら、モデルが示す動的な振る舞いを、表形式で 確認することは難しい。

一方、セキュリティ検証モデルの制御フローやデータフローを「状態遷移図(State Diagram)」の形で出力することは可能である。例えば、GraphivizのDOTなどを 用いて作図が可能であるが、Webアプリケーションの制御フローには多くのルー プが存在するため、複雑に絡まった図が生成される事になる。これは、アプリケー ション全体の規模の確認には十分に使えるが、個別の問題解決のための検討を、グ ラフ上で行うことは難しい。作図についても、人間が目でレビューをすることを 前提として、どのような表示方法が良いか十分に検討する必要がある。

ソフトウェアの関心部分のみを抜き出す手法として「プログラムスライシング」

や「モデルスライシング」が知られている[14]。セキュリティの問題を個別に解 析する際にも、こうした手法を用いることで開発者に問題箇所をわかりやすく提 示できる可能性がある。

5.3.3 アプリケーションの実装方法に関する課題

4.5.3節や、4.6節で扱ったアプリケーション、Railsgoat に仕組まれた脆弱性 の多くは、コマンドの実装に関する物であった。アプリケーション独自のでセキュ リティ機能を実装する場合には、開発者がセキュリティコマンド自体の実装が安

全であることを検証する必要がある。一方、セキュリティ機能として、フレーム ワークや、広く利用されているパッケージを利用する場合には、開発者は利用す るパッケージに脆弱性が無いことに留意すればよい。また、本手法を適用する場 合には、利用しているパッケージに対応するコマンド抽象化ライブラリの定義が 正しいことが重要である。

セキュリティに関するコマンドを実装する場合に、コマンドが提供するセキュ リティ機能の粒度について配慮することで、本手法で扱いやすいコマンドとなる。

例えば、一つのコマンドが、ある特定のセキュリティ機能に対応していると、ツー ルによるセキュリティ機能の特定や、テストカバレッジの計測に都合が良い。これ はテストケース記述にも該当し、セキュリティテストの記述に適した、セキュリ ティテスト用のコマンド定義が存在する。つまり、実装コードやテストケース上で セキュリティの問題をトレースしやすいように、コマンドを作成する。 これらを、

より定式化し、セキュリティ機能を分類することで、コマンドレベルの抽象化に よるセキュリティ保証に適した、実装のガイドラインを定義できる可能性がある。

5.4 まとめ

以上、5章では、提案手法が2.6節で挙げた4つの課題を解決できたか評価する とともに、関連研究や既存手法と提案手法の比較をまとめ、今後の課題を４つ指 摘した。提案手法は、最初に掲げた課題を十分に解決する、新しいセキュリティ保 証の仕組みを実現しているといえる。