SASTとDASTの比較
一般的に使用されているアプリケーションセキュリティテストツールにはどのようなものがあり、チームはどれを選択すべきなのでしょうか？詳しく見ていきましょう。
SASTとDASTは、セキュリティの脆弱性を検出するために使用される2種類のアプリケーションセキュリティテストです。ソフトウェア開発では、アプリケーションのセキュリティ確保が極めて重要です。そこで、静的アプリケーションセキュリティテスト（SAST）や動的アプリケーションセキュリティテスト（DAST）などのツールが活躍します。アプリケーションのセキュリティを脅かす可能性のある脆弱性を特定する上で、それぞれが独自の目的を果たします。
SASTとDASTの相乗効果により、開発チームは包括的なセキュリティテスト戦略を用意できます。SASTはコード内の脆弱性を早期に検出し、DASTはアプリケーションが稼動した後に攻撃を受けた場合の対応を実践的に評価します。### SASTとは？
SASTはソースコードを実行することなく深く掘り下げる、ホワイトボックステストのアプローチが特徴です。例えて言えば、専門のレビュアーがコードを精査し、SQL挿入やバッファオーバーフローのようなセキュリティ侵害が発生しやすい部分をピンポイントで指摘するようなものです。開発ライフサイクルの早い段階、理想的にはコードがコミットされた直後にSASTを統合することで、開発者は潜在的なセキュリティ問題について即座にフィードバックを受けることができ、迅速な修正が可能になります。
このようにセキュリティに対して事前予防的な姿勢を取ることで、コードがデプロイされるはるか前から脆弱性に確実に対処できるようになり、時間とリソースを節約すると同時に、開発者の輪の中でセキュリティに配慮する文化を醸成します。
DASTとは？
一方、DASTは、外部者の視点に立ち、実行中のウェブアプリケーションに対してブラックボックステストを実施し、攻撃者が悪用する可能性のある脆弱性を発見します。アプリケーションに対するサイバー攻撃をシミュレートし、クロスサイトスクリプティングや認証フローのような問題をスキャンします。
DAST は、アプリケーションをハッカーの視点から捉え、デプロイ環境におけるセキュリティの弱点を浮き彫りにし、実際の攻撃に対する防御を強化する方法についての詳細情報を提供します。
両ツールを併用することで開発ライフサイクルのさまざまなステージで異なる種類の脆弱性を検出でき、堅牢なセキュリティ対策状況が実現します。セキュアなソフトウェアの出荷を目指すチームでは、SASTの早期介入とDASTの実環境テストをバランスよく実施することで、アプリケーションを包括的に保護することができるようになります。
SASTは、デプロイされるはるか前のコード開発中の時点で、セキュリティの脆弱性を早期に発見できる重要な方法です。開発プロセスの早い段階で脆弱性を発見できれば、多くの場合より低コストかつ簡単に修正できます。こうした早期発見の仕組みは、潜在的なセキュリティ侵害のリスクを軽減するだけでなく、ペースの速い現代のソフトウェア開発環境において、安全なアプリケーションを開発するためのベストプラクティスとして活用されています。
初期段階からセキュリティを優先することで、高コストで被害規模が大きいセキュリティインシデントがデプロイ後に発生する可能性を大幅に低減し、アプリケーションと企業の信頼性を向上できます。SASTはアプリケーションを保護するだけでなく、開発チームの評価と安定性を維持し、ソフトウェア開発における卓越性と信頼性へのコミットメントを示すことができます。
DASTを使用すると、アプリケーション内のコードや技術に焦点を当てた他の従来のテスト手法では発見しにくい、アプリケーションのセキュリティ問題や脆弱性を発見することができます。DASTはアプリケーションに対する攻撃をシミュレートし、攻撃者が侵入する可能性のあるセキュリティ上の弱点を特定します。これにより、実際の攻撃者に悪用される前に弱点を修正することが可能となります。
さらにDASTはアプリケーションを実行状態でテストできるため、静的な解析では見落とされがちな実行時の動作や環境固有の脆弱性に関する独自のインサイトを得ることができます。これには設定ミス、認証やセッション管理の欠陥、アプリケーションが稼動しているときにのみ生じる運用上の問題などのテストが含まれます。
SASTとDASTは、DevOpsチームにとってますます一般的なツールとなっています。
GitLabの2022年グローバルDevSecOps調査によると、現在53%の開発者がSASTスキャンを（2021年の40%未満から増加）、55%の開発者がDASTスキャンを実行しています（2021年の44%から増加）。
SASTとDASTは、大きく異なる種類の脆弱性とセキュリティの問題を検出します。以下は、SASTとDASTが特定できるセキュリティ問題の一例です。
SASTが検出できるもの
- SQL挿入
- バッファオーバーフロー
- XML外部エンティティ（XXE）の脆弱性
- OWASPトップ10やSANS/CWEトップ25などの業界標準で特定された重大なセキュリティ脆弱性
DASTが検出できるもの
- クロスサイトスクリプティング（XXS）
- SQL挿入
- 破損した認証の欠陥
- 暗号化の問題
- アプリケーションサーバーまたはデータベースの設定ミス
- ソースコードから見えない可能性のあるセキュリティ管理に関する誤った前提条件
SASTとDASTのメリットを最大限に引き出すには、以下を行うことをおすすめします。
- SASTとDASTをチームのワークフローとCI/CDパイプラインにビルド/統合する
- SASTとDASTを自動実行させ、チームがテストを手動で開始する必要をなくす
- SASTとDASTの実行を確実にし、回避したり忘れたりできないようにする
- 脆弱性が検出されたコードを、適切な承認なしにマージできないように制限を設ける
- 使用するSASTアナライザーとDASTアナライザーが定期的に更新されていることを確認し、最新の脆弱性定義の恩恵を受けられるようにする
- 開発、運用、セキュリティのすべてのチームがスキャン結果を容易に確認でき、セキュリティ上の問題を修正するために協力できるように、SASTとDASTを使用する
チームが安全なソフトウエアをリリースできるように、また、セキュリティ上の問題が発生しても、それが開発の遅れにつながらないような早い段階で発見できるように、SASTとDASTの_両方_の使用をおすすめします。
SASTは、ソフトウエア開発ライフサイクルの非常に早い段階で、理想的にはコードがコミットされた時点で実行する必要があります。これにより、コード中のセキュリティ脆弱性を検出し、そのコードをコミットした担当者の記憶にまだ新しいうちにそれを指摘することが可能になります。
DASTは、アプリケーションに変更を加えるたびに実行する必要があります。理想的には、テスト環境にデプロイするときに実行することで、本番環境に移行する前に問題を発見できます。また、DASTは、クロスサイトスクリプティングや 認証の欠陥のような問題がないか、ライブのウェブアプリケーションを継続的に監視するために使用することもできます。
スキャン対象
SASTはソースコードをスキャンし、DASTはアプリケーションやアプリケーションが接続するAPIやウェブサービス（GraphQL、REST、SOAPなど）をスキャンします。
スキャンするタイミング
SASTはコードが書かれた直後のソフトウェア開発ライフサイクルの早い段階で発生しますが、DASTは開発ライフサイクルの後期、テスト環境で動作するアプリケーション、あるいは本番コード上で行われます。
テストの種類の違い
SASTは、アプリケーションとコード内の脆弱性を探すホワイトボックステストであり、DASTは、外部の攻撃者が侵入する可能性のある脆弱性を探すブラックボックステストです。
コースコードへのアクセス
SASTツールはアプリケーションのソースコードをスキャンしますが、DASTツールはソースコードにアクセスできません。
言語依存性の違い
SASTはソースコードをスキャンするため、使用するプログラミング言語や開発フレームワークに特化しており、使用するSASTツールは、C++、Python、Go、React、Rubyなど、使用しているプログラミング言語に対応している必要があります。
SASTとは異なり、DASTはアプリケーションを外部から攻撃者と同じようにテストするため、アプリケーションがどのような言語やフレームワークで構築されているかは関係ありません。
誤検出
SASTはDASTよりも誤検出が多くなる傾向があります。これは、ソースコードに焦点を当てているため、問題があるように見えるコードの1行が、実際には他のどこかで解決されているかを判断するためのすべてのコンテキストを持っていないためです。GitLabのようなDASTプロバイダーの中には、SASTで誤検出を特定できるものもあります。
GitLabのDevSecOpsプラットフォームは、SASTとDASTを最大限に活用し、スピードを犠牲にすることなくアプリケーションのセキュリティを向上させることができます。
詳細に関しては、以下のリソースをご覧ください。