SASTとDAST：違いと両方を使用すべき理由

概要

• SAST (静的アプリケーションセキュリティテスト) は、アプリケーションが実行される前にソースコード、依存関係、バイナリをチェックします。
• DAST (動的アプリケーションセキュリティテスト) は、アプリが実行中にリアルな攻撃をシミュレートして分析します。例えば、SQLインジェクション、XSS、または認証の問題などです。
• SAST と DAST の主な違い
  • SAST = コード内（開発者側）
  • DAST = コード外（攻撃者側）
• ベストプラクティス： 両方のセキュリティテスト手法または ASPM プラットフォームのような統一された AppSec ワークフローを使用して、コードからクラウドまでのソフトウェア開発ライフサイクル全体をカバーします。
• 人気のツール： Plexicus、Checkmarx、OWASP ZAP、Burp Suite。

SAST と DAST は、アプリケーションを攻撃から保護するために使用されるセキュリティテスト手法です。それぞれがアプリケーションセキュリティにどのように役立つかを理解するために、これらの違いとワークフローにおける位置付けを見てみましょう。

各テスト手法は異なる方法で脆弱性を発見します。一方はコードをチェックし、もう一方は実行中のアプリをテストします。SAST と DAST の違いを知ることは、安全なアプリケーションを構築するための鍵です。

この記事では、次のことを学びます：

• SASTとDASTとは何か
• それぞれをどこで、いつ使用するか
• SDLCにおけるそれらの適合を示す明確な図
• 各手法に最適なツール
• 完全なカバレッジを得るためのそれらの組み合わせ方

SAST（静的アプリケーションセキュリティテスト）とは？

SASTはホワイトボックステストとも呼ばれ、ソースコード、バイナリ、またはバイトコードを分析して脆弱性を検出するセキュリティテストアプローチであり、アプリケーションを実行せずに行います。アプリの設計図の内部を検査するようなものです。

仕組み

• 開発者がコードをコミット → SASTツールがそれをスキャン（IDE、CIパイプライン）
• SASTツールがハードコードされた認証情報、SQLインジェクション、不安全なAPI使用などの問題を指摘
• チームがデプロイ前に早期に問題を修正

長所

• 開発の早い段階で脆弱性を発見し、修正コストを最小限に抑える
• 開発ワークフロー（IDE、CI）に統合され、即時フィードバックを提供

短所

• 言語やフレームワークに依存
• 実行時テストと比較して誤検知が発生する可能性がある
• 実行時/環境固有の問題を検出できない

最適な使用ケース

SASTを「シフトレフト」戦略の一部として使用します：コードのコミット/ビルド時にスキャンし、デプロイ前の最終テストとして脅威を扱うのではなく、早期にバグを発見するのに役立ちます。

DAST（動的アプリケーションセキュリティテスト）とは？

DASTはブラックボックステストとも呼ばれ、アプリケーションを実行中にスキャンし、攻撃者の視点からの実際の攻撃をシミュレートして、実行中に見える脆弱性を特定する方法です。

仕組み

• デプロイ済み/テスト環境でアプリケーションを実行します。
• DASTツールはHTTP/APIリクエストを送信し、入力を操作し、攻撃をシミュレートします。
• 認証の破損、XSS、公開されたAPI、または設定ミスなどの問題を特定します。

長所

• テクノロジーに依存しない（言語やフレームワークを問わず動作）
• 実行時および環境固有の脆弱性を発見

短所

• コードロジックの深部にある問題を見逃す可能性がある
• SDLCの後半に行うため、修正コストが高くなる。

最適な使用ケース

テスト/プレプロダクション中、または実行時のセキュリティ検証のために本番環境で継続的にDASTを使用します。

DevOpsチームによるSASTとDASTの利用状況

GitLabのGlobal DevSecOps Surveyによると、約53%の開発チームがSASTスキャンを実行し、55%がDASTスキャンを実行しています。

SAST vs DAST: 主な違い

各テスト方法がどのように異なり、また互いに補完し合うかを明確に比較します。

なぜSASTとDASTの両方を使用するのか？

SASTとDASTは互いのギャップを埋めます。

• SASTはコード内の脆弱性を早期に検出します（修正が安価）
• DASTは実行時の動作を検証し、SASTが検出できないものを捕捉します

例えば、SASTはコード内のSQLインジェクションの欠陥を検出できないかもしれませんが、DASTは実際のアプリでその欠陥が利用可能であることを検出するかもしれません。

両方を組み合わせることで、コードから実行時までのカバレッジを得ることができます。アプリケーションをより強固にします。

このシンプルなフローは、SASTとDASTがどこに適合するかを示しています。

SAST vs DASTツール

考慮すべきトップツールはこちらです：

ツール比較表

市場で利用可能な最高のSASTツールとDASTツールもチェックしてください。

ベストプラクティス：SAST + DASTワークフロー

• SAST を CI/CD にできるだけ早く統合する（プリマージまたはビルド時）
• DAST をテスト/ステージング、理想的には本番環境で実行し、ランタイム検証を行う。
• 壁を設置する: コードを保護するための壁を作成する。SAST ツールによって重大な問題が発見された場合、コードはマージできない。DAST ツールが脆弱性を発見した場合、アプリはデプロイできない。
• 開発チームとセキュリティチームが協力して結果を解釈し、セキュリティ修復を実行する。
• スキャナーのルールと脆弱性定義を更新し続ける（SAST）と、ノイズを減らすために DAST スキャンプロファイルを調整する。

課題と落とし穴

• ツールの過剰: 複数のスキャナーがオーケストレーションなしで使用されると、チームにノイズとアラート疲労を引き起こす可能性がある
• 偽陽性: 特に SAST は、調整されていない場合、多くの無関係な発見を生む可能性がある
• 遅いテスト: DAST のみに依存すると修復が遅れ、リスクが増大する
• 断片化されたワークフロー: SDLC の各段階（開発、ビルド、ランタイム環境）での可視性が欠如している

適切なプラットフォームがどのように役立つか

SAST と DAST の両方をサポートするプラットフォームを選ぶことで、ワークフローが合理化されます。例えば、Plexicus ASPMのようなプラットフォームは、静的および動的テストを統合し、発見を関連付け、リスクを優先し、自動修復を提供することで、開発チームとセキュリティチーム間の摩擦を減らします。

SAST と DAST の理解は、効果的なアプリケーションセキュリティ（AppSec）のベストプラクティスの基盤です。

• SAST はコード内の問題を早期にキャッチする
• DAST はランタイムで攻撃がどれほど現実的かをテストする

一緒に、それらは層状の防御を形成します：コードからクラウドへ。

アプリケーションのセキュリティを真剣に考えるなら、SASTとDASTの両方を統合することが必須です。DASTとSASTを統合できるプラットフォーム、例えばASPMを使用することを検討してください。また、最高のASPMツールもご紹介していますので、ご参考にしてください。

A: 一般的に、SASTはコードベースの分析と実行時コンテキストの欠如により、より多くの誤検知を生み出す可能性があります。

執筆者

José Palanco

José Ramón Palancoは、2024年に設立されたASPM（アプリケーションセキュリティポスチャ管理）の先駆的企業であるPlexicusのCEO/CTOです。この企業はAIを活用した修正機能を提供しています。以前は、2014年に設立した脅威インテリジェンスのスタートアップであるDinofluxを創業し、Telefonicaに買収され、2018年から11pathsで働いています。彼の経験には、EricssonのR&D部門やOptenet（Allot）での役割が含まれています。彼はアルカラ・デ・エナレス大学で通信工学の学位を取得し、デウスト大学でITガバナンスの修士号を取得しています。サイバーセキュリティの専門家として認められており、OWASP、ROOTEDCON、ROOTCON、MALCON、FAQinなどの様々な著名な会議で講演を行っています。サイバーセキュリティ分野への貢献として、複数のCVEの公開や、nmap-scada、ProtocolDetector、escan、pma、EKanalyzer、SCADA IDSなどの様々なオープンソースツールの開発があります。

続きを読む José