サードパーティコードのセキュリティレビュー
社内で開発したアプリケーションの本格的な情報セキュリティレビューのすべての手順に精通していないため、次のシナリオが一般的かどうか疑問に思っています。
Webアプリケーションが作成され、Microsoftの.NETフレームワーク上で実行されます。
セキュリティレビューの条件に基づいて、社内で記述されていないコードとしてここで定義されているすべてのサードパーティコードをレビューする必要があります（ただし、これは正しいか間違っているかを問わず）。
したがって、.NETスタックの上に書かれた社内コードだけでなく、.NETスタック自体も監査する必要があります。したがって、コードの最初の監査以外に、Microsoftの更新も監査する必要があります。たとえば、アプリがMVC 5.2を使用していて、MicrosoftがMVC 5.3をリリースし、アプリがMVC 5.3にアップグレードされたとします。この場合、（他のテストの中で）MVC 5.3コードベース自体が監査/レビューを実行するまで、アプリはレビューに合格できませんでした。
これは通常の情報セキュリティレビューの一部ですか？
Microsoftスタックでアプリをビルドするときに、Microsoft独自のコードベースのセキュリティレビューを実施するのは標準的な方法ですか？
内部監査およびレビュープロセス（サードパーティのツールを使用）が、Microsoft自体が実行するテストよりも洗練されていると想定するにはどうすればよいでしょうか。
そして、このサイクルはどこで止まりますか？サードパーティのツールや内部テストは標準に達していると誰が言っているのですか？私はそれらのプロセスの監査もあるはずだと思います。そして、それらの監査の監査...等々など。ある時点で、これは停止しなければならず、信頼のレベルが必要ですよね？
Microsoftスタックでアプリをビルドするときに、Microsoft独自のコードベースのセキュリティレビューを実施するのは標準的な方法ですか？
いいえ。理由の1つは、リバースエンジニアリングを行わない限り、プロプライエタリ（Windows、IIS、.Net、パッチ）コードにアクセスできず、その努力がメリットを上回ることです。
一般的なアプローチは、信頼できるサードパーティを定義し、リスクを受け入れることです。サードパーティコンポーネントの100％をカバーしたい場合は、.Net、Windows、デバイスドライバー、ファームウェア、BIOSだけでなく、ハードウェアも確認する必要があります。
いいえ、特定のコードが何をしているかを正確に確認したい場合は、デバッガで.netサポートライブラリの大部分をウォークスルーできますが、通常はこれを行いません。バイナリを操作できる静的コード分析を使用して一部のライブラリをスキャンできる場合がありますが、評判の良い大規模なベンダーの場合、すでにこのテストまたは同様のテストを行っているため、小規模なベンダーにはない場合があります。
最終的には、コードの使用に関連するリスクを判断するために、ベンダーの認定、ホワイトペーパー、契約、評判、および安全な開発方法を確認する必要があります。たとえば、それぞれがもたらすリスクに基づいて、特定のオペレーティングシステムを選択することはできますが、どちらのソースコードもすべて確認することはできません。