CI/CDパイプラインにおけるDAST：統合戦略とベストプラクティス

重要なポイント

• CI/CDパイプラインにおけるDASTの重要な役割：DASTは、稼働中のアプリケーションを対象とするブラックボックス方式のテストです。SQLインジェクションやXSSなどの実行時の脆弱性を検出し、SASTを補完します。現代のCI/CDパイプラインに不可欠な防御レイヤーです。

• 最適な統合方法：DASTスキャンは、ビルドとデプロイの後にステージング環境または本番前環境で実行します。デプロイごとにスキャンを自動化し、認証を設定して、アプリケーションの保護された領域を正確にテストすることがベストプラクティスです。

• 主な統合上の課題：主な課題は、誤検知の多さとスキャン時間の長さです。これらはアラート疲れやパイプラインのボトルネックにつながる可能性があります。DASTツールをアプリケーションのロジックに合わせて調整し、スキャン範囲、差分スキャン、実行頻度を最適化することで対処できます。

• 効果的な戦略：包括的なセキュリティカバレッジを実現するには、DASTをSAST、SCA、IASTなどの他のセキュリティ手法と組み合わせる必要があります。また、明確なセキュリティ指標を設定し、開発チームが検出結果を効率的に解釈して修正できるようトレーニングすることも重要です。

• Snykによる支援：Snykは、開発者ファーストの包括的なセキュリティプラットフォームを提供します。DAST向けのAI搭載ソリューション、Snyk API & Webは主要なCI/CDプラットフォームとネイティブに連携します。インテリジェントな優先順位付けによって誤検知を減らし、SASTとDASTを活用して、脆弱性の検出を迅速な修正につなげる実用的な修正アドバイスを開発者に直接届けます。

DASTと現代のパイプラインにおける重要な役割を理解する

セキュリティ自動化が進むスピーディーなDevSecOpsの世界では、動的アプリケーションセキュリティテスト（DAST）は不可欠な防御レイヤーです。DASTはブラックボックステスト手法であり、外部から稼働中のアプリケーションを分析して、実際の攻撃者が脆弱性を探る方法をそのまま再現します。コンパイル前にソースコードをスキャンする静的アプリケーションセキュリティテスト（SAST）とは異なり、DASTはデプロイ済みの稼働中アプリケーションを対象に、エンドポイントへのアクセス、フォームへの入力、ユーザーや攻撃者と同じ手順でのワークフローの操作を行います。

この違いは重要です。SASTは開発プロセスの早い段階でコードレベルの欠陥を検出するのに優れていますが、アプリケーションが完全に構成され、データベース、API、認証システム、サードパーティサービスと連携したときに初めて発生する実行時の脆弱性は検出できません。DASTはこのギャップを効果的に埋め、実行環境でのみ発生するSQLインジェクション、クロスサイトスクリプティング（XSS）、クロスサイトリクエストフォージェリ（CSRF）、認証バイパスの脆弱性、設定上の弱点を特定します。

現代の継続的インテグレーション／継続的デプロイ（CI/CD）パイプラインにおいて、DASTは不可欠になっています。セキュリティのシフトレフトでは、脆弱性の予防的な検出が重視されます。DASTを使えば、デリバリープロセスの各段階でアプリケーションを自動スキャンできます。

CI/CDパイプラインにおけるDASTの主なメリット：

• 稼働中のアプリケーションをリアルタイムで脆弱性検出し、SASTや手動レビューでは見つけられない問題を発見

• 設定ミス、認証の不備、統合上の問題など、実行時や環境固有の問題を特定

• ソースコードや内部アーキテクチャへのアクセスなしに、外部の攻撃者の視点をシミュレーション

• WebアプリケーションとAPIを包括的にカバー。Swagger/OpenAPIなどのAPI定義をインポートし、RESTおよびSOAPエンドポイントを体系的にテストする機能もサポート

• PCI DSS、HIPAA、GDPRなどの規制要件への対応を支援するコンプライアンス対応レポート

現在では、Snyk API & WebのようなクラウドネイティブなDASTソリューションをCI/CDパイプラインに直接統合し、コードのコミット、ビルド、デプロイのたびに自動実行できます。この継続的な自動化により、DASTは定期監査からセキュリティ体制の中核へと変わります。

CI/CDワークフローへのDASTの組み込み：ベストプラクティス

動的アプリケーションセキュリティテスト（DAST）をCI/CDに統合するには、その特性を理解することが重要です。静的コードを分析するSASTとは異なり、DASTには完全にデプロイされた稼働中のアプリケーションが必要です。そのため、アプリケーションの構築、設定、稼働が完了している一方で、まだ実ユーザーには公開されていないステージング環境や本番前環境でスキャンを実行すると、最も効果を発揮します。

一般的なCI/CDの流れが「ビルド → テスト → ステージング → 本番」の場合、DASTはビルドとデプロイの後に組み込むのが自然です。アプリケーションのコンテナ、マイクロサービス、Webアプリがテスト環境にデプロイされたら、DASTは自動的な調査を開始できます。アプリケーションをクロールし、入力値の検証をテストし、認証の仕組みを調査して、攻撃パターンをシミュレーションします。

プラットフォームごとの統合方法

CI/CDプラットフォームによって、DAST統合へのネイティブサポートの範囲は異なります。主要なプラットフォームを比較します。

各プラットフォームでは、プラグインベースの統合とCLI/APIによるスキャンの両方がサポートされているため、チームは既存のワークフローやツールチェーンに最適な方法を選べます。一般的な統合方法では、認証トークンの設定、スキャンパラメーター（対象URL、スキャン深度、重大度のしきい値）の定義、結果管理のワークフローの確立を行います。

GitHub ActionsでDASTスキャンを自動化する

.gitlab-ci.ymlを使ってGitLab CI/CDパイプラインにDASTを設定する、シンプルな例を紹介します。

# WebアプリケーションのスキャンにGitLabのDASTテンプレートを含める include: - template: DAST.gitlab-ci.yml

# DAST設定用の変数を定義 variables: DAST_WEBSITE: "https://staging.yourapp.com" # 対象アプリケーションのURL DAST_FULL_SCAN_ENABLED: "true" # 包括的なスキャンを有効化 DAST_AUTH_URL: "https://staging.yourapp.com/login" # 認証エンドポイント DAST_USERNAME: "${DAST_USERNAME}" # GitLab CI/CD変数に保存 DAST_PASSWORD: "${DAST_PASSWORD}" # マスク変数として安全に保存

# DASTスキャンステージはステージングへのデプロイ後に実行 dast: stage: test only: - staging # ステージングブランチへのデプロイ時のみスキャンを実行

この設定により、コードがステージング環境にデプロイされるたびにDASTスキャンが自動で実行され、保存された認証情報でログインし、GitLabのセキュリティダッシュボードで確認できるセキュリティレポートが生成されます。

DASTをスムーズに統合するためのベストプラクティス

CI/CDパイプラインでDASTの効果を最大限に高めるため、次の実証済みの手法をおすすめします。

• 手動での介入なしに継続的なセキュリティ検証を実現するため、ステージングへのデプロイごとにDASTスキャンを自動実行する

• ログインが必要なアプリケーションの保護領域もDASTツールでテストできるよう、正確なスキャンのために認証とセッション管理を設定する

• チケット管理システム、Slack通知、マージリクエストのコメントとの連携を通じて、検出結果を開発者に直接届けるフィードバックの仕組みを整える

• ビルド失敗の基準となる脆弱性の重大度しきい値を明確に設定する。重大または緊急の検出結果がある場合のみビルドを失敗させ、セキュリティの厳格さと開発スピードのバランスを取る

効果的な統合には、セキュリティをコードとして扱い、パイプライン定義をバージョン管理に保存することが欠かせません。また、開発者が問題を迅速に修正できるよう、明確で実行可能なフィードバックを提供する必要があります。

CI/CDパイプラインでDASTを実行する際の課題

誤検知

DASTをCI/CDパイプラインに統合すると、セキュリティ向上よりも運用上の負担が増すことがあります。最大の原因は誤検知です。多くのDASTツールは大量の誤検知を生成するため、AppSecチームや開発チームの貴重な時間を浪費するだけでなく、ノイズに埋もれて重大な脆弱性が見過ごされる可能性もあります。DASTはアプリケーションの詳細なコンテキストを把握できず、デフォルト設定やヒューリスティックに頼るため、複雑なビジネスロジックや正当なアプリケーションの動作をセキュリティ上の欠陥と誤認することがあります。

開発スピードへの影響は深刻です。チームが誤検知を何度も目にすると「アラート疲れ」が生じ、セキュリティ上の検出結果を無視したり、優先度を下げたりするようになります。DASTツールの判断を信頼できなくなった結果、実際の脆弱性が見逃されるという危険な悪循環につながります。

DASTスキャンの誤検知：ノイズを減らす方法

次の実践的な方法を通じて、誤検知を大幅に減らし、DASTの効果を高めることができます。

1. 既定の設定に頼るのではなく、アプリケーションのアーキテクチャ、ビジネスロジック、技術スタックに合わせて、DASTツールを定期的に調整・カスタマイズする

2. 過去の分析と検証に基づいて既知の誤検知を拒否リストに登録するフィルタリングの仕組みを導入し、同じ問題でない検出結果がスキャンのたびに表示されるのを防ぐ

3. 機械学習で通常のアプリケーションの動作パターンを把握し、正当な機能を脆弱性と誤認するのを抑える、AIを活用したDASTソリューションを利用する

4. 自動ツールでは明確な判断が難しい複雑なビジネスロジックのシナリオなどでは、手動のペネトレーションテストとDASTを組み合わせて検証する

5. セキュリティチームと開発チームが連携して、実際の検出結果を分類、優先順位付け、修正できるよう、担当を明確にしたトリアージプロセスを確立する

パフォーマンスへの影響を管理する

誤検知に加え、スキャン時間の長さも大きな課題です。機能が豊富な大規模アプリケーションでは、DASTスキャンに数時間、場合によっては数日かかることもあります。スピードが重視され、デプロイの時間枠が数時間ではなく数分単位のCI/CDパイプラインで、ボトルネックが発生する原因になります。

こうしたパフォーマンス上の課題を解消するには、スキャン範囲と頻度を戦略的に検討する必要があります。

• 脆弱性が最も大きなリスクとなる認証フロー、決済処理、データ管理機能など、重要なアプリケーションパスに対象を絞ってスキャン範囲を最適化する

• 網羅性とパイプラインの速度を両立するため、包括的なスキャンは定期的（毎晩または毎週）に実行し、コミットごとには範囲を絞った軽量スキャンを実行する

• 大規模アプリケーションでは並列スキャン機能を活用し、複数のインスタンスにスキャン処理を分散して、全体の所要時間を短縮する

• スキャンの深度とパイプラインの時間的制約のバランスを取る。デプロイの状況に応じてクロールの深度とテスト範囲を調整する（リリース候補ではより深く、機能ブランチではより高速にスキャンする）

重要なのは、DASTを「すべて実施するか、まったく実施しないか」の二択にする必要はないということです。状況に応じてスキャンの強度を柔軟に調整すれば、厳格なセキュリティと開発の俊敏性を両立できます。

CI/CDパイプラインで効果的なDAST戦略を構築する

DASTを他のセキュリティ手法と組み合わせる

包括的なカバレッジを実現するには、複数のテスト手法を組み合わせることが最も効果的なアプリケーションセキュリティプログラムの要であると、私たちは学んできました。DASTはデプロイ済みアプリケーションの実行時の脆弱性を見つけるのに優れていますが、あらゆる種類のセキュリティ上の欠陥を検出できるわけではありません。コードレベルの分析を行う静的アプリケーションセキュリティテスト（SAST）、オープンソースの脆弱性を検出するソフトウェア構成分析（SCA）、そして実行時に計測を行うインタラクティブアプリケーションセキュリティテスト（IAST）でDASTを補完することで、組織は多層防御を実現できます。単独ですべてを検出できるツールはありませんが、複数のツールを組み合わせればカバレッジが重なり、攻撃対象領域を大幅に縮小できます。

SASTとDASTの組み合わせでCI/CDのセキュリティを強化する

DASTと静的アプリケーションセキュリティテスト（SAST）の組み合わせにより、CI/CDパイプライン全体のセキュリティを確保できます。SASTはソースコードを早い段階で分析し、アプリケーションのビルドやデプロイ前に脆弱性を内部から把握します。DASTは、ステージング環境や本番前環境で稼働中のアプリケーションをテストし、実行時に実際に悪用可能な問題を検証することで、これを補完します。両者を組み合わせることで、デリバリーライフサイクル全体にセキュリティを組み込むシフトレフト、検証は右へのアプローチを実現できます。

相互検証によって誤検知を減らす

CI/CDパイプラインでDASTを使う際、誤検知はよくある課題です。DASTはアプリケーションの全体像を把握せずに動作するため、想定どおりの挙動を脆弱性と誤認する場合があります。DASTとSASTを組み合わせることで、こうしたノイズを減らせます。SASTの検出結果をもとにリスクの高い領域へDASTスキャンを誘導し、DASTで静的解析の検出結果が実環境で悪用可能かどうかを確認できます。両方の手法で同じ問題が検出されれば確度が高まり、チームは修正の優先順位をより適切に決められるため、アラート疲れの軽減にもつながります。

コードから実行時までのギャップを埋める

SASTとDASTには、それぞれ固有の限界があります。SASTでは実行時の設定ミスや認証の不備を検出できず、DASTでは実行時に表面化しない安全でないコーディングパターンやハードコードされたシークレットを特定できません。両者を組み合わせることで、コードからデプロイまで継続的に可視化し、問題を早期に発見するとともに、現実のリスクが存在する環境でセキュリティを検証できます。

Snykは、AIを活用したSASTのSnyk Codeと、インテリジェントなDASTを実現するSnyk API & Webを単一のプラットフォームに統合し、このアプローチを実現します。静的解析と動的解析の検出結果を関連付けることで誤検知を減らし、CI/CDパイプラインを遅らせることなく、検出から修正までを迅速化します。

明確な指標を設定し、DASTのKPIを追跡する

データに基づくセキュリティには、測定可能な成果が欠かせません。主なKPIは次のとおりです。

• 脆弱性検出率（DASTが1回のスキャンで検出する問題の数）

• セキュリティ上の検出事項の平均修復時間（MTTR）

• 誤検知率（検出された問題のうち、実際の脆弱性ではないものの割合）

• スキャン完了時間。

こうした指標を活用すれば、DASTの設定が最適化されているか、開発者が検出結果に効率よく対応できているか、ツールが価値をもたらしているのか、それともノイズを生み出しているだけなのかを把握し、継続的に改善できます。

開発チームをトレーニングする

セキュリティは全員で担うものであり、開発者は最前線にいます。DASTの結果の解釈、よくある実行時の脆弱性パターンの認識、セキュアなコーディング手法の実践に役立つ教育に投資することで、組織のセキュリティ態勢を強化できます。セキュリティ上の指摘がなぜ重要なのかを開発者が理解すれば、修正の妨げになるのではなく、修正に取り組むパートナーとなります。

DASTをプロアクティブに導入する

まず、現在のCI/CDセキュリティ態勢を評価しましょう。どこにギャップがありますか？本番環境に入る前に実行時の脆弱性を検出できていますか？開発者に実行可能なフィードバックを提供できていますか？重要度の低いアプリケーションでDASTを試験的に導入し、実際の結果をもとに設定を調整してから、確信と専門知識を高めつつ対象範囲を段階的に広げましょう。

セキュリティを最優先する文化を築くには、セキュリティ、開発、運用の各チームが真に協力することが不可欠です。全員がアプリケーションセキュリティに責任を持ち、セキュリティツールが妨げではなく支援となり、脆弱性の検出と修正が日々の開発プロセスに組み込まれれば、セキュリティはボトルネックではなく競争優位性になります。

SnykでCI/CDパイプラインを保護する

Snykは、既存のCI/CDワークフローに直接組み込める、包括的な開発者向けセキュリティプラットフォームとして開発されました。開発者の作業を妨げず、共に機能するセキュリティです。AIを活用したこのプラットフォームは、ソフトウェア開発ライフサイクル全体を通じてアプリケーションセキュリティを実現します。インテリジェントなSASTを実現するSnyk Code、SCAを実現するSnyk Open Source、イメージスキャンを行うSnyk Container、インフラストラクチャのセキュリティを確保するSnyk IaC、そして包括的な実行時テストを行うSnyk API & Webを提供します。

Snykの強みは、開発者を第一に考えたアプローチです。開発者が作業する場所で実行可能な修正ガイダンスを提供し、Jenkins、GitLab、Azure DevOpsをはじめ、主要なCI/CDプラットフォームとネイティブに連携します。また、インテリジェントな優先順位付けにより誤検知とアラート疲れを大幅に軽減します。セキュリティ上の検出結果には状況に応じた情報や修正方法が含まれ、プルリクエストの自動化にも対応するため、脆弱性の検出から迅速な修正へとつなげられます。

AI時代にAI主導のSASTとDASTを組み合わせた統合的なアプリケーションセキュリティテストが必要な理由を、さらに詳しく知りたいですか？今すぐ『The Gorilla Guide® To Unified SAST and DAST in the AI Era』をダウンロードしてください。