ホワイトボックス監査も可能な場合、ブラックボックス侵入テストは理にかなっていますか？
私が自社のアプリケーションの責任者であり、セキュリティの専門家を雇ってセキュリティ監査を実施するとします。さらに、私の会社がアプリケーションのソースコードを所有していて、採用した専門家にそれを引き渡すことを許可されていると仮定しましょう。
セキュリティソースコードのレビューよりもブラックボックス侵入テストを好む正当な理由はありますか？私の意見では、ソースコード監査は、ブラックボックス侵入テストよりもはるかに迅速かつ効率的に重大な脆弱性を識別します。セキュリティ構成の専門家がシステム構成やソースコードなどの内部情報を提供して、彼の努力をより適切に指示できるようにするために、なぜセキュリティの専門家にアプリケーションの暗闇の中でハンマーを叩かなければならないのですか？.
混乱を避けるために-セキュリティソースコードのレビューについて話すとき、私はセキュリティの専門家にアプリケーションのテストを実行させ、その結果を検証してさまざまな攻撃を試すことを許可することを想定しています。監査の目的は、弱点を特定し、後でアプリケーションのセキュリティを向上させることです。
一般に、ソースコードのレビューは、ブラックボックスペンテストよりも効果的です。 @Demento、あなたはその理由を明確に述べました。そして、これらの第一原理の正当化とは別に、経験的にソースコードをレビューすると、ブラックボックスペンテストよりも多くの脆弱性が見つかります。これは、ソースコードレビューがアーキテクチャリスク分析（マイクロソフトが脅威モデリングと呼ぶもの）と組み合わせる場合に特に当てはまります。
ブラックボックスペンテスティングの大きな利点は、かなり安価で専門知識が必要ないことです。これが、多くの人がブラックボックスペンテストを使用している理由の1つです。それははるかに安価であり、脆弱性のかなりの部分をキャッチしています。
個人的には、ソースコードレビューを使用する場合は、ブラックボックスペンテストと組み合わせることもお勧めします。ブラックボックスペンテストの費用は、ソースコードレビューの費用のほんの一部です。また、経験的データによれば、ブラックボックスペンテスト+ソースコードのレビューでは、どちらか一方だけの場合よりも多くのバグが検出されます。したがって、すでにソースコードのレビューを行っている場合でも、ブラックボックスペンテストの限界的なユーティリティはおそらく価値があります。