Bright Securityによる開発者中心のDAST
2023年4月14日
13 分で読めますセキュリティテストは、
この
SASTとDASTとは?
SASTと
SAST(静的アプリケーションセキュリティテスト)は、
DAST(動的アプリケーションセキュリティテスト)は、
SASTとDASTツールのメリットと限界
SASTと
SASTのメリット:
脆弱性の
早期 検出:SASTは、 ソフトウェア開発ライフサイクルの 早い 段階で 脆弱性を 検出できます。 開発者は 問題が 発生した 時点で 修正できる ため、 開発後半や、 さらに 悪い 場合には アプリケーションの デプロイ後に 修正する コストを 避けられます。 開発プロセスとの
統合:SASTツールは 開発プロセスに 組み込める ため、 継続的な テストと 脆弱性の 自動検出が 可能です。 手動で セキュリティテストを 行う 場合と 比べて、 時間と リソースを 節約できます。 ルールセットの
カスタマイズ:SASTツールは、 アプリケーションごとに 特定の ルールセットを 設定でき、 アプリケーション固有の 脆弱性を 特定できます。 このように カスタマイズする ことで、 対象の アプリケーションに 関連する 問題を 確実に 検出できます。
SASTのデメリット:
検出できる
問題の 範囲が 限られる :SASTツールで 検出できる 脆弱性の 種類には 限りが あり、 複雑な 脆弱性や 見つけに くい 脆弱性を 検出できない 場合が あります。 その ため、 一部の 脆弱性が 見逃され、 アプリケーションが 攻撃に さらされる おそれが あります。 静的な
入力への 依存:SASTツールは 静的な 入力に 依存する ため、 与えられた コードしか 分析できません。 ユーザーからの 入力データなど、 アプリケーションが 動的な 入力を 使用する 場合、 その 入力に 起因する 脆弱性を SASTでは 特定できないことがあります。 誤
検知:SASTツールは 誤検知を 生み、 時間やリソースの 浪費に つながることがあります。 実際には 脆弱性でない 問題や、 実際に 悪用できない 問題を ツールが 検出した 場合に 発生します。 誤検知は 開発者に とって ストレスと なり、 ツールへの 信頼を 損なう おそれが あります。
DASTのメリット:
実際の
攻撃シナリオを 正確に 再現:DASTは 実稼働環境で アプリケーションの 動作を テストする ため、 実際の 攻撃シナリオを 正確に 再現できます。 SASTでは 検出できなかった 脆弱性の 特定に 役立ちます。 開発プロセスに
依存しない :DASTテストは 開発プロセスから 独立しており、 ソースコードに アクセスする ことなく、 デプロイ済みの アプリケーションを テストできます。 その ため、 サードパーティ製アプリケーションの テストに 適しています。 包括的な
テスト範囲:DASTは、 Webサービス、 データベース、 APIなど、 実行時環境との アプリケーションの やり取りを テストする ため、 包括的な テスト範囲を 実現します。
DASTのデメリット:
問題の
トリアージが 難しい 場合が ある :DASTテストでは、 複数の コンポーネントに またがる 問題 (入出力の サニタイズに 関する 問題など)が 特定される ことがあります。 その 場合、 チームは 問題の トリアージと 修正に、 より 多くの 時間を 要する 可能性が あります。 実行時環境への
依存:DASTテストは アプリケーションの 実行時環境に 依存する ため、 特定の 実行時環境でのみ発生する 脆弱性を 検出できない 場合が あります。 その 結果、 偽陰性が 発生し、 セキュリティが 確保されていると いう 誤った 安心感に つながる おそれが あります。 導入時期が
遅い :DASTでは、 実稼働環境での 動作を テストする ために、 アプリケーションの 実行インスタンスが 必要です。 その ため、 通常は 開発プロセスの 終盤に 導入されます。 つまり、 アプリケーションの 開発が 完了し、 本番環境または ステージング環境に デプロイされるまで DASTを 開始できず、 その間、 潜在的な 問題が 検出されないままに なる 可能性が あります。
開発者中心のDASTとは?SASTをどのように補完するのか?
開発者中心の
開発者中心の
SASTは
一方、
SASTと
開発者中心のDAST戦略を導入するための5つのベストプラクティス
開発者中心の
DASTを
開発プロセスに 統合する:開発者が コードの 作成直後に セキュリティ上の 脆弱性を テストできるよう、 開発プロセス全体に DASTを 組み込みます。 その ためには、 開発環境に 統合できる 自動化DASTツールが 必要です。 脆弱性に
優先順位を 付ける:脆弱性が 検出されたら、 深刻度と 潜在的な 影響に 基づいて 優先順位を 付けます。 これに より、 最も 重大な 脆弱性から 確実に 対処できます。 セキュリティの
ベストプラクティスに ついて 開発者を トレーニングする:より 安全な コードを 書けるよう、 セキュアコーディングの 手法など、 セキュリティの ベストプラクティスに ついて 開発者を トレーニングします。 これに より、 そもそも 脆弱性が 混入するのを 防ぎやすくなります。 脆弱性を
修正する プロセスを 確立する:開発者中心の DASTで 検出された 脆弱性を 修正する プロセスを 確立します。 脆弱性が 修正された ことを 確認し、 修正が 有効である ことを 確かめる ために アプリケーションを 再テストする 手順も 含めます。 進捗を
監視・追跡する:開発者中心の DAST戦略が 効果を 上げているか確認する ため、 進捗を 継続的に 監視・追跡します。 検出された 脆弱性の 数、 修正に かかる 時間、 アプリケーション全体の セキュリティ態勢などを 指標と して 活用できます。
これらの
SASTとDASTのモダナイゼーション
ソフトウェアセキュリティテストは、



