脆弱性検出ツール「IAST」が「DevSecOps」に欠かせないのはなぜか？：これで分かる「DevSecOps」の課題と解決【第2回】
アプリケーション開発時のセキュリティツールとして、脆弱性を検出する「IAST」がある。セキュリティを取り入れたアプリケーション開発手法「DevSecOps」の具現化に役立つという、IASTの特徴とは。
Webアプリケーションを安全に開発する手法として、「開発」「運用」「セキュリティ」を密接に連携させる「DevSecOps」が広がっています。第1回「『SAST』『DAST』『SCA』がDevSecOpsに向かない“なるほどの理由” 」は、代表的な脆弱（ぜいじゃく）性検出ツール3種の特徴と、それらがDevSecOpsに不向きなことを説明しました。第2回となる本稿は、DevSecOpsに適した脆弱性検出ツール「IAST」（インタラクティブアプリケーションセキュリティテスト）に焦点を当てます。
IASTは、アプリケーション内で脆弱性情報を収集する「IASTエージェント」（センサー）と、エージェントからの情報を解析する「IASTサーバ」で構成されるツールで、アプリケーションの単体テストや結合テストなどの機能テストの実行中に、脆弱性を自動的に検出してアラートを出します。第1回で取り上げた「SAST」（静的アプリケーションセキュリティテスト）と「DAST」（動的アプリケーションセキュリティテスト）の制限に対処しつつ、両者の利点を組み合わせて、さらに進化させています。
アプリケーションの稼働中に動作を監視する「インストルメンテーション」を可能にすることが、IASTの主な役割です。IASTを機能させるには、アプリケーションサーバにIASTエージェントを埋め込む必要があります。IASTエージェントは、アプリケーション内のデータ処理の流れ（データフロー）を追跡するためのプログラムです。動作中のアプリケーションが内包するフレームワーク（アプリケーションを機能させるソフトウェア）やデータフローを詳細に解析し、アプリケーションの脆弱性を検出します。
SAST、DASTの課題を解決 IASTがDevSecOpsに不可欠な理由とは？
IASTエージェントをアプリケーションサーバに組み込んでおけば、Webアプリケーションの機能テストのタイミングで、IASTエージェントが自動的に、Webアプリケーションの内部で発生した複数の「脆弱性の兆候」を確認します。具体的には
- HTTPリクエストのパラメータ
- 通信で発生した文字列やその処理結果
- Webアプリケーションが発行したSQL文
など、脆弱性の影響が現れやすい要素を精査して、脆弱性を自動的に検出することが可能です。脆弱性を自動検出するIASTを、「DevOps」（開発と運用の融合）における機能テストを自動化するツールと組み合わせることで、さらなる自動化が実現します。機能テストの自動化ツールの例には、UI（ユーザーインタフェース）テストツールやAPI（アプリケーションプログラミングインタフェース）テストツールがあります。
こうした自動化の結果、Webアプリケーション開発終了後に手動で実施するのは「2段階認証の設定」「cookieの有効期限」「アカウントロック機能の有無」など、脆弱性診断ツールでは検出が難しい要素の機能テストだけで済みます。これによりコストと時間の削減を図ることができるのです（図1）。
従来の脆弱性検出ツールの課題
SASTやDASTといった従来の脆弱性検出ツールは、脆弱性を検出できない「検出漏れ」や、実際は脆弱性ではないものを脆弱性として検出する「過検出」（False Positive）が大量に発生することがあります。検出された脆弱性候補の中から本当の脆弱性を見つけるには、ある程度のスキルを持ったセキュリティエンジニアがトリアージ（対処すべき脆弱性の特定）をしなければなりません。ソフトウェア開発ライフサイクル（SDLC）における「Webアプリケーションの開発終了時」に脆弱性診断をすると、開発のやり直しや手戻りが発生し、DevSecOpsに沿った高速な開発が難しくなります。
DASTは、数百パターンから数千パターンの疑似的な攻撃に対する、Webアプリケーションの応答を基に脆弱性を特定します。Webアプリケーションの実際の反応を確認するので、過検出数を抑えることはできます。ただし十分な攻撃パターンを用意できないと、検出漏れが発生しやすくなります。Webアプリケーション完成後に機能テストをするので、この段階で脆弱性を修正すれば、工程全体が長くなる可能性があります。
SASTは、ソースコードさえ準備できれば、スキャンによりソースコード全体を検査可能なので、脆弱性検出の網羅性は高くなる傾向があります。半面、Webアプリケーションの実際の動作を確認するわけではないので、ソースコードだけでは正常の処理かどうか不明確な場合に「脆弱性がある」と判断することがあります。そのため過検出が増える恐れがあるのです。過検出の検証はセキュリティエンジニアや開発者に負荷をかけることになり、脆弱性診断や開発にかかるコストと時間がますます増加します。
IASTとCI/CDパイプラインの親和性
IASTを活用すれば、CI/CDパイプライン（CI/CDにおける一連の処理を連携させ、自動化した処理群）内のWebアプリケーションの機能テストに脆弱性検出を組み込むことができます。
図2は、ソースコードリポジトリ（ソースコードの貯蔵庫）内のソースコードからビルド（実行可能ファイル生成）したアプリケーションを例に、IASTによる脆弱性診断の流れを説明しています。IASTエージェントはアプリケーションの脆弱性診断を実施して、その結果であるアプリケーション脆弱性情報をIASTサーバに集約します。IASTサーバは受け取った脆弱性情報の解析に加え、IASTエージェントが脆弱性診断を正しく実行したかどうかを判断します。開発者はIASTサーバから脆弱性情報を受け取って、アプリケーションのどこを修正すればよいのかを判断するという流れです。
CI/CDパイプライン内でIASTと、テストの実行や結果レポートの作成を自動化する「CI」ツールを連携させれば、開発者は脆弱性検出にかかる時間を削減できます。セキュリティエンジニアは、自動テストが順守すべきセキュリティポリシーをIASTサーバに設定可能です。違反が発生した場合は、CI/CDパイプラインを自動的に終了させることができます。
IAST活用による脆弱性対策の効率化
「高い脆弱性の検出精度」と「修復箇所に関する指摘の具体性」という、DASTとSAST両方の利点がIASTにはあります。Webアプリケーションの機能テストやUIテストで、脆弱性検出のテストカバレッジ（網羅率）を十分に確保できていれば、IASTによって脆弱性検出の精度と網羅性をさらに高めることができます。
上述の通りIASTは、Webアプリケーション内部で多角的に兆候を確認して、脆弱性の判断プロセスを複数回踏みます。脆弱性かどうかをより精緻に判断できるので、「疑わしいから取りあえず脆弱性だと判断する」ことが起こりにくくなり、過検出の発生を抑制できます。検出した脆弱性が本当に脆弱性かどうかを精査するにはスタックトレース（エラーが発生するまでの処理過程）を確認すれば済むので、手間はほとんどかかりません。
IASTは、機能テストを実施するエンジニアのスキルやツールの利用経験の有無に関係なく、Webアプリケーションの一般的な機能テストで脆弱性を検出可能です。ソースコードのどの部分に脆弱性があるのかといった詳細情報も提示します。開発者はこうしたIASTの修正ガイダンスに従って脆弱性を修正できます。
脆弱性検出をIASTによって自動化することで、開発者はセキュリティエンジニアの支援を受けることなく、開発段階でセキュアコーディングがしやすくなります。IASTはアプリケーション内の全てのデータフローを追跡するので、Webアプリケーションへの値の入力時におけるバリデーション（入力値の妥当性検証）や、出力時におけるサニタイズ（無害化）といった処理を自動で検出し、検査することもできます。
IASTは、さまざまなプログラミング言語やフレームワークの特性を基に、HTTPリクエストや文字列変換、SQLクエリなど複数の兆候を確認することで、脆弱性検出から修正までの自動化を実現しています。その自動化により比較的容易にSDLCの効率化やコスト削減、DevSecOpsの実現が図れます。こうしたメリットを受けて、日本でも大手企業を中心にIASTの大規模な展開が始まっています。
第3回は、Webアプリケーションのオープンソースソフトウェアの脆弱性診断対策に重きを置いたセキュリティテスト手段である「SCA」（ソフトウェア構成分析）ツールを紹介します。
著者紹介
田中一成（たなか・かずなり） Contrast Security Japan
国内システムインテグレーターや外資系企業で営業を経験した後、ArcSight（現Micro Focus）、41st Parameter（現Experian）、SundaySkyなど、主に米国スタートアップのカントリーマネジャーとして6社の日本オフィスを立ち上げ、成長させた。IT業界で約30年の経験があり、ハードウェア、ソフトウェア、クラウド、セキュリティ、データベース、デジタルマーケティングなどさまざまな分野に精通している。Contrast Security日本オフィスの立ち上げに尽力。
Copyright © ITmedia, Inc. All Rights Reserved.