課題 4: 変化への対応力

本提案手法のツールも含め、こうしたセキュリティテストツールには一般に擬陽 性(False-positive)の問題がある。本ツールでも、例えば完全なインフォメーショ ンフロー解析はできておらず、疑わしい箇所は警告としてレポートしている。そ うした警告が実際に問題のある脆弱性のレポートなのか、無視して良いレポート なのかの判断に動的テストを用い、実際のアプリケーションの振る舞いから陽性 か擬陽性かを判断する。4.3.2節の例では、対象アプリケーションに、脆弱性を仕 込むことで、この機能の有効性について確認を行った。

提案ツール自体は既知の脆弱性のあるパッケージのチェックはサポートしない が、これについては、外部のツールと連携して、パッケージの脆弱性を把握でき るようにしている（4.1.7節）。利用しているパッケージに脆弱性が見つかった場 合、本来は早急に該当パッケージを最新版に更新する必要がある。しかし、更新 により機能的な問題が生じる場合などがあり、すぐには対応できないケースが発 生する。こうした場合に、依存パッケージの脆弱性が実際に問題となるのか否か 動的テストにより検証する機能は、実用性が非常に高い。本ツールでは未対応で あるが、今後対応したい機能の一つである。

重要な要素はセキュリティに関わる様々な変化への迅速な対応力である。開発者

はRailroadMapを用いることで、セキュリティに関する様々な情報をメトリック

スの形で利用することができる。

次に、アプリケーション開発に関連する変化を、開発アプリケーションの要求 変化、フレームワークの提供する機能の変化、セキュリティ知識の変化、の３つ に分類し、それぞれについて提案手法との関係をまとめる。

5.1.4.1 開発アプリケーションの要求変化

アジャイルソフトウェア開発では頻繁に要求、つまり必要とされるソフトウェ アの機能が変化してゆく。Webアプリケーションであれば、新しいデータモデル や、ページ遷移が追加された場合、そうした部分へのセキュリティ要求の追加も 同時に必要になる。また、機能が削除された場合には、該当するセキュリティ要 求の削除も同時に必要になる。提案手法では、機能要求の変更に伴うセキュリティ 要求の変更の場合は、4.2.2節で示すように、まず機能要求の変更に従って、実装 作業を進める。その後、実装作業が終了した時点で、ツールによる検証を併用し ながら、セキュリティ機能の実装と、セキュリティ要求の修正作業を進めていく 手順を提案している。この手法のメリットは、1.2節で例として示した、実装コー ド上の様々な箇所に分散したセキュリティ機能の配置を、計画的かつ段階的に間 違いなく進められることである。

一方、RBACによるアクセス制御を実施している場合には、新たなロールの追 加や、アクセス制御リストの権限の見直しなども必要になる場合がある。この場 合は、まずセキュリティ要求を変更し、その後、ツールによる検証を併用しなが ら、セキュリティ機能実装の修正を段階的に実施する。

どちらの場合も、ツールによる警告がなくなり、新たなセキュリティ要求のレ ビューが完了した時点で、更新が完了となる。

今回開発したツールは、その他のセキュリティテストツールと同様に、問題箇 所を指摘するだけである。その結果を元に必要となるレビューやコードや要求の 修正作業は、開発者の責任としている。

このように、本手法は、開発アプリケーションへの要求の変化と、そのセキュリ ティへの影響を捉え、警告とし報告することで、開発者のセキュリティ機能実装 と要求定義の負担を低減している。

5.1.4.2 フレームワークの提供する機能の変化

一般に、フレームワークを用いた開発では、フレームワーク自体の変化への対 応が必要となる。フレームワーク変化には、脆弱性の発覚によるセキュリティアッ プデート、バグ修正に伴うアップデート、機能の変更を伴うメジャーアップデート (セキュリティ機能の変更を含む)などがある。こうした変更に伴って、開発者は

様々な更新作業を実施する必要がある。これはフレームワークのみならず、アプ リケーションが利用している外部パッケージについても当てはまる。

提案手法では、アプリケーションが依存するフレームワークや外部パッケージ が提供する機能をコマンドライブラリの形でまとめている。したがって、フレー ムワークや外部パッケージ側で生じた変更は、コマンドライブラリの修正で対応 する必要がある。

5.1.4.3 セキュリティ知識の変化(外部環境の変化)

これは、開発するアプリケーションに依存するが、例えば法令や規制の変更な どがアプリケーションの要求の変更につながるケースが想定できる。現在提案し ているフレームワークでは、そうした前提条件と要求とを取り扱う仕組みは提供 できていない。例えば、HIPPAやPCI-DSSへの順守の確認ができるようにフレー ムワークを拡張することも、今後検討する必要がある。これは、ある産業ドメイ ンのセキュリティ知識を扱えるようにすることを意味する。

もう一つは、新たな攻撃手法への対応である。これは前節とも関係するが、コ マンドライブラリの更新と、本ツール側での対応で対処可能であると考える。

5.1.4.4 ツール自体の保守

本ツールもRubyのアプリケーションの一つであり、バグの修正や、新機能の追 加が絶えず必要となる。実際に、様々なRailsアプリケーションについて本ツール の適用を試みたが、新たな実装スタイルへの対応が必要となり、コードの修正や 機能追加が必要となった。Rubyは様々な記述が可能である。また新規の機能パッ ケージが利用されている場合には、そのパッケージに対応できるように、本ツー ルの修正が必要となる場合が多く発生した。Rubyの構文については、未対応の構 文があった場合にはエラーとして報告している。コードからのセキュリティ検証 モデル生成についても、遷移先が見つからない場合はエラーを報告する。

そうした個別の問題を細部にわたってサポートするか、開発者の判断で補正す るかの判断は難しいが、基本的には、本ツールの実装が出来るだけ単純になる形 で個別の問題への対応を進めてゆくことにした。本ツール自体もアジャイルソフ トウェア開発に対応し、テスト駆動で機能拡張を進めている。