継続的テストとCI/CDパイプラインにおけるセキュリティギャップを解消

最近発表されたガートナー社の2022年の「Critical Capabilities for Application Security Testing（アプリケーション・セキュリティ・テストのための重要な能力）」（AST）レポートでは、Synopsysが5つのユースケースで最高スコアを獲得しました。「Continuous Testing Use Case（継続的テストのユースケース）」で、ガートナー社によるランキングと評価、および継続的テストの導入を検討中または現在実施している組織にとってSynopsysの製品ポートフォリオが最適な理由をご覧ください。

継続的テストを実施するための上位14のツールの能力を評価する基準に関しては、動的アプリケーション・セキュリティ・テスト（DAST）、インタラクティブ・アプリケーション・セキュリティ・テスト（IAST）、APIセキュリティを実行するツールのテストと検出の機能に比重が置かれ、静的アプリケーション・セキュリティ・テスト（SAST）およびソフトウェア・コンポジション解析（SCA）を実行するツールの機能は同等以下の比重で評価されています。その理由を理解するために、最近のソフトウェアエコシステムで継続的テストが果たす役割をご覧ください。

継続的アプリケーション・セキュリティ・テスト

まず、継続的テストとは何かを理解する必要があります。継続的テストとは、コードが変更されるたびに自動テストを実行することです。継続的テストはソフトウェア開発ライフサイクル（SDLC）全体にわたって継続的かつ反復的に実行され、ソフトウェア・デリバリー・パイプラインに組み込まれて、コードやバイナリリポジトリにプッシュされた変更に関するフィードバックを迅速化します。

継続的テストは、特にDevOpsで継続的インテグレーション/継続的デリバリー（CI/CD）を推進する場合に重要です。CI/CDは時代の先取りを目指す企業に必須のスピーディーな製品のイノベーションを可能にする手法であるのに対し、継続的テストは品質に対する信頼の確立を支援します。継続的テストにより、製品が想定どおりに動作し、信頼性とセキュリティが確保されているという安心感を得られます。デリバリーパイプラインでの継続的テストにより、必要な品質レベルを達成するために、必要な場所に任意の数のクオリティゲートを導入することができます。

継続的テストにおけるセキュリティギャップを解消

最近では、継続的テストは標準的な手法になりつつありますが、多くの組織にとって、セキュリティ監視のための新たな層を組み込むことは簡単ではありません。それには容易に理解できる理由があります。

セキュリティ層を追加しなくても、継続テストの実装に必要な作業はすでに膨大です。継続的テストを機能させるには、開発チームとQAテストチームが協力してテストを早期に定義し、テスト駆動型またはビヘイビア駆動型のテストケースを作成して、最適なテストカバレッジを確保する必要があります。継続的テストの実行を成功させるには、開発チームとテストチームがさまざまな用途で使用するための開発に適したツール（コード、CI/CD統合、サポートされているオープンソースなど）を備えた包括的なオンデマンドのテスト環境を装備する必要があります。理想的には、単体テスト、統合テスト、機能テスト、回帰テスト、受け入れテストなどのさまざまなニーズにオンデマンドで対応し、運用環境に近いデータを使用して包括的なテストを実行できるように、適切なテストデータをプロビジョニングできるテスト環境が求められます。継続的テストでは、継続的パイプラインの各段階において、さまざまな種類のテストが、多様な環境やデプロイ先のさまざまな環境でシームレスに実行されます。テストはコードチェックインやコード変更などのイベントによって自動的にトリガされます。継続的テストの目的は、迅速なフィードバックを確保し、できるだけ早くチームに問題を警告することです。

継続的テストは、運用環境への移行が進むにつれて、ますます困難で時間がかかるようになります。また、シミュレーション環境が運用環境に近づくほど、テストが深化します。コードの成熟と環境の複雑化に応じて、徐々にテストを増やし、より複雑なテストを追加していく必要があります。以前に開発したものと同じテストケースがSDLC全体で実行されない可能性があります。テストケースは重要な変更が行われるたびに更新する必要があります。また、コードの成熟度が高まり、環境が上位レベルに進み、構成とインフラストラクチャが運用段階に到達するまで、自動化されたスクリプトをテスト進行の各段階で更新する必要があります。

テストがリリース段階に向かって進行するにつれて、テストの実行に必要な時間も増加します。たとえば、単体テストの実行は短時間で完了するかもしれませんが、統合テストやシステム・テスト/負荷テストの実行には数時間から数日かかる場合があります。GoogleのState of DevOps Reportで報告されている、エンドツーエンドの継続的テストを実行するために必要な時間と労力の大きさを考えると、自動化されたセキュリティ・テストが他のタイプの自動化作業（ビルドやリリースの自動化など）に遅れをとっていることも不思議ではありません。

継続的テストとデリバリーパイプラインにセキュリティテストのプラクティスとツールが組み込まれている組織では、一般的に、自動化されたパイプラインにSASTツールやSCAツールがデプロイされています。各ツールはSDLCの工程でそれぞれ固有の位置を占めていますが、独自開発のコードベース、およびオープンソース・コードやサードパーティー製コードなどの外部依存関係を保護するためにSDLCの早い段階で導入する必要があります。コードベースが管理され、ユーザーエクスペリエンスを確実に予測可能な統制された環境であれば、これで十分かもしれませんが、

ソフトウェアアプリケーションの開発とデリバリーのパラダイムがモノリシックモデルから高度に分散されたコンピューティング・モデルに移行した昨今では、この装備では不十分です。マイクロサービスアーキテクチャ、クラウド、API、サーバーレス関数などのテクノロジの登場により複合化が進んでいるモダンアプリケーションには、無数のソフトウェアコンポーネントとイベント駆動型トリガが存在します。また、重大な脆弱性やエクスプロイトを開発フェーズでは予測または捕捉できず、アプリケーション・ランタイム・テストでさまざまなコンポーネントが統合される段階で初めてトリガされる場合もあります。最近の組織は、独自開発の内部コードベースやアプリケーションから、サードパーティー製のコンポーネントやAPIに至るまで、膨大な量のアプリケーションを所有・管理しなければならず、これが予期しないアタックサーフェスの拡大につながります。

そのため、摩擦を最小限に抑えてCI/CDパイプラインの継続的テストを強化できるモダンなDASTアプローチをテストに組み込むことがこれまで以上に重要になっています。