静的コードレビューのアプローチ
私の質問は、VeracodeとFortify/AppScanで使用されている静的コード分析アプローチに関連しています。
- Veracode –ソースを必要とせずに、アプリケーションバイナリとバイトコードのセキュリティ欠陥を検出します
- Fortify/AppScan-実際のソースコードを分析してセキュリティの脆弱性を特定します。
A）ソースコードよりもバイナリのレビューを行うことの利点/欠点はありますか？ B）どちらがより多くのカバレッジ/脆弱性を提供するか。 C）どんな例でもいいでしょう。
おかげで、
A）ソースコードよりもバイナリのレビューを行うことの利点/欠点はありますか？
多くの場合、コンパイラーはソースで意図されたとおりにコードを明示的に記述しません。たとえば、Return Oriented Programmingは、コンパイラーがプログラマーが認識しているよりも多くのRETオペコードを挿入するという事実を利用しています。パイプライン処理やその他の最適化トリックのために、コンパイラーは基本的にコードを書き直し、おそらく 独自の脆弱性を追加します。 これは、ソースコードの一部の構成がまったくバイナリで表現されます！
これは、本質的にimpossibleであるエラーのクラスであり、手動のコード分析を介してキャッチします...そして、Java/C＃JITコードについてもリスクが依然として存在すると思われますが、これは難読化されます静的分析ツール。
手動のソースコード分析は、mostの一般的な脆弱性を目視で確認できるため、役立ちます。また、その他の利点もあります。特に、一般的な製品バグの数を減らすだけです。 （したがって、コストがかかります。）そして、それは社会的な側面にも役立ちます。ソースレビューは、他の誰かが見ているかのように書くことを人々に促します。主な欠点は、Perl、Groovy、LISPおよびその派生物などの動的に型付けされた言語を処理している場合、ほとんどのデータは実行時まで見られない、つまりどちらでもない静的分析またはソースコード分析で十分です。
静的に型付けされたコードを実行時に命令に変換することで、静的分析ツールをだますこともできます。 VeracodeはあなたのJava構成を好きではありませんか？リフレクションを使用して書き直します。Veracodeバグは消え、誰も賢明ではありません。セキュリティの専門家として、あなたはプログラマーが自社は潜在的な脅威です。
したがって、簡単に言えば、希望どおりの安全なコードベースが望まれる場合、特定のアプリケーションでソースコード分析、静的分析、動的分析を回避する方法はありません。
B）どちらがより多くのカバレッジ/脆弱性を提供するか。
ソースコードの分析は、優れたセキュリティスキルを持つレビュアーに依存しています。レビュアーは人間であるため、完璧なパフォーマンスを期待することはできません。そのため、静的分析ツールが便利です。私の好みは、最初に静的分析ツールを実行し、次に安全なコードレビューを行うことですafter発見は軽減されます。これにより、人間はロジック関連の一般的ではないセキュリティ問題に集中できます。しかし、賢い人間は、平凡な静的分析ツールをいつでも倒すでしょう。
ソースコード分析は、プログラマーがバックドアを置き去りにした場所を見つけるのに役立ちます。静的分析ツールは、それを処理するために装備されていません。
したがって、この質問への答えは...「状況によって異なります」です。未確認のままにしたい脅威の種類は何ですか？
*「許容できる程度に安全」でない場合は、窓を開けたままにし、正面玄関のロックを解除することと定義されています。
これらについての本を書くことはできても、満足することはできません。特別な製品に名前を付けることなく、一般的にこれに答えてみましょう。
バイナリ/バイトコード分析
メリット
- （ほとんど）プログラミング言語にとらわれない
- どこからでも入手したクローズドソースのバイナリ/ライブラリで実行できます
- コンパイラーのバグ（またはソース言語の未定義の動作）によって導入された欠陥を見つけることができます
短所
- ハードウェアが急速に進化しているため、多くの場合、書き込み/保守が難しくなります（たとえば、インテルAVXをまだ理解していない可能性があります）
- 特定のアーキテクチャに限定（ほとんどのものがx86/x86_64で実行されるため、実際にはめったに問題にならない）
- マルチスレッドの同期構造は検出されても、検出されません。
ソースコード分析
メリット
- 多くの場合、見つかった欠陥を実際のソースコードまで追跡するのが簡単です。
- 通常、ツールは、物事がどのように連携するかについての「全体像」を見ることができます（例：ここに割り当てられたもの、そこに割り当て解除されたもの、そこから解放されてそこから読み取る可能性）
- 意味的に高いレベルでの分析を提供します（例：アセンブリレベルではシフトと加算の理解できない混乱である計算での整数オーバーフロー）
- ソースコードの注釈は、ツールが何が起こっているのかを理解するのに役立ちます（例：「信じてください、これは同期プリミティブなので、以下はアトミックであり、競合状態を心配する必要はありません」）。
短所
- ソースコードが利用可能である必要があります
- すべての言語を完全にサポートしていない可能性があります（C++テンプレートのメタプログラミング構造など）
- 後で実行されるマシンのプロパティ（整数のサイズなど）を正確にシミュレートできない可能性があります
- バイナリーとしてのみ使用可能であるか、システムによって異なるライブラリー依存関係には至りません。
カバレッジのレベル
これは、ツールの動作とほぼ直交しており、主にその製品の品質の尺度です。十分な努力を払えば、すべてのツールがあらゆる種類の脆弱性のすべてのチェックを実装できますが、だれも十分な人手がありません。より簡単なことが行われます。実行が難しいものは実装されない可能性があります。
まったく異なることに焦点を当てた2つのソースコード分析ツール（たとえば、1つは競合状態、もう1つはオーバーフロー）を使用できます。私はツール間で常にいくつかの重複があると確信していますが、2つのツールがまったく同じ種類の欠陥を見つけることはありません。
可能性がある場合は、できるだけ多く実行してください。まだ実行していないツールの1つでしか発見できないバグがあるかどうかはわかりません...
簡単に言えば、両方を使用することです。ハイブリッドまたは統合アプリケーションセキュリティテスト（IAST）は、バイナリとバイトコードの動的アプリケーションセキュリティテスト（DAST）と静的アプリケーションセキュリティテスト（SAST）を組み合わせて、アプリケーションの脆弱性の統一されたビューを作成します。目標は、脆弱性を見つけることだけでなく、開発者がそれらのエラーをすばやく特定、解釈、修正するのにも役立ちます。ハイブリッドツールは、静的分析を使用してDASTを超えるだけでなく、ソースコードの特定の行をポイントし、ツールの適用範囲を拡張します。さらに、IASTツールは、ソフトウェア開発者の悩みの種である誤検知を減らし、SASTの結果をライブテストします。 IASTは、SASTメソッドとDASTメソッドの両方の長所を利用して、それぞれに固有の弱点を相殺できます。たとえば、SQLインジェクションの動的テストでは、攻撃が実際にデータベースに到達したことを確認できます。 IASTは、コードを調べて攻撃対象を狭めることにより、テストを高速化します。ページがSQLを実行しない場合、SQLインジェクションについてページをテストする必要はありません。 IASTは、SASTを使用して、動的なテスト方法に隠されている可能性のあるコードの攻撃面を発見できます。
IASTツールの例としては、Aspect from Aspect、Quotium Technologies ’Seeker、Appscan Enterprise from IBM、Acunetix Web Vulnerability Scanner、HP WebInspect Real-Timeなどがあります。 Jeff Williamsのブログ投稿を参照してください 静的アプリケーションセキュリティスキャナーがもはやそれをカットできない理由 同様の質問を参照してください インタラクティブアプリケーションセキュリティテストの有効性
A）ソースコードよりもバイナリのレビューを行うことの利点/欠点はありますか？
私は通常、バイナリを「逆コンパイル/逆アセンブル」し、ソースコードの代わりにそれらを確認します。ソースコードにアクセスできないこともあります。異なる「ブランチ」や、コンパイルされたバイナリ（デッドコード）に含まれないソースが存在する可能性もあります。
B）どちらがより多くのカバレッジ/脆弱性を提供するかソースコードには、// TODOやコメントなどのヒントがあり、何かを実装する必要がある/弱点がある場合に役立ちます。バイナリにはありません。どちらにもメリットがあります。