コード分析：バイナリとソース
ソフトウェアのセキュリティ評価を行っているときに、コンパイルされたアプリケーション（C++など）のソースコードにアクセスできる場合、自動化された手法を使用して、または手動で、コンパイルされたバージョンの分析を行いますか？この状況で適用できる唯一のテクニックはファジングですか、それともバイナリを見ることに他の潜在的な利点がありますか？
アプリケーションの種類、配備モデル、特に脅威モデルなど、状況によって異なります。
たとえば、特定のコンパイラは一部のデリケートなコードを大幅に変更して、特定のチェックをバイパスするなど、コードには表示されますが（コードレビューは満たす）、バイナリには表示されず（現実のテストに不合格）、微妙な欠陥をもたらします。
また、特定のコードレベルのルートキットがあります-あなたはC++について言及しましたが、 managed code rootkits もあります。 .NETとJava-コードレビューを完全に回避しますが、デプロイされたバイナリに表示されます。
さらに、コンパイラ自体に特定のルートキットが含まれている場合があり、アプリにバックドアを挿入できるようになります。 （ 元のルートキット の履歴を参照してください-コンパイラは、ログインスクリプトにバックドアパスワードを挿入しました。「クリーン」なコードから再コンパイルすると、このバックドアもコンパイラ自体に挿入されました）。繰り返しになりますが、ソースコードにはありませんが、バイナリには存在します。
とはいえ、バイナリをリバースエンジニアリングすることはもちろんより困難で時間がかかり、すでにソースコードがある場合はmostシナリオでは無意味です。
私はこの点を強調したいと思います。ソースコードがある場合は、クリーンアップするまでREを気にしないでくださいallコードレビュー、ペンテスト、ファジング、脅威モデリングなどを介して発見した他の脆弱性。それでも、それが非常に機密性の高いアプリであるか、非常に目立つ場合にのみ問題になります。
Edgeケースは見つけるのが難しいほど、そしてまれに、あなたの努力が他の場所でよりよく費やされる可能性があります。
一方、特にバイナリをスキャンする静的分析製品（Veracodeなど）がいくつかあることに注意してください。そのため、それらの1つを使用している場合は、特に問題にはなりません...
@AviDソリッドポイント、バイナリ/コンパイラコンポーネントのルートキットに完全に同意します。
あなたが知識豊富なセキュリティ専門家である場合、AviDが作成する有効なポイントを脇に置いて、最も脆弱性はソースコードにある可能性が最も高いでしょう。安全なプログラミングとリバースエンジニアリングの実現に関する強力な知識があれば、ソースコードのほとんどの穴を修正/防止するための最良の方法が得られます。さらに、コンパイラ/バイナリのエクスプロイトが存在する場合、別のコンパイラ/言語を使用することを除いて、開発者がそれを防ぐためにできることは多くありません（通常、実行可能なオプションではありません）。
セキュリティ関連の問題以外にも、最終的なバイナリを調べる理由はたくさんあります。デバッガー、逆アセンブラー、またはプロファイラーとValgrind（コンパイルされたプログラムのさまざまな側面を検証できる）のようなエミュレーターのいずれかを使用します。
プログラムのセキュリティと正確性は、通常、密接に関連しています。
私にとっては、最初にコードをリンティング（つまりPCLINTを使用）してから、バイナリを構築し、これらをファザーとmemcheck（Valgrindから）で検証して、堅牢性と信頼性に関して非常に良い結果を得ました。この場合、PCLINTのみがソースコードにアクセスできます。
バイナリとソースコードの分析は少し異なる観点を与えるので、それらの両方を適用する必要があります。ただし、バイナリ分析は人間にとって恐ろしいものです。ソースコードレベルでの分析はイライラすることはありませんが、アセンブリレベルでのアプリケーションのロジックの分析は、最良の選択ではありません。バイナリ分析では、実際に何が起こっているのか、そうでなければできないことに対処します。ソースコードでいくつかの仮定を行うことができる場合、ここに明確な状態があります。
ただし、ファジングなどのテストは、コンパイルされたアプリケーションに対して実行して、少なくともある程度のレベルでアプリケーションの堅牢性を確保する必要があります。コードカバレッジは、ファジングの方法論、アプリケーションの詳細、およびその他のいくつかの要因に依存します。ここでは説明が多すぎて、ファジングの技術です。マイクロソフトでさえファジング用のツールを開発し、 SDLで適用 します。ここにプロセスへの洞察としてのCodenomiconからの論文があります： http://www.codenomicon.com/resources/whitepapers/codenomicon-wp-sdl-20100202.pdf
AviDがほのめかされたがおそらく強調されるべき点があります。それは、コードレビューはバイナリレビューよりもはるかに時間と労力の効果的なプロセスになる傾向があるということです。特にC++では、平均的な開発者は言うまでもなく、平均的なセキュリティ専門家にとっても、バイナリを理解することは非常に困難です。
インタプリタ言語の場合、これはそれほど当てはまりません。難読化されていないJavaおよび.NETバイトコードは、かなり人間が読める形式に変換できます。
多くのセキュリティ機能は、コンパイルされたバイナリの分析が行われたときにのみ評価できるため、バイナリを確認することは常に必要です。たとえば、コードは、アプリケーションのロジックの脆弱性を示唆している可能性があります。コンパイルされたバイナリは、ASLRなどの特定のコンパイル機能やスタック実行可能ファイルが有効か無効かを通知します。この情報は、ソースコードを見ただけでは取得できません。ファジングは、一般に脆弱性をブルートフォースにするのに役立つテクニックですが、時間とリソースを大量に消費する可能性がありますが、ファジングに依存して問題を特定すると、誤った結果や見落としが生じる場合があります。そのため、バイナリを分析するには、radare2やhopperなどのリバースエンジニアリングツールも必要です。
バイナリとソースコードの分析を比較するこのリソースも見つけました、これは役立つはずです 
免責事項-私はAppknoxで働いています