Skip to main content

Bright Securityによる開発者中心のDAST

blog header snyk brightsec

2023年4月14日

0 分で読めます

セキュリティテストは、ソフトウェア開発ライフサイクル(SDLC)に欠かせない要素として、ますます重視されています。従来、アジャイルソフトウェア開発では、開発スピード、市場からの迅速なフィードバック、高品質な製品やサービスの提供が重視されてきました。しかし、サイバー攻撃に対して脆弱なソフトウェアはエンドユーザーに価値をもたらさず、顧客とソフトウェアベンダーの双方に大きなリスクをもたらします。そのため、セキュリティテストをソフトウェア開発プロセスに組み込むことが不可欠です。

この記事では、ソフトウェアテストツール、とりわけ新世代の開発者中心のDASTツールが、組織のセキュリティテストの網羅性を高め、開発者を育成し、効果的な脆弱性修正プロセスを確立して、コストのかかるセキュリティ侵害を防ぐ安全なアプリケーションを構築するうえで、どのように役立つかをご紹介します。

SASTとDASTとは?

SASTとDASTは、ソフトウェアセキュリティテストで広く使われている2つの手法です。

SAST(静的アプリケーションセキュリティテスト)は、アプリケーションのソースコードを分析して、セキュリティ上の脆弱性を特定するテスト手法です。Snyk CodeのようなSASTツールは、バッファーオーバーフロー、SQLインジェクション、リモートコード実行(RCE)など、一般的なプログラミングエラーやセキュリティ上の問題を検出するためにソースコードをスキャンします。SASTは通常、アプリケーションの開発段階で実施され、ソフトウェア開発ライフサイクルの早期に脆弱性を検出するのに役立ちます。

DAST(動的アプリケーションセキュリティテスト)は、アプリケーションへの攻撃をシミュレートし、セキュリティ上の脆弱性を特定するテスト手法です。DASTツールは、Webサービスやデータベースなど、外部環境とのやり取りを含め、アプリケーションの動作をテストします。DASTは通常、ステージング環境または本番環境で実施され、SASTでは見逃された可能性のある脆弱性や、実稼働環境でのみ発生する脆弱性の検出に役立ちます。

SASTとDASTツールのメリットと限界

SASTとDASTのツールは、開発やアプリケーションセキュリティの専門家に大きなメリットをもたらしますが、完璧ではありません。Snykでは、互いの弱点を補うSASTとDASTの併用について、より詳しく解説した記事も公開しています。ここでは、それぞれの技術のメリットとデメリットを簡単に見ていきましょう。

SASTのメリット:

  • 脆弱性の早期検出:SASTは、ソフトウェア開発ライフサイクルの早い段階で脆弱性を検出できます。開発者は問題が発生した時点で修正できるため、開発後半や、さらに悪い場合にはアプリケーションのデプロイ後に修正するコストを避けられます。

  • 開発プロセスとの統合:SASTツールは開発プロセスに組み込めるため、継続的なテストと脆弱性の自動検出が可能です。手動でセキュリティテストを行う場合と比べて、時間とリソースを節約できます。

  • ルールセットのカスタマイズ:SASTツールは、アプリケーションごとに特定のルールセットを設定でき、アプリケーション固有の脆弱性を特定できます。このようにカスタマイズすることで、対象のアプリケーションに関連する問題を確実に検出できます。

SASTのデメリット:

  • 検出できる問題の範囲が限られる:SASTツールで検出できる脆弱性の種類には限りがあり、複雑な脆弱性や見つけにくい脆弱性を検出できない場合があります。そのため、一部の脆弱性が見逃され、アプリケーションが攻撃にさらされるおそれがあります。

  • 静的な入力への依存:SASTツールは静的な入力に依存するため、与えられたコードしか分析できません。ユーザーからの入力データなど、アプリケーションが動的な入力を使用する場合、その入力に起因する脆弱性をSASTでは特定できないことがあります。

  • 誤検知:SASTツールは誤検知を生み、時間やリソースの浪費につながることがあります。実際には脆弱性でない問題や、実際に悪用できない問題をツールが検出した場合に発生します。誤検知は開発者にとってストレスとなり、ツールへの信頼を損なうおそれがあります。

DASTのメリット:

  • 実際の攻撃シナリオを正確に再現:DASTは実稼働環境でアプリケーションの動作をテストするため、実際の攻撃シナリオを正確に再現できます。SASTでは検出できなかった脆弱性の特定に役立ちます。

  • 開発プロセスに依存しない:DASTテストは開発プロセスから独立しており、ソースコードにアクセスすることなく、デプロイ済みのアプリケーションをテストできます。そのため、サードパーティ製アプリケーションのテストに適しています。

  • 包括的なテスト範囲:DASTは、Webサービス、データベース、APIなど、実行時環境とのアプリケーションのやり取りをテストするため、包括的なテスト範囲を実現します。

DASTのデメリット:

  • 問題のトリアージが難しい場合がある:DASTテストでは、複数のコンポーネントにまたがる問題(入出力のサニタイズに関する問題など)が特定されることがあります。その場合、チームは問題のトリアージと修正に、より多くの時間を要する可能性があります。

  • 実行時環境への依存:DASTテストはアプリケーションの実行時環境に依存するため、特定の実行時環境でのみ発生する脆弱性を検出できない場合があります。その結果、偽陰性が発生し、セキュリティが確保されているという誤った安心感につながるおそれがあります。

  • 導入時期が遅い:DASTでは、実稼働環境での動作をテストするために、アプリケーションの実行インスタンスが必要です。そのため、通常は開発プロセスの終盤に導入されます。つまり、アプリケーションの開発が完了し、本番環境またはステージング環境にデプロイされるまでDASTを開始できず、その間、潜在的な問題が検出されないままになる可能性があります。

開発者中心のDASTとは?SASTをどのように補完するのか?

開発者中心のDASTは、ソフトウェア開発ライフサイクルへのセキュリティテストの統合に重点を置くDASTの手法です。開発者中心のDASTの目的は、開発プロセスの早い段階にセキュリティテストを前倒しし、開発サイクルの早期に脆弱性を検出して修正できるようにすることです。

開発者中心のDASTとSASTを併用すると、アプリケーションセキュリティテストをより包括的に実施できます。

SASTは通常、開発者がコードを記述する開発プロセスの初期段階で使用します。アプリケーションのソースコードをスキャンし、SQLインジェクションなどの脆弱性を検出します。この手法により、コードがコンパイルされてデプロイされる前に、開発者が潜在的なセキュリティ上の問題を特定して修正できます。ただし、SASTには限界があり、実行中のアプリケーションでしか確認できない脆弱性は検出できない場合があります。

一方、開発者中心のDASTは実行中のアプリケーションをテストし、入力検証、設定、認証に関する脆弱性など、SASTでは見逃す可能性のある脆弱性を検出できます。開発者中心のDASTは開発プロセスに統合できるため、開発者はアプリケーションを作りながらテストできます。この手法では、コードのセキュリティに関するフィードバックをすぐに得られ、脆弱性を迅速に修正できます。

SASTと開発者中心のDASTを組み合わせることで、組織はソースコードと実行中のアプリケーションの両方にある脆弱性を特定して修正でき、セキュリティ態勢をより完全に把握できます。また、この手法はコンプライアンス要件への対応や、セキュリティ侵害とデータ損失のリスク低減にも役立ちます。

開発者中心のDAST戦略を導入するための5つのベストプラクティス

開発者中心のDAST戦略を導入するには、ソフトウェア開発ライフサイクルにセキュリティテストを統合する必要があります。効果的に実施するため、組織は次のベストプラクティスに従いましょう。

  1. DASTを開発プロセスに統合する:開発者がコードの作成直後にセキュリティ上の脆弱性をテストできるよう、開発プロセス全体にDASTを組み込みます。そのためには、開発環境に統合できる自動化DASTツールが必要です。

  2. 脆弱性に優先順位を付ける:脆弱性が検出されたら、深刻度と潜在的な影響に基づいて優先順位を付けます。これにより、最も重大な脆弱性から確実に対処できます。

  3. セキュリティのベストプラクティスについて開発者をトレーニングする:より安全なコードを書けるよう、セキュアコーディングの手法など、セキュリティのベストプラクティスについて開発者をトレーニングします。これにより、そもそも脆弱性が混入するのを防ぎやすくなります。

  4. 脆弱性を修正するプロセスを確立する:開発者中心のDASTで検出された脆弱性を修正するプロセスを確立します。脆弱性が修正されたことを確認し、修正が有効であることを確かめるためにアプリケーションを再テストする手順も含めます。

  5. 進捗を監視・追跡する:開発者中心のDAST戦略が効果を上げているか確認するため、進捗を継続的に監視・追跡します。検出された脆弱性の数、修正にかかる時間、アプリケーション全体のセキュリティ態勢などを指標として活用できます。

これらのベストプラクティスに従うことで、組織は効果的かつ効率的な開発者中心のDAST戦略を導入できます。この手法は、アプリケーション全体のセキュリティ態勢を強化し、セキュリティ侵害やデータ損失のリスクを低減するとともに、コンプライアンス要件への対応にも役立ちます。

SASTとDASTのモダナイゼーション

ソフトウェアセキュリティテストは、アプリケーションを安全に保ち、サイバー攻撃から守るうえで不可欠です。開発者中心のDASTは、ソフトウェア開発プロセスへのセキュリティテストの統合を重視する動的テストの手法です。セキュリティテストを自動化して継続的インテグレーション/デリバリー(CI/CD)パイプラインに組み込むことで、開発者中心のDASTは、潜在的なセキュリティ上の問題に関する迅速なフィードバックを開発者に提供します。これにより、開発者は脆弱性にリアルタイムで対処でき、セキュリティ上の問題の影響を最小限に抑え、脆弱性の見逃しを防ぎやすくなります。