Contentsアプリケーション・セキュリティ・テストには時間がかかる複数のアプリケーション・セキュリティ・テスト・ツールから生成される膨大なテスト結果を理解する方法は?多くの組織は複数のアプリケーションを利用しており、大企業になると、数百もしくは数千のアプリケーションを開発・運用していることでしょう。各アプリケーションは、セキュリティ上の問題の解決、パフォーマンスの向上、新しい顧客要件への対応のために常に更新されており、その更新プロセスでアプリケーションのセキュリティの問題をテストすることが不可欠になっています。多くの組織では、リリース前にさまざまなアプリケーション・セキュリティ・テスト・ツールを使用してアプリケーションを分析します。そこで、各種アプリケーション・セキュリティ・テスト・ツールを使用した場合の課題について考えてみたいと思います。アプリケーション・セキュリティ・テストには時間がかかるアプリケーション・セキュリティは時間がかかる取り組みで、ソフトウェア開発ライフサイクル(SDLC)のさまざまな段階で実施されます。SDLCの早い段階から開始する静的アプリケーション・セキュリティ・テスト(SAST)では、アプリケーションのソースコードを検査して脆弱性を引き起こす可能性のある誤りを検出します。これによりアプリケーションの構築中にフィードバックを得られるため、長い目で見ると結果的に開発期間を短縮できます。コミット、ビルド、テストの各段階で独自開発のコードに潜む一般的な脆弱性を検出できます。コードベースでの一般的なSASTの実行にかかる時間を知りたいと思っても、漠然とした答えしか得られません。テストの実行時間はアプリケーションの規模と複雑さに依存します。スキャンにかかる時間はビルド時間の数倍になることを示す推定値もあります。次のスキャンの結果をマージし、組織およびアプリケーションの最優先課題に焦点を当てたテストを支援する機能はSASTツールによって異なります。生成される結果の数もアプリケーションの規模と複雑さに依存します。ソフトウェア・コンポジション解析(SCA)ツールもSDLCの早い段階で実行し、コードベース内のオープンソースを追跡および解析します。大部分のモダンアプリケーションにはオープンソースのコンポーネントが含まれており、他のソフトウェアと同様に、そのコンポーネントの中に脆弱性が潜んでいる可能性があります。オープンソース・セキュリティ&リスク分析(OSSRA)」レポートでは、2021年に監査されたコードベースの97%にオープンソース・コンポーネントが含まれており、過去2年間に開発活動やユーザーによる更新が行われていないオープンソース、運用上の懸念があるこれらのコンポーネントを使用しているコードは全体の88%に達します。SASTの評価対象は独自開発のコードのみであるため、SCAツールを実行することが不可欠なのです。SCAをSDLC全体に組み込むことで、オープンソースの定期的なスキャンを設定することができます。オープンソースを使用する場合、常に新しい脆弱性が公開あるいは発見される可能性があるため、アプリケーション内のオープンソースを可視化することが不可欠です。使用されるオープンソース・コンポーネント、アプリケーションの規模、コードベースの複雑さによって大きく変わり、脆弱性の公開自体が予測不可能であるため、発見される脆弱性の数を予測することは困難です。SDLCの後の段階のテスト/QA工程では、インタラクティブ・アプリケーション・セキュリティ・テスト(IAST)ソリューションを用いることで、Webアプリケーションの実行時の脆弱性に関連するセキュリティ・リスクを特定・管理できます。多くのIASTツールは、継続的インテグレーション(CI)/継続的デリバリー(CD)ツール(一般にCI/CDツールと呼ばれる)に統合され、開発者がコードを変更して再コンパイルし、アプリケーションを実行させて再テストすることで、すぐに結果を返すことができます。IASTツールをCI/CDに統合してプロセスの一部として組み込めば、機能テストにかかる時間が増えることはありません。実行状態でアプリケーションをテストする動的アプリケーション・セキュリティ・テスト(DAST)は、ソースコードをテストしないため、言語またはプラットフォームに依存しません。アプリケーションを外側から評価することで、他のテストツールで見落とされた間違いが見つかります。DASTはSDLCの後工程のテスト・運用フェーズで用いられます。アプリケーションが変更されるたび、継続的にアプリケーションをスキャンすることで、緊急の問題を特定して修正することができます。DASTツールを実行する頻度にかかわらず、実行状態でのアプリケーションの脆弱性を把握し、潜在的な脆弱性に事前に対処することで、ハッカーによる悪用を防ぎます。アプリケーション・セキュリティ・テストの最後の共通コンポーネントであるペネトレーションテストは、プロセスの自動化を用いず、主に手動で行います。通常、アプリケーションのリリース直前に行われるペネトレーションテストは、ホワイトハッカーの専門知識に基づいて実行中のアプリケーションをテストし、他のアプリケーション・セキュリティ・テスト・ツールでは捕捉できない可能性のある脆弱性を発見します。ProjectR(OWASP)は、ソフトウェアセキュリティの向上に取り組んでおり、ペネトレーションテストのガイドラインに優れた概説を提示しています。小規模なアプリケーションや高リスクと見なされないアプリケーションの場合であれば、1週間程度でテストを完了することも可能ですが、大規模で複雑なアプリケーションやさらに精査が必要なアプリケーションの場合、相当長い時間がかかり、結果のデータ件数も様々な要因によって増減します。テストにかかる時間や結果のデータ件数にかかわらず、ペネトレーションテストを実行することで、さまざまな種類の攻撃に対するアプリケーションの応答について新たな視点を得ることができます。複数のアプリケーション・セキュリティ・テスト・ツールから生成される膨大なテスト結果を理解する方法は?複数のツールを使用するにはそれなりの理由があります。各ツールには、それぞれ異なる長所があり、発見される問題の種類も異なります。どれが良いかという優劣の問題ではなく、組織が提供するアプリケーションに最適なツールを検討する必要があります。企業のビジネス目標達成に必須の重要なアプリケーションや規制監督の対象となるアプリケーションは、アタックサーフェスが限定されている比較的重要度の低いアプリケーションの場合よりも、テストを強化するメリットが高い可能性があります。どのツールを使用しても、膨大な結果をまとめることになるわけです。アプリケーションのテストには時間がかかるため、結果の信頼性を考慮する必要があります。これらのテストツールによって、膨大な欠陥やバグが報告される可能性があり、誤検知率とどれだけの重複が報告されるかを考慮する必要があります。結果は個々のツールに散在し、それぞれ独自の説明と重大度のスコアリング方式を採用しています。どの結果が最大のリスクをもたらすかを把握し、最も効果の高い修正作業に集中できるようにするにはどうすればよいでしょうか。Model(BSIMM12)によると、「開発部門の専任SSG(ソフトウェア・セキュリティ・グループ)メンバーの割合は中央値で0.74%(開発者135人あたりSSGメンバー1人)」です。この人員数の不均衡により、アプリケーション・セキュリティ・エンジニアは、確実に重大な脆弱性を迅速に特定し、解決する必要性に迫られています。そのためには、すべてのテストツールの結果を一元的に表示・管理し、簡潔で一貫した方法によって誤検知と重複を排除する必要があるのです。問題に優先順位を付けることで重要な問題を迅速に解決できるのです。多くのAppSecテスト・ツール・ベンダーはAppSecテストのすべての結果を一元的に可視化しようとしますが、その場合、一部のツールがテストのニーズを満たしていなくても、すべてのツールを1つのベンダーから選択せざるを得ず、選択肢が1社に限定されることになります。なく、さまざまなテストツールとソースからの結果を取り込み、SDLCにシームレスに統合し、結果を正規化して誤検知を排除するとともに、SSGチームが問題に優先順位を付け、重要度の高い問題から迅速に解決することのできるソリューションこそが必要なのです。