SAST・DAST・IAST 徹底比較｜最適なアプリケーションセキュリティテストを選ぶポイント｜ブログ

SAST/DAST/IASTによるセキュリティテスト｜システムに応じた最適なセキュリティテストとは？

現代のソフトウェア開発において、プロダクトの競争力を高めるためには、市場のニーズに迅速に対応し、変化に柔軟に対応できるような開発速度が求められています。その一方で、アプリケーションセキュリティは企業の信頼を左右する課題の一つとして、その重要性を増しています。攻撃者によるサイバー攻撃を受けることで、個人情報漏洩やサービス停止、企業のブランドイメージ毀損など、様々な被害につながる可能性があります。

そのため、ビジネスの継続性を確保し、顧客からの信頼を維持するためには、堅牢なアプリケーションセキュリティ対策が不可欠です。米サイバーセキュリティ・社会基盤安全保障庁（CISA）のSecure by Design 宣誓のソフトウェアベンダが優先して改善すべき7つの目標の一つである「Reducing entire classes of vulnerabilityにおいても、製品の脆弱性を減らしていくことが求められています。セキュアなアプリケーションは、企業の財産を守るだけでなく、競争優位性を築く上でも重要な要素となります。

このような状況下において、開発速度を維持しつつ、セキュアなプロダクト開発を進めていくためには、開発プロセスの中に適切なセキュリティ対策を組み込むことが求められます。

本ブログでは、これらの課題解決策の一つとしてアプリケーション・セキュリティ・テスト（AST）に焦点を当て、SAST（Static Application Security Testing）、DAST（Dynamic Application Security Testing）、IAST（Interactive Application Security Testing）という3つの主要な手法について、その特徴や活用方法を解説します。

開発工程に潜む課題

製品の競争力を高めるために開発スピードが加速する現代において、開発速度を維持しながらセキュアな製品を開発することは、企業にとって喫緊の課題です。本節では、開発速度とセキュリティの両立を阻害するよくある4つの課題について紹介します。

開発速度を阻害する課題1：リリース直前に発見される脆弱性の改修によるリリースの遅延

多くの開発プロジェクトでは、リリース直前にセキュリティ診断を実施することでプロダクトのセキュリティを担保しています。セキュリティ診断の利点としては、基本的に手動でアプリケーションセキュリティテストを行うため、網羅的にセキュリティリスクを洗い出せる利点があります。しかし、手動診断の実施タイミングがリリース直前になるため、開発中や設計中に脆弱性を修正するよりも脆弱性の修正コストが高くなる傾向にあります(参考記事)。また、大量の脆弱性が発見された場合や修正難易度が高い脆弱性が発見された場合は、修正に時間がかかり、当初予定していたリリーススケジュールが大幅に遅延する可能性があります。もし、発見された脆弱性の修正が間に合わない場合、脆弱性を抱えたまま製品のリリースをすることで、当該脆弱性を悪用されることによるセキュリティインシデントのリスクを高めてしまいます。

開発速度を阻害する課題2：セキュリティ診断の長期化によるリリースの遅延

セキュリティ診断は、一般的に外部専門家に委託するケースが多く、外部ベンダとの契約交渉やスケジュール調整が必要になります。そのため、必ずしも自社の希望のタイミングかつ希望通りのスケジュールでセキュリティ診断を受けることができない場合があります。また、セキュリティ診断では一般的に手動による診断を行う都合上、診断期間が数週間以上要する可能性もあり、開発スケジュールに影響を与える可能性があります。

セキュリティ課題1：セキュリティ知識不足とセキュリティ人材不足によるセキュリティリスクへの対策漏れ

セキュア設計やセキュアコーディングはセキュリティの知識が求められます。しかし、開発者全員がセキュリティに関する深い知識を持っているとは限りません。そのため、セキュリティ知識や専門人材の不足によって、脆弱性を作り込んでしまうリスクや、手動レビューでも発見できないリスクが生じます。

セキュリティ課題2：低頻度なアプリケーションセキュリティテストによるセキュリティリスクの検知漏れ

アプリケーションセキュリティテストは、新たな脆弱性や攻撃手法の進化に対応するために継続的に実施することが望ましいです。しかし、外部専門家によるセキュリティ診断は、前述の通り調整コストが発生しセキュリティ診断の実施ごとに費用が発生するため、セキュリティ診断の実施頻度は検討する必要があります。そのため、マイナーバージョンアップリリースの際などにアプリケーションセキュリティテストを実施しないことにより脆弱性が埋め込まれたままリリースしてしまうリスクや、新たな攻撃手法の登場や環境の変化により脆弱なシステムになるリスクが存在します。また、アプリケーションセキュリティテストを定期的に行わない場合、久しぶりの診断で大量の脆弱性が見つかり、修正コストの問題から脆弱性が放置される可能性があります。

SAST/IAST/DASTと手動セキュリティ診断の比較

このような課題に対処し、開発のスピードとセキュリティを両立させるために活用できる対策の一つとして、アプリケーション・セキュリティ・テスト（AST）ツールがあります。

ASTは、アプリケーションの脆弱性を発見・評価するためのテスト手法の総称で、SAST（Static Application Security Testing）、IAST（Interactive Application Security Testing）、DAST（Dynamic Application Security Testing）の3つがあり、それぞれ異なるアプローチでアプリケーションのセキュリティテストを実施します。

SAST/IAST/DASTはいずれもアプリケーションの脆弱性検査を自動で実施することは共通している一方で、異なる点が様々存在します。SAST、IAST、DAST、手動セキュリティ診断の動作原理を表した図と特徴を比較した表に下記に示します。

比較軸	SAST（ツール）	IAST（ツール）	DAST（ツール）	セキュリティ診断（手動）
検査原理	ソースコードを解析することで脆弱性を検出する。コードの質やコーディング規約の違反も確認するツールも存在する	アプリケーションの内部動作をリアルタイムで監視し、潜在的な脆弱性を検出する	アプリケーションに対して外部から攻撃を模擬したテストを実行し、外部的な振る舞いを分析することで脆弱性を検出する	アプリケーションの外部的な振る舞いを分析することで脆弱性を検出する
テストタイミング	コーディング中	機能テスト、UIテスト	テスト（リリース前・外部診断）	リリース前
診断対象	ソースコード	動的テスト中の実行アプリ	実行アプリ	実行アプリ
対応プログラミング言語・フレームワーク	ツールの対応プログラミング言語・フレームワークに依存	ツールの対応プログラミング言語・フレームワークに依存	プログラミング言語・フレームワークに依存しない	プログラミング言語・フレームワークに依存しない
検査実施に必要な準備	ソースコードが存在すれば検査可能	検査対象の機能をカバーできるテストケースの作成、もしくは手動で画面を巡回することが必要	検査対象のHTTPリクエストをカバーできるシナリオ作成が必要	診断ベンダとの調整を行う必要がある
検出可能な脆弱性	検知ルールに対応する脆弱性を検出可能（脆弱性検知の他に）	検知ルールに対応する脆弱性を検出可能。比較的新しいツールのため、開発言語に応じては検知ルールが少ない場合がある	検知ルールに対応する脆弱性を検出可能。最終的な実行アプリに対して検査を行うため、検出可能な脆弱性は多い傾向がある	網羅的な脆弱性検出が可能。ツールで検出できないアプリケーションロジックや認証認可の脆弱性なども検出可能
過検知の量	ソースコードのみで脆弱性判断を行うため、一般的に過検知が多い	実行アプリ内部の挙動を確認するため、一般的に過検知が非常に少ない	実行アプリの挙動を確認するため、一般的に過検知が少ない	セキュリティコンサルタントにより過検知は取り除かれるため、過検知は存在しない
検査時間	一般的に短い（数分から数時間であることが多い）	機能テスト・UIテストを実施しながら動的検査となるため、テスト時間に依存する	一般的にやや長い（数時間から1日程度であることが多い）	一般的に長い（数日から1か月程度）

ASTツールの導入効果と注意点

SAST/IAST/DASTは、検査原理の違いにより特徴が異なりますが、適切に開発プロセスに組み込むことで下記のような効果を期待できます。

アプリケーションセキュリティテストのシフトレフトによる修正コスト削減
ツールによる継続的なアプリケーションセキュリティテストや通常リリースの際のアプリケーションセキュリティテストによるセキュリティの向上
ツールによるアプリケーションセキュリティテストの自動化や短縮化によるリリース速度の向上
セキュリティツールの使用によるセキュリティ知識・ノウハウの取得

一方で手動のセキュリティ診断とは異なる3つの注意点が存在します。

一つ目は、ASTツールは機械的に検査を実施するため、アプリケーションロジックに起因する脆弱性や認証認可の不備などのように検出不可能な脆弱性が存在する点です。そのため、セキュリティ診断・検査の全てをASTツールで実施するのではなく、必要に応じて手動のセキュリティ診断を行ったりリスク受容の判断を行ったりする必要があります。

二つ目はセキュリティ診断とは異なり、開発者自身が検出された脆弱性の過検知判断や影響判断・優先度判断が必要になるため、一時的に開発者の負荷が高まることがあります。しかし、ASTツールで検出できる脆弱性は手動のセキュリティ診断よりも開発工程の早い段階で検出が可能なため、継続してASTによるセキュリティテストをすることでシフトレフト効果により脆弱性の修正コストの削減や開発スケジュールの短縮につながることが期待できます。また、継続的にASTツールによるセキュリティテストを行い脆弱性の改善を行うことで、システムに存在する脆弱性が減少し、脆弱性対応コストが減少していくことが期待できます。

三つ目は、一つのセキュリティテストツールで脆弱性を網羅的に検出することが不可能な点です。前節で示したようにASTツールごとに検査原理が異なることにより、検査可能な機能や検出可能な脆弱性が異なります。そのため、それぞれのツールの特性を理解し、自社の開発体制やリスク許容度に合わせて最適なアプリケーションセキュリティテストを組み合わせて、開発プロセス全体で継続的にセキュリティレベルを向上させていく必要があります。

最適なアプリケーションセキュリティテストは？

それでは自社のプロダクトや開発状況に最適なアプリケーションセキュリティテストとして何を実施すればよいでしょうか？

上記で整理したようにASTツールと手動診断の比較により、各ASTツールと手動診断は、検査タイミングや検査可能脆弱性、検査精度、脆弱性の修正容易さなど得意・不得意がそれぞれ異なりますが、各種テスト手法がそれぞれ適しているケース例を以下の表に示します。

セキュリティテスト種別	導入に適しているケース例
SAST	主にコーディングフェーズで検査実施できるため、シフトレフトによる効果を重視する場合ソースコードさえあれば検査実施できるため、検査実施に関する開発者負担を高めたくない場合ハードコーディングやIaCの設定ミスなどソースコードを対象にしたセキュリティテストで無いと検出できない脆弱性を検査したい場合
IAST	過検知が非常に少ないため、過検知判断の負担を減らしたい場合機能テスト・UIテストと同時に実施できるため、開発者への検査実施負担を軽減したい場合
DAST	最終的な実行アプリに対して検査を行うため、他のツールでは検出できない暗号化通信に関する脆弱性やサーバー側の設定ミスなどを検査したい場合本番リリース前の最終的なアプリに対してセキュリティテストを実施したい場合他ツールよりも多くの脆弱性を発見したい場合
手動セキュリティ診断	網羅的な脆弱性検出を行いたい場合（特に危険度の高いアプリケーションロジックや認証認可の脆弱性を検査したい場合）個人情報や金銭処理を扱う高リスクなシステムなど、より高いセキュリティ品質が求められる場合開発者への脆弱性の過検知判断を含むトリアージの負担を無くしたい場合セキュリティ専門家に相談しながら進めたい場合

しかし、上記はAST種別ごとの特徴であるため、同じ分類のASTの中においても製品やサービスにより特徴が異なる場合があるため注意が必要です。例えば、同じSASTツールの中でもツールによって得意な言語があったり、同じDASTツールの中でも得意なアプリケーション特性があったり、同じ分類のASTツールにおいても自社の状況に適したツールが存在します。また、各社ごとにアプリケーションの機能や保有している情報資産の重要度、利用ユーザ種別、リスク許容度、予算、開発期間などに応じて最適なアプリケーションセキュリティテストの組み合わせは異なります。

当社の SEC Team Servicesでは、お客様の課題を丁寧にヒアリングし、最適なセキュリティ戦略の策定を支援しています。また、当社ではセキュリティコンサルタントによるセキュリティ診断やASTツール導入支援も行っています。現状の課題分析から最適なツールの導入、専門家によるセキュリティ診断までワンストップでご支援可能ですので、まずはお気軽にご相談ください。

セキュリティ診断：https://www.nri-secure.co.jp/service/assessment

DevSecOps実行支援サービス：https://www.nri-secure.co.jp/service/consulting/devsecops