Webアプリやモバイルアプリ、各種業務アプリなど、企業が開発するアプリケーションは、平均すると26.7件の脆弱性を内包しています*。個々のアプリは多機能化し、サイズも肥大化していることから、さほど意外な数字ではないかもしれません。
ここで注視したいのは、この数字が2000年当時と変わっていないことです。ソフトウェア開発の技術は進歩していますが、ずっと同じ課題を抱えているのはなぜでしょう？ 今回は開発とアプリケーションセキュリティ（AppSec）、そしてテストの現状について考えてみます。
*“2019データBreach Investigations Report,” Verizon, April 2019.
利用環境の拡大に比例するセキュリティリスク
アプリケーション開発の工程では、要求仕様に応じた機能の実現と同時に、データ保護やコードの流出など、安全対策への視点が欠かせません。開発段階でコードに入り込む脆弱性に加えて、稼動後に見つかる欠陥を除去することも開発部門の責務の一つです。
現在のアプリケーションは、インターネットが浸透する20年前に比べると、無線を含め多様なネットワークからの接続、そしてクラウドという新しい動作環境も加わりました。プログラムの多機能化とサイズの拡大、そして利用環境の拡張に比例して、侵害に結びつく隙が生ずるリスクも増加していることは否めません。
こうした環境で欠かせないのがAppSecのテスト。いろいろな要求仕様に応じて開発される業務アプリやWebアプリ、Web API、フレームワークなどのソフトウェアツールに対し、コーティングミスの検出、データの改ざん防止、ユーザー認証の強度、伝送路における暗号の強度といった視点から、動作を検証するテストとテストツールの重要度は増しています。
セキュリティテストはDevOpsと逆行？
アプリケーション開発のプロセスで、いま多くの企業で課題になっているのが、AppSecテストの実行が開発の足かせになってしまうという点です。
まず、セキュリティテスト以前の話ですが、システム開発の現場において、限られた期間と予算の範囲で急な仕様変更にも対応し、スムーズに開発を進めたい開発部門と、安定稼動と平易な操作性を維持したい運用部門の優先事項が乖離することは珍しくありません。
この課題の解消策として、「DevOps（デブオプス）」という考え方が浸透してきました。いまのところ明確な定義はありませんが、開発（Development）と運用（Operations）の両部門が連携して作業を進めるというコンセプトです。優先順位が対立しがちな両部門の思いをすり合わせ、システム構築の効率を挙げていくのがその狙いです。
DevOpsのサイクルを回していく上で、新たなハードルになるのがAppSecテストです。開発と運用部門の利害の不一致と同様、セキュリティの確保も開発担当者から見ると、納期までにシステムを稼動させる上での足かせになってしまうのです。
その要因の一つとして、セキュリティの専門性の高さがあるでしょう。セキュリティが他分野に比べ、特別に高度な知識が求められるというわけではないのですが、独特の理論と技術、用語も多く、一定の慣れは必要と感じているエンジニアも多いと思います。この状況では、脆弱性が発見できても、専門知識が要求されるセキュリティの課題に対し、開発者が単独で対処方法と優先順位を決めることは容易ではありません。
テストツールの機能と課題
ここから先は、目線を具体的なテスト方法まで落として考えてみましょう。いまのテストツールは細分化していますが、いずれのツールも大まかに分けると、以下の工程を対象にしたものです。
・静的テスト：開発段階でコードを分析・検証
手法：SAST（静的セキュリティ検査）
SCA（ソフトウェア構造分析）
・動的テスト：稼動時の攻撃を想定し動作した状態で分析・検証
手法：DAST（動的セキュリティ検査）
・統合型：静的テストと動的テストをハイブリッドで実施
手法：IAST（インタラクティブセキュリティ検査）
-SAST：Static Application Security Testing
-SCA ：Software Composition Analysis
-DAST：Dynamic Application Security Testing
-IAST：Interactive Application Security Testing
現状、開発者はそれぞれの段階で使うテストツールをインストールし、設定、工程管理、スケジュール調整、運用管理、対応を行なっていますが、比較的負荷が高いAppSecのテストツールはDevOpsを前提とした工程への組込みは困難という現実があります。また現在のツールの精度では誤検知が多く、調査に時間を費やすという課題も20年前からあまり改善はしていません。
エージェントでAppSecテストをシフト
DevOpsサイクルへのAppSecテストの注入が難しく、時間短縮のため重要なテストを後回しにするような状況では、脆弱性を抱えたまま本番リリースを迎えてしまうことになりかねません。DevOpsとセキュリティの間にあるギャップを埋めるには、AppSecもDevOpsに組み込むことです。
“静的テストと動的テストの完了後にAppSecテスト”
多くの企業と開発部門は、AppSecテストを後工程にするステップで実践してきましたが、このモデルはもはや時代遅れです。いまの手法は、AppSecテストを開発と同時に実行すること。それを実践するテクノロジーとして浸透しつつあるのが、“エージェント型テストツール”です。
エージェントは“代理人”“代行”などの意味を持つ単語ですが、ソフトウェアの分野では、一般に自律的に動作し、ある機能の起動、複数プロセスの連動、あるいは動作の監視や情報収集などの機能を持つソフトを示します。AppSecテストの領域では、指定されたポイントで、指定されたテストを自律的に実行する機能と考えていいでしょう。
センサーを要所へ自動配置
AppSecテストにおいて異常を検知するのは、プログラムの動作を観察するセンサーです。アプリケーションの起動時に、指定したアプリケーションコード内のポイント（ライブラリ、フレームワーク、アプリケーションサーバーを含む）に、エージェントが自動配置。脆弱性を突かれる可能性を検知すると、センサーが問題個所をマークし、不審な動きがあればブロックします。
リアルの空間で言えば、エージェントとセンサーの働きはビルの警備室に相当します。ビルの各所に据えつけたセンサーが見張り、不審な兆候があれば警備室にアラートを発信。もし万一、火災に直結するような危険度が高い動きがあれば、防火扉や消火器が作動。社屋の空間で起こり得るリスクから、企業の資産を守っています。
エージェントとセンサーも、アプリケーションが動作する環境全体を見張ります。例えば、攻撃者からリクエストが発生するコントローラー、セッションの確立、ビジネスロジックの動作などの局面で、それぞれHTTP要求、データの追跡、ロジックの構文解析の視点から検証（下図）。各フェーズで攻撃の兆候を検出し、安全な動作の維持を保証します。
AppSecプラットフォームを構成
安全対策を分断せずにDevOpsと一体化、かついろいろな角度から検証できるエージェント型テストツールは、「AppSecプラットフォーム」と表現できます。AppSecの共通基盤、プラットフォームとして機能するには、特に以下の要素が重視されます。
・セキュリティテストの自動化
プログラムの機能テストの実行と同時に、AppSecを検証するテストが自動的に動作。リアルタイムで脆弱性と脅威の影響度を特定できるため、DevOpsのサイクルを阻害しません。この機能は、すでに稼動しているアプリケーションに対しても有効化できます。
・脆弱性の検知と可視化
DevOpsとAppSecを並立した環境の構築は、すべてのプロセス（例：テスト、本番、開発サーバー）における可視化が前提です。エージェントが自動配置したセンサーは、Webアプリ、API、ライブラリ、フレームワークなど、企業内部にあるすべてのソフトウェアをリスト化・可視化し、24時間365日監視します。
・ポリシーベースのセキュリティ制御
他のテストツール、セキュリティ対策ソフトと同様、異常を検知した際の対処を、企業の運用ポリシーに応じた形に制御できる機能です。ポリシーベースの制御は、詳細なコンテキスト分析を元にしたアラート発信から、攻撃の拡散を防止するリアルタイムの修復まで幅広く対応できます。
・連携とレポート
セキュリティ情報のやり取りは、PDFベースのレポートに頼っている企業も多いのですが、AppSecプラットフォームからは、リアルタイムのアラートや各種レポートをその部署が常用している既存のツールと連携した形での出力ができます。
拡張性もプラットフォームの要件
セキュリティチームがコンプライアンスを意識した設定・運用を実施することで、プラットフォームの運用は、FISMA（連邦情報セキュリティマネジメント法）やNIST（米国国立標準技術研究所）、PCI DSS（決済カード業界が定めたセキュリティ基準）、OWASPなどのセキュリティ規約への準拠を実現します。
-FISMA：Federal Information Security Management Act
-NIST：National Institute of Science and Technology）
-PCI DSS：Payment Card Industry Data Security Standard）
-OWASP：Open Web Application Security Project）
DevOpsと一体化したプラットフォームとして稼動し続けるには、アプリケーションの機能更新、仕様変更、また新しい技術やOSS（Open Source Software）の適用への対応が必要で、拡張性も重要な要素とされています。この視点から見たポイントとして、以下の検査機能の精度に着目する必要があるでしょう。
・IAST（Interactive Application Security Testing：インタラクティブセキュリティ検査）
実稼働前の環境で実行され、カスタムコードとOSSライブラリの双方で、実行中のコードからデータを収集して脆弱性を検知します。比較的新しいテスト手法ですが、ソースコードに含まれる脆弱性の特定が容易、プログラムが動作する状態を検証するため誤検知が少ないなど、SASTとDASTの特性を併せ持つという利点があります。
・SCA（Software Composition Analysis：ソフトウェア構造分析）
ライブラリを分析し、潜在的な脆弱さを持ったサードパーティやオープンソースのコンポーネントを特定。現状、アプリケーションの84％は半分以上がオープンソースコードで構成されるため、この機能は特に重要です。
・RASP（Runtime Application Self-Protection：ランタイムアプリ自己分析）
実稼働の環境で実行されたクエリ（処理要求）に対して、アプリケーションの内部（カスタムコードとOSSライブラリ）で脆弱性が悪用されることはないかを検証。アプリケーションの前面に配置されるWAF（Web Application Firewall）より、保護機能は高いとされています。
開発とセキュリティの連動を
エージェント型テストツールの特長は、開発側の視点で見ると、コードの変更を要さずにセキュリティが改善できる点です。主要コンポーネントの働きにより、システム構築に携わるすべての部門に、テストと承認を繰り返す既存のプロセスのようなハードルは意識させず、より早く本番環境への移行ができます（下図）。
AppSecのセンサー機能の4つの主要コンポーネント（保護、分析、検証、防御）
テストの自動化によって、リアルタイムで脆弱性を分析できる“スピード”、実行中のアプリケーションを直接調査できる“正確さ”、複数のアプリケーションで並行して実行できる“拡張性”、そして“セキュリティエンジニアの負担軽減”、“業務コスト削減”といった効果が期待できます。
エージェント型テストツールによる開発とセキュリティの融合は、スピードと安全、コストダウンの並立という多くの企業にとっての共通課題を解消する、極めて有力なソリューションなのです。
