CASTLE: 静的コードアナライザおよび LLM の CWE 検出に向けたベンチマークデータセット
CASTLE: 静的コードアナライザおよび LLM の CWE 検出に向けたベンチマークデータセット
この記事は以下の論文をもとに書かれたものです。
TL;DR
ソフトウェアセキュリティの世界では、脆弱性検出ツールの性能評価が重要課題。本記事では、静的解析ツール、形式検証ツール、LLMの脆弱性検出能力を比較するためのベンチマークフレームワーク「CASTLE」について解説します。LLMは小規模コードでは驚くほど高性能ですが、大規模コードでは性能低下。静的解析ツールは偽陽性が多く、形式検証ツールは特定の脆弱性タイプに強いという特徴があります。複数ツールの組み合わせが最も効果的という結論に。
はじめに:セキュリティツール選びに苦しんだ経験
セキュリティに関わる開発をしていると、「どのコード解析ツールを使えばいいんだろう?」と悩むことがあります。私自身、以前あるプロジェクトで静的解析ツールを選定する際に、各ツールの検出能力や偽陽性の多さに頭を悩ませた経験があります。特に最近は大規模言語モデル(LLM)がコード生成だけでなく脆弱性検出にも使われるようになり、選択肢がさらに増えています。
そんな中、最近発表された「CASTLE」というベンチマークフレームワークが、この問題に光を当てています。CASTLEは、Common Weakness Enumeration (CWE) の検出能力を評価するための包括的なベンチマークで、静的解析ツール、形式検証ツール、そしてLLMの性能を公平に比較できるようにしたものです。
今回は、このCASTLEベンチマークの概要と、それによって明らかになった各種ツールの強みと弱みについてまとめてみました。
CASTLEベンチマークとは何か
CASTLE(CWE Automated Security Testing and Low-Level Evaluation)は、ソースコード中の脆弱性を検出するための様々なツールの性能を評価するためのベンチマークフレームワークです。
従来のベンチマークには以下のような問題がありました:
- CWEカテゴリの不均衡な表現
- 脆弱なサンプルと非脆弱なサンプルの不均衡な分布
- コンパイルできないプログラムが多い
CASTLEはこれらの問題を解決するために、以下の特徴を持つデータセットを提供しています:
- 25種類のCWEを網羅する250個のCプログラム
- 各CWEに対して脆弱性あり6個、脆弱性なし4個の均等な分布
- すべてのプログラムがコンパイル可能
- 単一ファイルで構成され、1つのプログラムに1つの脆弱性のみを含む
CASTLEスコア:新しい評価指標
CASTLEでは、ツールの性能を評価するための新しい指標「CASTLEスコア」を導入しています。この指標は以下の要素を考慮しています:
- 真陽性率(実際の脆弱性をどれだけ検出できたか)
- 偽陽性率(脆弱性がないのに誤って検出したケース)
- 影響の大きい脆弱性(Top 25 CWEに基づく)の検出に対するボーナス
- 脆弱性のないコードの正しい識別に対する報酬
これにより、単純な合否評価よりも細かくツールの信頼性を評価できるようになっています。
評価されたツールの種類
CASTLEベンチマークでは、以下の3種類のツールが評価されました:
-
静的解析ツール(SAST): 13種類
- CodeQL、SonarQube、Semgrep など
-
形式検証ツール: 2種類
- ESBMC、CBMC
-
大規模言語モデル(LLM): 10種類
- GPT-03-Mini、GPT-01、DeepSeek R1 など
評価結果:各ツールの強みと弱み
静的解析ツール(SAST)
静的解析ツールの中では、CodeQLが最も高いスコアを獲得しました。脆弱性の29%(45/150)を検出できましたが、偽陽性も多く報告されました。SonarQubeも同じく29%の検出率でしたが、CodeQLよりも2.7倍多い偽陽性を報告したため、全体的な評価は下がっています。
静的解析ツールの特徴:
- 中程度の検出能力
- 偽陽性が多い
- 大規模コードベースでも比較的効率的に動作
形式検証ツール
形式検証ツールでは、ESBMCが最も高いスコアを獲得しました。形式検証ツールの特徴は、偽陽性が少ないことです。理論的には、有界モデル検査器は常にその結果に対する反例を提供するため、偽陽性を生成することはないはずですが、ESBMCは3つのカテゴリで32の偽陽性を示しました。
形式検証ツールの特徴:
- メモリ安全性などの特定の脆弱性タイプに強い
- 偽陽性が少ない
- SQLインジェクションなどの高レベルの脆弱性は検出できない
- 大規模コードでは状態爆発などの問題が発生しやすい
大規模言語モデル(LLM)
LLMは、小規模なコードスニペットでは驚くべき性能を示しました。特にGPT-03-Miniは、150個の脆弱性のうち126個を正しく識別し、977ポイントという最高のスコアを達成しました。
しかし、予備実験では、コードサイズが大きくなるにつれてLLMの性能は低下することが示されています。400行以上のコードでは、偽陽性が増加し、隠された脆弱性を検出する能力も低下しました。
LLMの特徴:
- 小規模コードでは非常に高い検出能力
- 大規模コードでは性能が低下
- ハルシネーション(幻覚)の問題がある
- コンテキスト理解の限界がある
ツールの組み合わせ効果
CASTLEの興味深い発見の一つは、単一のツールよりも複数のツールを組み合わせた方が良い結果が得られるということです。特に、ESBMCとCodeQLを組み合わせると、814ポイントという高いスコアが得られました。
これは、異なるツールが互いの弱点を補完し合うためです。例えば、形式検証ツールはメモリ安全性の問題に強く、静的解析ツールはSQLインジェクションなどの高レベルの脆弱性に強いという特性があります。
ただし、単純に多くのツールを組み合わせれば良いというわけではありません。重複する検出は偽陽性を増大させる可能性があるため、相補的な検出戦略を持つツールの組み合わせが重要です。
実際のコード例で見る脆弱性検出
CASTLEベンチマークのデータセットには、様々な脆弱性を含むコード例が含まれています。例えば、以下はバッファオーバーフロー(CWE-121)の例です:
#include <stdio.h>
#include <string.h>
void process_input(char* input) {
char buffer[10];
strcpy(buffer, input); // {!LINE} バッファオーバーフローの可能性
printf("Processed: %s\n", buffer);
}
int main(int argc, char** argv) {
if (argc > 1) {
process_input(argv[1]);
}
return 0;
}
このような単純な例では、ほとんどの静的解析ツールとLLMが脆弱性を検出できますが、より複雑なケースでは検出率に差が出てきます。
CASTLEの限界
CASTLEベンチマークにも限界があります:
-
マイクロベンチマークの範囲が限定的
- 各テストは単一の脆弱性に焦点を当てているが、実際のソフトウェアはより複雑
-
大規模なコードサンプルが不足
- 予備実験では、LLMと形式検証ツールは大規模コードで性能が低下
-
潜在的な過学習の可能性
- ツールベンダーが既知のベンチマークに最適化する可能性
これらの限界を考慮すると、CASTLEの結果は参考にしつつも、実際のプロジェクトの特性に合わせてツールを選択することが重要です。
実務での活用方法
CASTLEの結果を踏まえて、実務でのセキュリティツール選定には以下のアプローチが考えられます:
-
プロジェクトの特性に合わせたツール選択
- 小規模プロジェクトではLLMの活用も検討
- 大規模プロジェクトでは静的解析ツールをベースに
-
複数ツールの組み合わせ
- 形式検証ツール + 静的解析ツールの組み合わせが効果的
- 偽陽性の管理方法も考慮する
-
LLMの活用方法
- コード補完時のリアルタイムガイダンスとして活用
- 小さなコンポーネント単位での脆弱性チェックに利用
個人的には、LLMをコード生成時の脆弱性防止ツールとして活用し、静的解析ツールでより包括的なチェックを行うという二段構えのアプローチが効果的だと思います。
まとめ
CASTLEベンチマークは、様々な脆弱性検出ツールの性能を公平に比較するための貴重なフレームワークです。その結果から、以下のことが明らかになりました:
- LLMは小規模コードでは驚くほど高性能だが、大規模コードでは性能が低下する
- 静的解析ツールは中程度の検出能力だが、偽陽性が多い
- 形式検証ツールは特定の脆弱性タイプに強いが、カバレッジが限定的
- 複数ツールの組み合わせが最も効果的
セキュリティツールの選定は、プロジェクトの特性や要件に合わせて行うことが重要です。CASTLEの結果は参考にしつつも、実際のプロジェクトでの検証も欠かせません。
今後、LLMの進化によって脆弱性検出の精度はさらに向上する可能性がありますが、現時点では単一のツールに依存するのではなく、複数のアプローチを組み合わせることが最も信頼性の高い方法と言えるでしょう。
以上。
Discussion