DAST（Dynamic Application Security Testing）ツールの結果が誤検知になる可能性はありますか？
静的アプリケーションセキュリティテスト（SAST）の結果は誤検知または実際の結果になる可能性があることを知っており、シナリオとコンテキストに基づいて実際の脆弱性を判断するのはセキュリティアナリストと開発者の責任です。
DASTスキャン結果にも同じことが当てはまりますか？
これまでは、DAST（Dynamic Application Security Testing）ツールからの結果はすべて実際の/真のポジティブであり、対処する必要があると信じていました。一部のDAST結果も偽陽性になる可能性がありますか？ DASTは、誤検知を除外するために、開発者とセキュリティアナリストによる同じ時間と労力を必要としますか？
そうそう、私は文字通り、偽陽性の完全なレポートのトリアージを終えたところです（20ページのDASTレポートから正当なチケットを1つ調達しました）。そして、つまり、@ BrianWilliamsの例のように、いくつかのシナリオでは実際のツールである可能性があるため、ツールはそれらをレポートするのに適切ですが、熟練した分析者がこのシナリオで適用するかどうかを決定する必要があります。この1時間で見たいくつかの例：
- デフォルトのumaskが広すぎます。私の分析：これは、アプリがルートとして実行されるIoTデバイスであるため、無関係です。
- X-Frame ClickJacking保護が設定されていません。私の分析：静的で非インタラクティブなWebページにあるため、無関係です。
- CSRF保護がありません。私の分析：不正解です。ログインすると、（非Cookie）認証トークンがカウントされますが、ツールは盲目的に「CSRF」と呼ばれるヘッダーを探しています。
- TLS 1.0が有効になっています。私の分析：ええ、互換性のために必要です！
- 弱いオプションでマウントされたパーティション私の分析：関係ありません。デバイスに侵入してパーティションを感染させることができれば、すでにデバイスの内部にいることになります。 。
うん、私たちはそれらをずさんにしないように修正することができます（そしておそらくそうするべきです）が、それらはこのアプリケーションでは悪用されないので、それはもはやセキュリティの問題ではなく、他の技術的な負債/コードのクリーンアップタスクと一緒になってしまいます。
あなたの質問に：
DASTは、誤検知を除外するために、開発者とセキュリティアナリストによる同じ時間と労力を必要としますか？
開発者がプロセスに参加して、セキュリティスキルを常に向上させ、より安全なコードを作成できるようにしたいとします。手持ちの量は開発者のスキルに依存します。
一部のチームでは、レポートのトリアージを100％実行し、変更が必要な特定の事項のチケットをオープンする必要があります。私が開発者とトリアージする他のチーム、およびベテラン開発者の1つのチームは、トリアージのほぼ100％を行い、各リリースの前に分析を承認します。
私にとって、SAST/DASTレポートのすべての修正を盲目的に要求するセキュリティアナリストは、怠惰であるか、セキュリティで保護されているはずのテクノロジを理解していません。
トリアージプロセスにもう少し努力を払う必要があるようですが、セキュリティアナリストとして、報告された各脆弱性が本当に修正する必要があるかどうかを判断するために、もう少し掘り下げる必要があります（これにより、あなた自身のスキルを拡大することの副作用）。
偉大な言葉を言い換えると Tanya Janca ：
「開発チームとセキュリティチームの間に敵意を生み出す最も簡単な方法は、開発者に盲目的に自動化されたレポートを投げてFIX ITと言うことです！」 -ターニャジャンカ
DASTは間違いなく誤検知を起こす可能性があります。使用しているツールによって異なりますが、何百もの誤検知を引き起こす可能性があるものもあります。
たとえば、ツールは単一引用符を挿入してSQLエラーメッセージをチェックすることでSQLインジェクションをチェックしますが、エラーメッセージが表示されても、SQLインジェクションの脆弱性があるとは限りません。
SASTと同様に、修正する開発時間をスケジュールする前に、実際に脆弱性があることを確認する必要があります。