静的分析ツールの評価基準
ツールの購入と同様に、結果の一部は評価基準がいかに優れているかにあるため、セキュリティ静的分析ツールを評価するときに人々が使用する可能性がある基準を理解することが重要です。
明らかに、各基準の重み付けは個々の企業の優先順位にまで及んでいますが、リストはかなり一般的である可能性があります。
適用される可能性があるいくつかの基準は次のとおりです。
コスト。このためのいくつかのコンポーネントは、ソフトウェアライセンス（前払いおよび年間）、ソフトウェアを実行するためのハードウェアコスト（SAASではないと想定）です。
スケーリング。ツールをより大きな環境に拡張する機能。具体的なポイントは、開発者間でのデータの共有、バグ追跡との統合、ソースコード管理システムなどです。
能力。言語カバレッジ、偽陽性/陰性率。
カスタマイズ。この種のソフトウェアの重要な領域は、評価されている特定のコードベースにカスタマイズする機能（たとえば、特注の入力検証ライブラリを考慮に入れる）、レポートやその他の出力をカスタマイズする機能です。
これが私のリストにあるもので、私がクライアントに使用しているもの（あなたが言及したものを含む）：
- カバレッジ（組織が今日必要としているもの、および将来使用する予定のもの）
- 言語
- アーキテクチャー（例：一部のツールはWebアプリに最適ですが、リッチクライアントやWindowsサービス/デーモンにはそれほどではありません）
- フレームワーク（MSPではなくASP.NETのサポート、またはJava Spring以外））
- 必要に応じて、標準ライブラリ（Hibernate、log4j、またはAntiXSSを認識して、問題のあるライブラリをいくつか挙げます）
- スキャン性能。これに私は両方を含みます：
- 速度
- 大きなコードベース（LoC、サブシステム/プロジェクト、外部参照を含む）への拡張性
- 完全性-つまり、スキャンに含まれるルール/スクリプト。出力の信頼性を提供するのに十分です。つまり、偽陰性を最小限に抑えます。
- これは両方とも提供されたルールのリストであることに注意してください（たとえば、「SQLインジェクション」のチェック）。
- ANDこれらのチェックの品質、つまりSQL注入を実際にキャッチします。 （例として、名前のないままでいるこの分野の特定のリーダーは、多くの形式のコードフローによって簡単に混乱する可能性があり、そのため基本的な注入の欠陥がありません。）
- 結果の精度。これは、報告されている結果に適用されます（欠落している結果とは対照的に、「完全性」でカバーされています）。精度の低下は次の場所で確認できます：
- 多数の誤検知
- 重複
- 誤分類
- 優先順位付けの誤り（例：影響が非常に小さいバグを「高リスク」としてラベル付け）
- 無関係な結果（つまりisであるコードの欠陥）アプリケーションまたはアーキテクチャにはまったく関係ありません（例：非HTML、非HTTPでXSSを見つける） 、非対話型アプリ、またはクライアントアプリケーションでのSQLインジェクション）。
- カスタマイズ可能性-言ったように、ソース、シンク、およびフィルターをカスタマイズします。また報告する;また、ルール/スクリプトのカスタマイズとカスタムロジックの追加（ソース->フィルター->シンクだけでなく）も同様です。多くのツールではルールを「カスタマイズ」できますが、これは実際にはソース/シンク/フィルターの追加に限定されていますのみ。
- 持続可能性/繰り返し性-これにより、繰り返しスキャンの処理について言及します。変更はどのように処理されますか？以前に誤検知としてマークされた問題？比較はできますか？
- 導入モデル、例：通常は次の組み合わせです：
- 単一の監査ステーション
- リモート経由でアクセスされる共有サーバー
- webアクセス
- 開発者プラグイン
- サーバーのプラガビリティを構築する
- （もちろん、それぞれに異なるポリシーを設定する機能）
- 使いやすさ。これも：
- UI（ホットキーなどを含む）
- 監査フィルター機能
- コードフローを十分に強調することで十分なコンテキストを提供する
- 説明、説明、修正、外部ソースへのリンク、OWASP/CWEのIDなどの静的テキスト.
- 追加のユーザー機能-例手動の結果（自動スキャンでは見つからない）を追加できますか？
- レポーティング-必要に応じてプロジェクトごとに柔軟（開発者向けの詳細とマネージャー向けの高レベルを忘れないでください）、および集約されたクロスプロジェクト。比較なども.
- セキュリティ（サーバーモデルの場合）-データの保護、権限の管理など（他のサーバーアプリと同じように...）
- コスト。これには少なくとも以下が含まれます：
- ハードウェア
- ライセンス-次のいずれかまたはすべて：
- 座席あたり-監査人
- シートあたり-開発者
- シートあたり-ユーザーを報告
- サーバーごと
- プロジェクトごと
- コードの行ごと
- サイトライセンス
- メンテナンス
- サービス-例デプロイメント、チューニング、カスタム統合など
- トレーニング（トレーナーと監査人/開発者の両方の時間）
- Integration with：
- ソース管理
- バグトラッカー
- 開発環境（IDE）
- ビルドサーバー/ CI/CD
- オートメーション
これを見てみると、基本的な要件から、適用性、品質、展開の容易さ、効率、使いやすさまで、好みの順であると思います。
静的分析ツールを評価する方法について知っておくべき最も重要なことは次のとおりです。
独自のコードで試してください。
もう一度繰り返します。独自のコードで試してください。試用版を実行する必要があります。試用版を使用して自分の代表的なコードを分析し、その出力を分析します。
その理由は、静的分析ツールの有効性は大きく異なり、その有効性は会社でどのようなコードが記述される傾向があるかに依存するためです。したがって、あなたの会社に最適なツールは、他の会社に最適なツールと同じではない可能性があります。
機能一覧で行くことはできません。ツールがJavaをサポートすると言っているからといって、それが分析に優れているJavaコード-またはJavaコードと気になる問題を見つける。
ほとんどの静的分析ベンダーは、無料の試用版の設定を喜んでサポートしてくれるので、独自のコードで自社のツールを試すことができます。
Gary McGrawとJohn Stevenが セキュリティ静的分析ツールの選択方法に関する優れた記事 を書いています。自分のコードでツールを試してどちらが最適かを確認する必要があるという点に加えて、環境やニーズに合わせてツールをどの程度適切にカスタマイズできるか、およびそのための予算を考慮する必要があることも指摘しています。費用。
基準の長いリストは、良い解決策を思い付くのと同じくらいあなたをそらす可能性があります。
たとえば、「誤検知」の問題を考えてみましょう。これは、そのようなツールに固有の問題です。長期的な解決策は、彼らと暮らす方法を学ぶことです。これは、プログラマーが静的分析ツールの周りのコーディングを学び、それが誤検知をトリガーする原因を学び、誤検知がトリガーされないように別の方法でコードを書く必要があることを意味します。 lintを使用する人、またはコードをウォームフリーでコンパイルしようとする人によく知られているその手法：誤検知がトリガーを停止するまでコードを微調整します。
最大の基準は、解決しようとしている問題を理解することです。プログラマーに静的アナライザーを1回実行し、コードの最大の問題を取り除き、プログラミングについてすでに知っておくべきことを正直に学び、それらの間違いを犯さないようにすることは、プログラマーに大きなメリットがあります。しかし、継続的に実行される静的アナライザーの限界値ははるかに少なく、限界コストははるかに高くなります。
私は長年にわたってC++コードでGimpelのPC-Lintの大ファンでした。私にとって最大の2つの要因は、言語のカバレッジ（当時、他の誰もそれを持っていなかった）と「居住性」でした。ご存じのように、静的分析を行うことは、主観的なことです。 Gimpelのマニュアルには「Lint with Lint」と呼ばれる章があり、さまざまな浮き沈みをうまく話し合っています。住みやすくするためには、出力される警告とエラーをカスタマイズする機能がありますが、開発者がそれに夢中になって作業することはありません。
スケーラビリティに関連して、サードパーティのコード（ライブラリなど）に対応できない分析ツールで問題が発生したため、大きなプロジェクトでは、これも考慮事項です。