SASTテストを測定する3つのパラメーター

前回のブログ「リスト、テストスイート、ベンチマークだけではSASTツールを比較できない理由」では、現在SASTテストツールの評価や比較によく使われるさまざまなツールや指標を取り上げました。また、そうしたツールで一貫性のない結果が生じる理由や、SASTテストツールの評価に必ずしも信頼できるとは限らない理由についても説明しました。

SASTテストツールを評価する際は、次の3つのパラメーターを検討しましょう。

• 精度

• 完全性

• 独自の付加価値

このブログでは、これらのパラメーターとその測定方法を解説します。SASTテストツールの評価には、定量的な測定（結果の数と「ノイズ」の比較）と定性的な測定（特に言語の深さとサポート）という2種類の指標が関係します。

定量的な側面

精度と完全性の定義は、実は表裏一体であるため、最初は少し複雑に感じるかもしれません。Riceの定理によれば、完全な静的プログラム解析は数学的に不可能です。提案の数を増やせば、あらゆる問題を検出できると思うかもしれません。しかし残念ながら、それに伴って誤検知（FP）も増え、ノイズが大きくなりすぎて結果を活用できなくなります。SASTテストベンダーが結果を改善するための工夫はいくつかありますが、完璧を実現することは数学的に不可能です。

精度

SASTテストにおける精度とは、TP（真陽性、実際に問題がある検出結果）の数を最大化しつつ、FP（脆弱性ではない、つまり誤った検出結果）を最小限に抑える度合いを指します。

精度は特に重要です。精度が高ければ、実際に対処できる結果が増え、「ノイズ」（関連性がなく、対応につながらないレポート）が減ります。「ノイズ」は、開発者がSASTテスト製品を使わなくなる最大の要因でもあります。つまり、精度が高いほど、開発者にとって全体的な体験が向上します。

精度を計算するには、まず結果をトリアージする必要があります。計算式はTP*100/(TP+FP)です。この式により、1から100までの数値が得られます。数値が高いほど精度も高くなります。たとえば、TPを140件、FPを40件検出したツールの精度は77.7%です。

完全性

NISTの定義では、「完全性（再現率とも呼ばれる）とは、実際に検出された問題（TP）と、考えられるすべての問題（TPと偽陰性）の比率を測るものです。完全性が高いほど（理論上の最大値である1まで）、コード内に存在する問題をツールが網羅できていることを示します」。実際には、見逃された実際の問題、つまり偽陰性（FN）の数を指します。

ツールの完全性が高いほど、より優れた可視性と保護を得られます。もちろん検出結果も増える可能性がありますが、精度が高ければ、その多くは関連性のある結果となるはずです。ただし、完全性を考えるうえでは検出結果の深刻度も重要です。ノイズを最小限に抑えたい場合、深刻度の低いFNが1,000件あっても、必ずしも悪いとは限りません。一般的には、FNが少ないほど望ましいと言えます。また、実際の脆弱性を見逃さないために、FNを特定する方法を知っておくことも大切です。

この指標を算出できるのは、コード内の脆弱性を把握している場合、または複数のツールを比較して検出結果に差が見つかった場合に限られます。別の方法として、FNの深刻度を調べ、優先度の高いものに注目することもできます。FNは未知の問題であるため、測定が困難です。トレードオフは避けられません。経験上、複雑なプロジェクトではFNは常に発生するものと考える必要があります。サイバーセキュリティでは、安心しすぎて警戒を緩めることは決してできません。

定性的な側面

定性的な測定では、言語や脆弱性のサポートにどのように取り組んでいるかを評価します。前回のブログで説明したように、既知の脆弱性リスト、テストスイート、意図的に脆弱性を組み込んだリポジトリだけでは、全体像を把握できません。そのため、優れたSASTはリストだけにとどまりません。

この測定は、言語や脆弱性のサポートと、深さや精度への取り組みという2つの領域に分けられます。

言語サポートはどのように決まるのか

評価対象のSASTで、言語サポートの優先順位や対象がどのように決められているかを理解することが重要です。

脆弱性リストだけでは不十分であることは、すでにわかっています。より包括的なアプローチでは、複数の情報源からデータを集約し、最新のサイバーリスクに対応し、かつ文脈に即した堅牢な言語サポートを実現します。

リストも参考情報の1つですが、ほかにも確認すべき情報源があります。

• ニュースソース — 「トレンド」となっている脆弱性や新たに公開された攻撃手法は、悪用される可能性が高くなります

• NVD DatabaseやSnyk Vulnerability Databaseなどの既知の脆弱性データベースやエクスプロイトデータ

• 言語やフレームワーク固有のベストプラクティスとコンテキスト

• 新しいパターンや既存のパターンなど、ゼロデイ脆弱性に関する調査

Snyk Codeでサポートする言語やフレームワークを決める際には、上記を含むさまざまな情報を活用し、お客様が注目すべき、最も関連性の高い問題のリストを作成しています。

言語サポートの深さと精度にはどう取り組んでいるのか

幅広い言語と脆弱性をサポートすることは重要な第一歩ですが、そのサポートが実際の検出結果にどれだけ反映されているかも考慮する必要があります。

たとえば、厳格なレビュープロセスがほとんど、あるいはまったくない状態で、オープンソースコミュニティに新しいルールの作成と公開を任せているSASTは、FPが多くなりやすく、言語や脆弱性によって結果に一貫性がないことも少なくありません。

Snyk Codeでは、専任のセキュリティリサーチャーチームが、より多くの言語や脆弱性へのサポートを継続的に追加するとともに、深さと精度を高めて既存のサポートも強化しています。

SASTの開発速度とメンテナンス状況

前述のとおり、SASTソリューションのメンテナンスと継続的な開発は重要です。これは、製品のロードマップと、それを実現する企業やコミュニティの能力という2つの側面に関わります。機械学習の近年の進歩が、ロードマップにどう生かされているかも注目すべき点です。また、最新の言語への対応、最新のエンジンの採用、新しい言語を追加する速度も重要です。

次に、企業やコミュニティがSASTのナレッジベースをどの程度維持できるかを把握することが重要です。前述のとおり、セキュリティを確保するには、常に状況を監視し、さまざまな情報源に対応する必要があります。

すべてを総合すると

定量的な評価では、ツールが実際の環境でどのような結果を出すかを把握する必要があります。言語や脆弱性のサポートが優れていても、検出結果が多すぎたり（TPであっても）、反対にノイズ（FP）が多かったりすれば十分ではありません。セキュリティの専門家は高い完全性を求めますが、開発者がより重視するのは、具体的な対処につながる実践的なアドバイスです。そのため、提案の数、優先順位付け、開発チームが対処できるかどうかのバランスが重要です。私たちの経験と調査によると、提案が多すぎると（特に精度が低い場合）、開発者の意欲を損ない、プロセスをかえって遅らせます。

定性的な観点からは、環境内で重視する項目をリストアップしてマトリクスを作成し、各競合製品の値を記入することをおすすめします。

定量的な特性を測定する際は、よく把握している実際のプロジェクトを選ぶことをおすすめします。手軽に評価するには、小規模から中規模程度のプロジェクトが適しています。前回のブログで触れたように、意図的に脆弱性を組み込んだアプリは、ツールの実際の価値を示すとは限らないため、使用を避けましょう。

SASTを実行して結果を受け取ったら、次はトリアージです。トリアージとは、各結果がTP（実際の問題）かFP（実際の問題ではない）かを判断することです。SASTの結果はコンテキストに左右されることが多いため、スキャン対象のプロジェクトをよく理解しておくことが重要です。結局のところ、事前に用意されたベンチマーク結果で、あなたの専門知識や作業を置き換えることはできません。

最後に、この記事で前述した計算式を使って精度と完全性を算出します。

すべてのツールを集めて実行すればよいのでは？

前述のとおり、どのツールもTPとFPを検出します。可能な限りすべてのツールを使うのがよさそうに思えますが、実際にはノイズを仕分ける作業が、ツールを追加する価値を上回ってしまいます。開発者は、異なる形式で出力される複数のツールの重複した提案に対応する必要があり、実行時間の制約に加えて大きな負担が生じます。FNやFPの数を把握するには有効な方法ですが、継続的な運用には現実的ではありません。私たちの経験では、開発者に使いやすいプラットフォームが最も重要です。セキュリティ要件が非常に厳しい環境や規制対象の環境であれば、CI/CDプロセスの後半で専門ツールを追加するとよいでしょう。

SASTは間違いなく、すべての開発者が「ツールボックス」に加えるべき強力なツールであり、アプリケーションセキュリティに大きな違いをもたらします。だからこそ、自分や組織に最適なツールを選ぶことが重要です。この記事と前回のブログで紹介した情報や手順が、より適切な判断に役立てば幸いです。