侵入テストと安全なソースコードレビュー
最近、ある機関がビジネスアプリケーションを開発するためにサードパーティベンダーを雇ったという状況に遭遇しました。 侵入テストおよび独立したサードパーティの安全なソースコードレビューに関連する次の質問を思いつきました。
独立したサードパーティの安全なソースコードレビューの実施は、侵入テストとどのように異なりますか？
独立したサードパーティの安全なソースコードの制限とは
レビューと侵入テスト、およびそれらは互いにカバーし合いますか
制限がありますか？独立したサードパーティの安全なソースコードレビューがカバーする分野
どのペネトレーションテストがそうではなく、その逆ですか？
独立したサードパーティの安全なソースコードレビューの実施は、侵入テストとどのように異なりますか？
安全なコードレビューはホワイトボックスの方法論であり、コードレビューアーは自動ツールや手動のアプローチを使用して、特定のソースコードのセキュリティ問題を特定しますが、侵入テストは主に- ブラックボックス組織がテストするアプリケーションのIPアドレスまたは名前/ URLのみを提供する方法。侵入テストでは、セキュリティアナリストは通常、情報の収集から始めて、システムの脆弱性を特定します。その後、アナリストはテスト中のシステムを攻撃し、より多くのセキュリティ問題を特定し、特定された脆弱性の影響を評価するために、ますます深く侵入しようとします。
独立したサードパーティの安全なソースコードのレビューと侵入テストの制限は何ですか？また、制限されている場所で互いにカバーしますか？
それは、ベンダーとのエンゲージメントのタイプに完全に依存します。ほとんどの場合、それらは互いにカバーしません。私は個人的に、アプリケーションの侵入テストと安全なコードレビューの両方をお勧めします。安全なコードレビューは、静的なアプローチに近いものです。しかし、最新の安全なコードレビューツールは、動いているデータも分析される汚染分析などの動的な機能を提供しますが、私の個人的な経験によると、安全なコードレビューでは侵入テストの結果を達成できず、その逆も同様です。
独立したサードパーティの安全なソースコードのレビューがカバーしているペネトレーションテストは、どの領域をカバーしていますか？
すでに述べたように、両方のアプローチを使用してより良い結果を得ることができます。例を使ってもっとよく説明できればいいのにと思います。たとえば、サーバー側の安全なコードレビューには、パスワード管理チェックが含まれます。 MD5などの弱いハッシュアルゴリズムを使用してユーザーのパスワードをハッシュするシナリオ。このセキュリティ問題は、サーバー/コードアクセスが達成されていない場合、侵入テストで問題が特定されない可能性がある安全なコードレビューで特定されます。