アプリケーションの開発に使用するセキュリティ対策ツールの種類と特徴
次に、Webアプリケーションの開発に使用する各種セキュリティ対策ツールの特徴を紹介します。
静的解析ツール（Static Application Security Testing）
アプリケーションのソースコードや、ライブラリの構造を解析して脆弱性があるかどうかを調べるツールです。静的解析ツールではソースコードを直接解析するため、開発中でアプリケーションがまだ動作しない状態でも解析を行うことができます。ソースコードを直接解析するという特性上、ツールごとに対応するプログラミング言語が異なります。ツールによって解析方法は異なり、簡易なパターンマッチングから、データフローを解析するなど、さまざまな手法が用いられています。
アプリケーションを実際に動かさないため、処理の流れを正しく解析できない場合があり、実際に問題がないような箇所も脆弱性として判定する過剰検知が、後述の動的解析ツールに比べて多くなる傾向にあります。また、ソースコードを直接解析するため、開発の初期段階からアプリケーションの開発中に組み込むことができます。さらにソースコードの修正箇所だけをチェックする機能を備えたツールもあり、開発ライフサイクル全般に組み込みやすいのも特徴です。
- 代表的なツール：SonarQube（OSS）、Coverity、CxSAST、Fortify
動的解析ツール（Dynamic Application Security Testing）
実際に動作するアプリケーションに対して、疑似的な攻撃パターンを送信し、脆弱性があるかどうかを検査するツールのことです。アプリケーションの挙動を元に脆弱性の有無を判断するため、静的解析ツールよりも過剰検知が少なく、実際に問題となる脆弱性を効果的に検出できる傾向にあります。ただし、検査用の環境を事前に構築する必要があるうえ、静的解析ツールに比べて検査時間が長くなる傾向にあります。さらに検査対象のアプリケーションの性能によっても検査時間が左右されます。
多くのツールが簡単に検査できるオートクロール機能と、細かく設定できる手動検査機能を搭載しています。手動検査設定を作り込むことで、検査時間を短縮し、より正確に検査することもできます。しかし検査設定を作りこむ作業は手間が掛かるうえ、アプリケーションの修正に合わせて検査設定の見直しが必要になります。そのため、開発ライフサイクルに組み込む場合はアプリケーションの仕様が安定するまではオートクロール機能を使い、アプリケーションの初回リリース直前など、仕様がある程度安定してきたら、手動設定を作り込んで正確に検査を行うといった工夫が必要になります。
また、アプリケーションの挙動から脆弱性を検出するという特性上、プログラミング言語に依存しないというメリットはありますが、ソースコードのどこを修正したらいいかまでは指摘することができません。
- 代表的なツール：OWASP ZAP（OSS）、AppScan、Vex、WebInspect
SCA（Software Composition Analysis）
静的解析ツールの一種ですが他のツールと特徴が異なるので個別に取り上げます。SCAとは、脆弱性が報告されているサードパーティー製のライブラリを使用していないか調査するツールです。アプリケーションが使用しているライブラリに脆弱性が見つかると、その脆弱性を悪用されるおそれがあります。このようなツールを使用し、脆弱性情報が公開されているライブラリを使用していないか、新しい脆弱性が公開されていないかをチェックし、脆弱性が見つかった場合は素早くアプリケーションの更新を行う必要があります。
- 代表的なツール：OWASP Dependency-Check（OSS）、Retire.js（OSS）、Vuls（OSS）、AppCheck、Black Duck Hub
IAST（Interactive Application Security Testing）
動的解析ツールと静的解析ツールの長所を併せ持つツールになります。基本的には、動的解析ツールと同じような特徴があります。しかし、実行環境を監視しながら動的検査を行うことで、脆弱性の検出時に問題のコードを特定することができます。しかし、実行環境を監視しながら検査を行うため、アプリケーションの動作が遅くなる可能性があります。
- 代表的なツール：CONTRAST ASSESS、Seeker
ここまで紹介したツールはどれも未検知という、脆弱性が存在するのに検出できないという問題が発生します。未検知となってしまう脆弱性を減らすためには、それぞれのツールの特徴を理解し、複数のツールを組み合わせることが必要になります。しかし、複数のツールを導入する場合、過剰検知の判断に時間が掛かり、本当に修正すべき脆弱性がすぐに分からないという問題に悩まされる場合があります。どれが本当の脆弱性か判断できないと、修正の優先度付けが困難になります。その結果、修正すべき脆弱性が放置され、ツールが有効に活用されなくなってしまいます。
このような状況を防ぐためには各ツールの検査結果を集計し、検査結果を管理するということが必要になります。最近では複数のセキュリティ対策ツールの検査結果を統合・管理するAVC（Application Vulnerability Correlation）と呼ばれるツールも出てきています。
ここまで説明したツール以外にも、Webアプリケーションの実行中に攻撃を検知・阻止するツールとして以下のようなツールが存在します。どちらもアプリケーションの防御用のツールとなります。アプリケーションの動作環境によっては、これらのツールを導入することが難しい場合や、防御用のツールではアプリケーションへの攻撃を防ぎきれない可能性もあります。そのため、これらのツールを導入していたとしても、アプリケーションの開発中からセキュリティ対策を行う必要があります。
WAF（Web Application Firewall）
Webアプリケーションの実行中にWebアプリケーションへのリクエストを中継し、アプリケーションへの攻撃を検知・阻止するツールです。これはアプリケーションの開発中に利用するものではなく、アプリケーションの運用中にアプリケーションを守るために使用します。
RASP（Runtime Application Self-Protection）
WAF同様、アプリケーションの実行中に攻撃を検知・阻止するツールです。こちらも、アプリケーションの開発中に利用するものではなく、アプリケーションの運用中にアプリケーションを守るために使用します。アプリケーションの実行中に動作する点もWAFと同じですが、WAFとは異なりアプリケーションに組み込む必要があります。
まとめ
簡単にまとめると、今回のポイントは以下のとおりです。
- DevSecOpsの目的は、安全なソフトウェアを頻繁にリリースすること。
- 安全なアプリケーションを頻繁にリリースするためには、セキュリティ対策ツールを開発ライフサイクルに組み込むことが大事。
- どのセキュリティ対策ツールも実際の脆弱性を誤って未検出と判断する可能性がある。未検知を減らすためには複数のツールを組み合わせることが必要。
- 過剰検知を管理し、修正の優先度を管理することが大事。
- WAFやRASPで防ぎきれない場合もあるので、アプリケーションの開発中からセキュリティ対策を意識する必要がある。
次回はDevSecOpsを実現するために、各種セキュリティ対策ツールを開発工程のどのタイミングでどのように導入すべきかについて説明します。
