ガートナー ジャパン
メインメニュー ホーム リサーチ コンサルティング ベンチマーク エグゼクティブ プログラム イベント 会社情報 メインメニュー
SAMPLE RESEARCH

サンプル・リサーチ

イメージ アプリケーション・セキュリティ・テストの重要トレンド
インフラストラクチャ (INF)/INF-12-52
Research Note
J. Feiman, N. MacDonald
掲載日:2013年6月11日/発行日:2012年10月10日

本リサーチ分析レポートのテーマに関心をお持ちの方は、2013年7月1日(月)・2日(火)に開催する「ガートナー セキュリティ&リスク・マネジメント サミット 2013 | 今改めて考える、未知の脅威をいかに想定し対策を練るか」 のページを是非ご覧ください。
本サミットでは、クラウドやモバイルに焦点を当て、企業が行うべきセキュリティ対策やリスク・マネジメントを、グローバルのトレンドも見据えつつ提言する。
(イベント終了後も開催実績としてご覧いただけます)

 

セキュリティ/アプリケーション担当マネージャーは、アプリケーション・セキュリティ保護計画とテクノロジの選定の際には、本リサーチノートで定義する重要トレンドを参考にされたい。


要約

セキュリティ/アプリケーション担当のマネージャーおよびプロフェッショナルが、アプリケーション・セキュリティに関する重要トレンドを明確に理解すれば、アプリケーション脆弱性検出/保護テクノロジのポートフォリオとプロセスを開発し、進化させる上で役立つ。


主要な所見

    ● アプリケーション・セキュリティ市場は、エンタプライズ・セキュリティ・インテリジェンス (ESI) の実現に向けて進化している。

    ● 静的アプリケーション・セキュリティ・テスト (SAST) と動的アプリケーション・セキュリティ・テスト (DAST) の組み合わせは、例外ではなく標準になっている。

    ● サービスとしてのアプリケーション・セキュリティ・テストは、主流のデリバリ・モデルに進化している。

    ● クラウド対応インタフェース、モバイル・アプリケーション、リッチ・インターネット・アプリケーション (RIA)、および動的プログラミング言語が新たな優先事項になっている。

    ● ツールだけではソフトウェア・ライフサイクル (SLC) プロセスの基本問題を解決できない。そのためIT部門では、セキュアなSLCプロセスに重点を置く傾向を強めている。


推奨事項

●ESIを採用する。ESIを実現するテクノロジとベンダーを選定する。

● アプリケーション・セキュリティ・ベンダーの評価に当たっては、SASTとDASTを組み合わせて実行する能力を重視する。

● テスト・サービス・プロバイダーのクラウド対応インタフェース、モバイル・アプリケーション、RIA、動的プログラミング言語のテスト能力を差別化要素として評価する。

● IT部門 (およびアウトソーシング/サービスとしてのソフトウェア [SaaS]/クラウド/商用ソフトウェア・ベンダー) が提供するアプリケーションについて、静的/動的手法を併用したテストを実施済みであるという証拠の提出を要求する。

● セキュアなアプリケーションを開発するために必要となるセキュリティ開発ライフサイクル・プロセスの変更を見過ごしてはならない。


目次

戦略的プランニングの仮説事項

分析
 ESIの採用
 クラウド対応インタフェース、モバイル・アプリケーション、RIAが新たな優先事項になっている
 サービスとしてのセキュリティ・テストとクラウド・デリバリへの進化
 アプリケーション (アウトソース、パッケージ、クラウド) にSAST/DASTを適用して、サードパーティによる独立したテストとコンプライアンス検証を行う
 セキュリティ/品質検査テクノロジ・ソリューションの組み合わせ
 新たなアプリケーション・セキュリティ保護機能
 静的なバイナリ・コード/バイト・コード分析のサポート拡大
 動的プログラミング言語分析の新たなサポート
 情報セキュリティ部門が独自に実施するテスト確認

推奨リサーチ


戦略的プランニングの仮説事項

● 2012年までに、大手SAST/DASTベンダーはESIの実現を戦略目標に位置付ける。

● 2015年までに、企業の60%以上がアプリケーション開発プロセスにSASTソリューションを採用する。

● 2015年までに、企業の75%以上がアプリケーション開発プロセスにDASTソリューションを採用する。

● 2015年までに、企業の70%以上がアウトソーシング/SaaS/クラウド/商用ソフトウェア・ベンダーに対して、SAST/DASTテストを実施した証拠の提出を要求するようになる。

分析

以下に示す新たな重要トレンドの出現と、既に確認済みのトレンドのさらなる進化を、ガートナーでは過去18カ月以上にわたって確認している (推奨リサーチ参照)。


ESIの採用

SAST/DASTベンダーの間では、アプリケーション・セキュリティ市場がESIの実現に向けて進化するとの認識が生まれている (「Prepare for the Emergence of Enterprise Security Intelligence」参照)。ESIは、「セキュリティ・インテリジェンス」を1つの「明示的な成果物」と見なし、企業のITセキュリティ/リスク管理プログラムにおける戦略的セキュリティ目標の1つに位置付ける概念である。ESIの目的は、セキュリティ検出/保護機能の精度の向上、範囲の拡大、セキュリティ/リスク管理の最適化を実現することにある。


ESIを可能にするには、これまで縦割り式に孤立していたテクノロジの相互作用と、情報の統合/相関付けという2つの重要な要素が前提となる。異なるセキュリティ・テクノロジの相互作用は、「セキュリティ検出/保護の精度の向上と範囲の拡大」と、ビジネス・コンテキスト・データとの統合と相関付けに使用するセキュリティ情報の精度の向上および範囲の拡大を実現することを目的とする。この2つの目的を組み合わせると、「最適なセキュリティ/リスク管理」を実現する「コンテキスト評価」が可能になる。

ESIの採用は、アプリケーション・セキュリティ・テスト・サービスの進化に以下の2つの大きな影響をもたらす。

● SAST/DASTの相互作用:ESIという概念の基本要素の1つは、異なるテクノロジの相互作用である。SAST/DASTテクノロジ/サービスを (直接または提携を通じて間接的に) 提供する大手アプリケーション・セキュリティ・ソリューション・ベンダーがこの機能を提供していることを、ガートナーでは過去18カ月間にわたって確認している。先進性の高いソリューションは、SAST/DASTテクノロジと後続の相関結果分析の相互作用を実現している。これら2つのテスト・テクノロジの相互作用は、いくつかの点で重要な優位性を実現している。つまり、SAST/DASTテクノロジを併用する場合は、それぞれ単独で使用した場合よりも多くのSLCフェーズ (プログラミング、テスト、運用) を分析できる。さらに、一方のテクノロジで明らかになった脆弱性を他方のテクノロジで確認する、または誤りであると証明することができるため、テクノロジを個別に使用した場合に発生する誤検出や検出漏れが減少し、その結果として検出精度が向上することも重要なポイントである (「Application Security Technologies Enable Enterprise Security Intelligence」参照)。

セキュリティ情報とコンテキスト情報の統合と相関付け:SAST/DASTテクノロジが収集したセキュリティ分析の結果と、テスト対象アプリケーションのビジネス/コンプライアンス/知的資産に関する特性などのコンテキスト情報 (「The Future of Information Security Is Context Aware and Adaptive」参照) は永続的なリポジトリに保存し、コンテキスト依存リスク評価と最適なリスク管理を目的とした検索要求や、そうした評価に基づくビジネス上の意思決定のための検索要求に対応できるようにすべきである。

今後、ベンダーはアイデンティティ/アクセス管理 (IAM)、ネットワーク・セキュリティ、データベース・セキュリティといった、他のセキュリティ・テクノロジから入手したセキュリティ情報を追加できるようにするとガートナーは予想している。セキュリティ情報/イベント管理 (SIEM) テクノロジは、多様なソース (ネットワーク、IAM、エンドポイント保護など) を網羅する各種のセキュリティ・スキャナ/モニタから入手したセキュリティ情報を収集する上で重要な役割を担うことになる。

クラウド対応インタフェース、モバイル・アプリケーション、RIAが新たな優先事項になっている
次世代アプリケーションの開発に影響するトレンドは複数存在し、これらはやがてアプリケーション・セキュリティ・テストのベンダーに要求される能力に直接影響するようになる。その1つ目は、Web対応アプリケーションへのシフトに関連したRIAインタフェースへのシフトである。Ajaxを介したJavaScript、Flash、Flex、Silverlight、HTML5の広範な利用は、いずれも開発におけるこうしたシフトの例である。RIAは、もっぱらWebサーバ側からアプリケーションをテストする傾向が強い従来のアプリケーション・セキュリティ・テスト・ツールに疑問を投げかけるものである。RIAではアプリケーション・ロジックのクライアント側もテストしなければならないため、クライアント側のJavaScript、Flash、Flex、Silverlightなどの分析とテストを行うことになる。多くのDASTツールは、クライアント側コードをうまくテストできず、正しく分析するためにはクライアント側コードの静的な分析を行う必要がある。このことは、DAST/SASTのハイブリッド型テストに優位性を主張するもう1つの根拠となっている。

2つ目は、iPhone、iPad、Android、Windows Phone 7 (WP7) といった新興モバイル・プラットフォーム上でネイティブに稼働するモバイル・アプリケーションへのシフトである。これらのアプリケーションを正しくテストするためには、各モバイル・プラットフォーム上で使用する言語とフレームワークをテストできるよう明示的に設計されたSASTツールが必要になる。例えば、WP7の場合はSilverlightを明示的にテストする機能が、Apple iOSの場合はObjective-Cをテストする機能が必要である。バイナリ・テストでは、独自に必要になる言語のサポートに加え、モバイル・デバイスに採用されたチップセット (通常はARMベースのプロセッサ) をサポートする必要がある。

3つ目として、クラウド対応型のサービスとリソースを利用する方向へのシフトにより、アプリケーション・セキュリティ・テスト・ツールを以下の2つの方向に進化させることが必要になる。

● クラウド専用の言語とフレームワークを使用して、特定のクラウド・プラットフォーム用に開発されたアプリケーションをテストする機能をサポートする。例えば、Force.comで採用されている言語であるApexや、Microsoft Windows Azureで採用されている.NETのバリアントをテストする能力が挙げられる。

● クラウド対応型サービスと接続し、それを利用できるようにするXMLベースのAPIをテストする機能をサポートする。これを実現するには、クラウド対応型ベンダーのAPI構成を明確に把握し、それらのAPIの適正な使用方法を理解することが必要になる。

サービスとしてのセキュリティ・テストとクラウド・デリバリへの進化
企業にとって、サービスとしてのセキュリティ・テストには、先行投資コストの削減および限られた社内リソースの活用を可能にする方法の1つとして、多くのメリットがあるとガートナーでは考えている。サービスとしてのテストは、アプリケーション・セキュリティ市場にますます大きな影響を与えている。また、SASTベンダーやDASTベンダーの製品およびサービスを好んで利用する企業からガートナーに寄せられるコメントも増えている。例えば、機密性の高いアプリケーションはSAST製品やDAST製品を使用してオンプレミスでテストし、機密性の低いアプリケーションはSAST/DASTサービスを利用してテストするという事例や、展開済みアプリケーションはサービスを利用してテストし、開発中のアプリケーションはオンプレミス型のSAST/DAST製品を使用してテストするという事例である。

クラウド/サービスとしてのセキュリティ・ソリューションは、多くの理由で企業に訴求力を持つ。

● 設備投資を削減できる。これは、自社でハードウェアとソフトウェアを購入して保守する代わりに、それぞれハードウェアとソフトウェアを所有するクラウドSAST/DASTベンダーのサービスを利用するためである。

● クラウドからSAST/DASTサービス (開発中の社内アプリケーションや、社内のIT部門が自社運用しているアプリケーションをテストするもの) をそれぞれ利用できるようになれば、人材 (アプリケーション・セキュリティ・テスト担当者) の採用、トレーニング、管理に要するコストを削減できる。

● もう1つのコスト削減機能は、クラウド・ベンダーに期待される従量課金制の考え方である。つまり、企業顧客がサービスを利用した分だけ料金を支払う仕組みである。これにより、大企業ばかりでなく、自社でテクノロジ製品を購入する余裕はないが、個別のサービス料金は支払うことができるという中堅・中小企業も、クラウドを利用できるようになる。

● クラウドを利用すると、新サービスなどを採用する際の障害が低減する。企業は、大規模サービスを契約する前に少額の料金でテクノロジ・サービスを試用することができる。

● クラウドを利用すると、地理的に分散している拠点間の橋渡しをすることもできる。

● テストが済んでいない大量の展開済みアプリケーションを素早く処理する必要があることも、社外のサービス/クラウド・プロバイダーを利用する理由となっている。

● SAST/DASTサービス・プロバイダーは、自社サービスの一環としてスキャン結果を専門家がフィルタリングするサービスを自動テストに追加して、テクノロジに関連する誤検出を減少させると予想される。

ただし、クラウド対応型モデルを採用したアプリケーション・セキュリティ・サービス (SAST/DASTを含む) は、以下に示すいくつかの課題をもたらす。

● サービス・プロバイダーがソースコードやバイナリ・コードにアクセスすること (サービスとしてのSASTの場合) や、社内アプリケーションの脆弱性を知ってしまうことへの懸念がある。

● 脆弱性の検出が行われる場所とそれらの解消が行われる場所にギャップがある。例えば、検出はサービスとしてのSASTやDASTで行う一方、解消 (ソフトウェア修正) はオンサイトのプログラマーが実施する必要がある。

● 検出はクラウドのスペシャリストが担当する一方、修正は社内スタッフや請負業者が担当するという組織面のギャップも生じる。

● 検出しても、修正しなければ意味がない。したがって、ギャップを埋める作業が重要になる。企業側とクラウド・ベンダー側でギャップを埋めるプロセスの管理を定義し、確立すべきである。ただし、企業とクラウド・ベンダーはいずれも検出/修正プロセス全体に対して責任を負うものではない。したがって両者の作業範囲を分ける境界線の定義、サービス・レベル合意 (SLA) の作成、フィードバックと協働が必要不可欠である。企業とクラウド・ベンダーは、プロセスの詳細 (例えば、クラウド・ベンダーが毎月末などのスケジュールに従ってSAST/DASTテストを実施するのか、それとも新規開発アプリケーションの次期バージョンの準備が整い次第、SAST/DASTテストを随時実施するのか) を取り決めるべきである。

● クラウドでのプロセスとオンプレミスでのプロセスを、双方向で統合すべきである。例えば、企業側で新たにプログラミングしたアプリケーション・モジュールが完成すると、自動的にクラウドSAST/DASTベンダーによるSAST/DASTテストが実施される。このクラウド・ベンダーが実施したセキュリティ・テストの結果は、オンプレミスのアクセス可能なバグ追跡システムに取り込まれ、オンサイトのスペシャリストがその情報に基づいて修正作業を引き受け、実施する。この統合プロセスは、自動化され透過性が確保されることが望ましい。

アプリケーション (アウトソース、パッケージ、クラウド) にSAST/DASTを適用して、サードパーティによる独立したテストとコンプライアンス検証を行う

企業は、クラウド・ベンダー (クラウド・セキュリティ・ベンダーを含む) を調査してから選定すべきである。こうした調査を妨げるものとしては、以下の例がある。

● 自社からコードを確認できないクラウド・ソフトウェア・システムを、どのようにテストするかという問題。

● ベンダーがコードへのアクセスを制限している場合、クラウド・システムをどのようにテストするかという問題。システムのプログラム・コードは、ベンダーにとって最も重要な知的財産 (IP) である。したがって、ベンダーがコードの検査を目的とした自社コードへのアクセス権の付与に消極的になるのは当然である。

● クラウド・ベンダーのセキュリティ保護策をテストする上で必要となるセキュリティ専門知識を欠く企業が多い現状にあって、こうしたテストをどのように実施するかという問題。

クラウド・ベンダーが提供するサービスは、ベンダーのインフラストラクチャとサービスを対象とする独立したセキュリティ・テストを通して信頼を得る場合が多い。

解決策の1つは、クラウド・ベンダーの調査をサードパーティ・セキュリティ・ベンダーに委託することである。この場合、企業、クラウド・ベンダー、サードパーティ・ベンダーが交渉を行って3者間契約を締結することになる。この契約に従ってクラウド・ベンダーがサードパーティ・ベンダーによる調査に同意し、調査が行われ、調査結果のレポートが企業に提出される。企業は、このレポートに基づいてクラウド・ベンダーのセキュリティ対策が満足できるものか否かを判断する。

いずれは、調査・審査機関による認定がサードパーティ・テストに代わる有望な選択肢となったり、サードパーティ・テストを補完するものとなったりすると考えられる。

アプリケーションのセキュリティをテストするベンダーは、アプリケーション (アウトソース、パッケージ、クラウド) のサードパーティによる独立したテスト/コンプライアンス調査において、重要な役割を担うようになる。

セキュリティ/品質検査テクノロジ・ソリューションの組み合わせ
ベンダーは、品質検査とセキュリティ・テストに関してアプリケーション開発者に別個のツールの使用を要求する (そして他のベンダーに別個のツールの提供を要求する) のではなく、両方の要件に対応するソリューションを提供するか、または提携を通じてこうしたソリューションを実現する機会が存在すると捉えるべきである。アプリケーション品質検査を専門としてきたベンダーの一部は、アプリケーション・セキュリティ・テストをテスト・ツールのポートフォリオに追加している。こうしたベンダーの一部は、SAST/DASTベンダーを買収し、品質検査/セキュリティ・ポートフォリオを顧客に提供すべく作業を進めている。

それ以外にも、(主力の品質検査機能に追加する形で) セキュリティ・テスト機能を用意しているアプリケーション品質検査ベンダーは、品質検査/セキュリティ・テスト機能を組み合わせたポートフォリオを提供するためにSAST専業ベンダーとの提携に踏み切っている。品質/セキュリティ・テスト機能のテクノロジ統合レベルは、マーケティングに等しいもの (2種類の製品をまとめて販売しているだけ) から、品質/セキュリティ・テストの結果を同一リポジトリに収め、相関付けて分析するテクノロジ統合に至る。

SAST/DASTをSLCプラットフォームに統合:アプリケーション・セキュリティ・テストは、SLCプロセス内に位置付けるのが妥当である。SLCプロセスでは、プログラミング・フェーズでアプリケーション開発プロフェッショナルがSAST/DASTツールの助けを借りて、可能な限り早期にセキュリティ脆弱性を検出し、修正する。次にビルド/テスト・フェーズに移行し、さらには運用プロフェッショナルもテストに関与できる本稼働/運用フェーズを経る。大半の企業は、SAST/DAST機能をSLCプラットフォームに緊密に統合する方を好む。ごくわずかなコストでSAST/DAST機能をSLCプラットフォームに組み込むことができる場合に、この傾向は特に顕著である。SaaSやクラウドを通じてSAST/DAST機能を調達している場合でも、こうした機能を修正目的でSLCプロセスやSLCプラットフォームに緊密に統合することが望ましい。

SLCにおけるSAST/DASTソリューションの採用を成功させるには、開発プロセスを変更するとともに、開発者の考え方を改める必要がある。多くの企業はセキュリティ・テスト・ツールを既に入手しており、こうしたツールをSLCプラットフォームに組み込む作業への支援と、プロセス設計 (セキュアなアプリケーション開発の重要性を強調する評価基準を含む) を見直す作業への支援を求めている。

新たなアプリケーション・セキュリティ保護機能
アプリケーションのセキュリティをテストするベンダーは、当初は、悪用される可能性のあるセキュリティ脆弱性を検出するテクノロジに注力していた。最近は、アプリケーション保護テクノロジにも注力している。

保護モデルの1つは、ソフトウェア・アプリケーション・ファイアウォール (SAF) である。SAFをアプリケーションのランタイム環境内にインストールすると、アプリケーション内の最も重要なポイント (SQLインジェクション攻撃により悪用される可能性のあるデータベース照会など) に対するインバウンド・アクセスをリアルタイムで分析できる。分析の結果として攻撃が確認された場合、SAFはアプリケーションのオーナーにアラートを送信するか、または悪意あるセッションを打ち切るなどの方法によって個別の攻撃に対処することができる。

もう1つの保護モデルは、アプリケーションのハードニングとシールディングを実行するテクノロジを用いるものである。これらのテクノロジは、アプリケーションを本稼働環境に移行する前に、アプリケーションのバイト・コードやバイナリ・コードに特殊な「保護」コードを挿入する。保護コードは、アプリケーションの実行時に、アプリケーション・コードを変更する試み (ライセンス保護を解除したり、オーナーの「ウォーターマーク」情報を消去したりするなど) を検出する。これらを検出した場合、保護コードは (アプリケーションがネットワークに対応していれば) アプリケーションのオーナーに報告し、悪意あるセッションの打ち切りや当該アプリケーションの破壊を試みる。

アプリケーション保護テクノロジはアプリケーションに近似しているため、アプリケーションのロジックと弱点を熟知している。したがってこれらのテクノロジは、ネットワーク・ベースのセキュリティ保護テクノロジにはまねのできない方法で、アプリケーションのセキュリティをより適切に向上させる。

静的なバイナリ・コード/バイト・コード分析のサポート拡大
パッケージ・アプリケーションなどのプログラムや、インターネットを介して利用契約しているソフトウェア・サービスのほか、セキュリティ・テスト時にソースコードは参照できないがバイナリ・コードとバイト・コードは参照可能なダイナミック・リンク・ライブラリ (DLL) を呼び出すソフトウェア・アーキテクチャでは、バイナリ・コードとバイト・コードの脆弱性を検出することが重要である。また、バイナリ・コードとバイト・コードの分析時は、ソースコードが参照可能であっても、コンパイル済みコードを分析することになるため、特定のライブラリやプラットフォームに関連する問題も発見できる。

企業は、バイナリ分析ツールのベンダーを評価する際に、次のことを考慮すべきである。すなわち、C/C++などの低水準言語のバイナリ分析を行う際は、基礎となるCPU命令セット、OS、アプリケーションの開発とコンパイルに使用した言語の3点に関する知識と明示的なサポートが必要である。例えば、x86チップセット上で稼働するWindows上で動作するC++アプリケーションをサポートしているベンダーでも、x86チップセット上で稼働するLinux上で動作するC++アプリケーションはサポートしていないことがある。

Javaのような高水準言語の場合、OSとチップセットは理論上は中立であるが、Java仮想マシン (JVM) の実装については明示的なサポートを要するほど、それぞれに異なっている。例えば、IBMのJavaベース・アプリケーションをサポートしていてもOracleのJavaベース・アプリケーションはサポートしていないベンダーや、Windows上でIBMのJVMをサポートしていてもAIX上ではサポートしていないベンダーが存在する可能性がある。脆弱性テストの完全性と正確性を高める目的でバイト・コードとバイナリ・コードの分析を追加するベンダーが増加していることをガートナーでは確認している。

動的プログラミング言語分析の新たなサポート
Hypertext Preprocessor (PHP)、Python、Rubyといった動的プログラミング言語が、主流のIT活動に採用されつつある。動的プログラミング言語は、市場をリードする既存のテクノロジにはまねのできない独自の機能を多数備えている (「Dynamic Programming Languages Will Be Critical to the Success of Many Next-Generation AD Efforts」参照)。この差別化要素を強化するテクノロジ面の要因は複数存在するが、次の2点が特に重要である。

● 静的な言語は、コンパイル時にメモリを特定のデータ・タイプ (整数のみや浮動小数点数のみなど) に結び付ける。動的な言語は、これを実行時に行う。

● 動的な言語は堅牢な実行「エンジン」を搭載しているため、アプリケーション側でデータを実行コードとして評価し、オブジェクトの挙動を変更し、組み込まれている内部機能を実行時に拡張できる。

SASTベンダーは、大半のアプリケーションの開発に利用されていることを理由として、これまでC/C++、Java、C#、VB.NETといった静的プログラミング言語の分析に注力してきた。しかし動的プログラミング言語の採用が増えているため、大手SASTベンダーは動的言語のセキュリティ分析に対応すべくテクノロジを進化させる作業に着手している。

動的言語の分析には、テクノロジ面の問題に加え、社内文化面での課題も存在する。全社統括IT部門のコントロールが及ばないビジネス部門内のアプリケーション開発者が、動的プログラミング言語を利用する事例が増加していることも、動的言語のセキュリティ・テストの阻害要因の1つである。ビジネス部門内の開発者にSASTに関する厳格なプロセスと手法を採用させることも、付加的な障害となる。

動的言語のテストには課題があるため、SAST/DASTの両手法を組み合わせて使用することによって最適な分析が可能になると、ガートナーは見込んでいる。分析対象言語の広範性と正確性は、言語の採用ペースに合わせて少しずつ拡大する。

情報セキュリティ部門が独自に実施するテスト確認
開発プロセスを変更してセキュリティ・テストを盛り込んだ場合でも、情報セキュリティ部門は、実施されるはずのテストが実際に行われていることを独自に確認する必要があるため、アプリケーション・セキュリティ・テスト・ツールにさまざまな影響が生じる。ローエンドでは、ネットワーク脆弱性評価に対応する一部のソリューションが、主力のネットワーク/脆弱性評価に加えて「過不足のない」基本DAST機能をサポートすべく進化している。SAST/DASTソリューション・ベンダーも、テストを独自に確認する際に利用できるソリューションを開発することによって、こうしたニーズに対応している。このソリューションでは、情報セキュリティ専用に設計されたツールを利用するか、またはポリシーとSAST/DASTソリューション内からの報告内容に関する厳密な職務の分掌を実現する。独立性の高い確認方法へのニーズにより、アプリケーション・セキュリティの独立した評価を行う分かりやすい手段である、サービスとしてのSAST/DASTテストの利用も加速する。


    推奨リサーチ
    ・ 「Prepare for the Emergence of Enterprise Security Intelligence」
    ・ 「Application Security Technologies Enable Enterprise Security Intelligence」
    ・ 「Using Context to Design Applications」
    ・ 「Magic Quadrant for Static Application Security Testing」
    ・ 「Dynamic Programming Languages Will Be Critical to the Success of Many Next-Generation AD Efforts」

    (監訳:礒田 優一)
INF: INF-12-52







※本レポートの無断転載を禁じます。

←INDEXに戻る

 

gartner.com
TOP OF PAGE
Copyright