TOSSS: a CVE-based Software Security Benchmark for Large Language Models

この論文は、CVE データベースに基づき大規模言語モデル(LLM)が安全なコードと脆弱なコードを区別する能力を測定する新しいベンチマーク「TOSSS」を提案し、14 種類のモデルを C/C++ および Java で評価した結果、セキュリティスコアが 0.48 から 0.89 の範囲に分布することを示しています。

Marc Damie, Murat Bilgehan Ertan, Domenico Essoussi, Angela Makhanu, Gaëtan Peter, Roos Wensveen

公開日 Thu, 12 Ma
📖 1 分で読めます☕ さくっと読める

Each language version is independently generated for its own context, not a direct translation.

この論文は、**「AI(大規模言語モデル)が本当に『安全なコード』を書けるのか、それとも『危険なコード』を生成してしまうのか」**を測る、新しいテスト方法「TOSSS」を紹介するものです。

難しい専門用語を使わず、身近な例え話で解説しますね。

🕵️‍♂️ 物語の舞台:「AI 助手」と「セキュリティの壁」

今、世界中のエンジニアは「AI 助手」を使ってプログラミングをしています。まるで優秀な新人アシスタントが、あなたの指示でコードを書き起こしてくれるようなイメージです。

しかし、ここに大きな不安があります。
「そのアシスタント、本当にセキュリティに詳しいの?バグや穴だらけのコードを書いて、ハッカーに狙われやすくなったりしない?」

これまでの研究では、AI に「新しいコードを書いてみて」と指示し、その結果を専門のツールでチェックしていました。でも、これには2 つの大きな問題がありました。

  1. 更新が面倒: 新しいタイプの「ハッキングの穴(脆弱性)」が見つかったら、テストのルールを全部作り直さなきゃいけない。
  2. 判定が難しい: AI が書いたコードが「完璧なコード」なのか「穴だらけのコード」なのか、自動で判断するのが難しかった。

🎯 解決策:「TOSSS」という新しいゲーム

そこで著者たちは、**「コードを作るゲーム」ではなく、「コードを選ぶゲーム」**に変えてみました。これが「TOSSS」です。

🍎 例え話:「毒入りリンゴと安全なリンゴ」

Imagine(想像してみてください):
あなたは AI に、**「A と B、どっちのリンゴを食べたい?」**と聞きます。

  • A:実は中が腐っている(=セキュリティの穴があるコード)
  • B:新鮮で安全なリンゴ(=安全なコード)

AI は「A」か「B」のどちらかを選ぶだけです。

  • 安全な方を選べば「○」
  • 腐った方を選べば「×」

これを何百回も繰り返して、**「AI が安全な方を選べる確率」**を点数(0〜1)で出します。

  • 1.0:常に安全な方を選ぶ(完璧なセキュリティ意識)
  • 0.5:ただの運(サイコロを振っているのと同じ)
  • 0.5 未満:危険な方を選んでしまう(ハッカーの味方?)

🛠️ なぜこれがすごいのか?(3 つのメリット)

この「選ぶゲーム」には、これまでの方法にはないすごい特徴があります。

  1. 自動でアップデートできる(伸縮自在)
    • 世界のセキュリティニュース(CVE というデータベース)に新しい「穴」が見つかったら、その「穴」と「修理されたコード」のペアを自動的に集めて、テストに追加できます。まるで**「新しい問題が出たら、すぐに新しい問題集を追加できる」**ような感じです。
  2. 大量にテストできる(スケールする)
    • 人間が一つずつチェックする必要がなく、AI が瞬時に「A か B か」を選べるので、何千ものテストを簡単にこなせます。
  3. 結果がわかりやすい
    • 「安全なコードを選ぶ確率が 8 割」という数字が出れば、誰でも「この AI は 8 割の確率で安全な判断ができるんだな」と直感的にわかります。

📊 実験の結果:AI はどうだった??

著者たちは、14 種類の有名な AI モデル(GPT や Claude など)にこのテストを行いました。

  • 結果の幅: 最高で0.88(ほぼ完璧)、最低で0.48(ほぼランダム、あるいは危険な方を選んでしまう)と、AI によって実力差が激しかったです。
  • ヒントの効果: 「どちらが安全な方か選んでね」と明示的に指示すると、多くの AI の成績が向上しました。つまり、AI も「あ、これはセキュリティの話なんだ」と気づくと頑張るようです。
  • 意外な事実: 「コーディングに特化した AI」が、必ずしも「安全なコードを選ぶのが得意」とは限りませんでした。逆に、コード生成に特化しすぎているせいで、セキュリティを軽視してしまう AI もいました。

💡 結論:何ができるようになったの?

この研究は、**「AI にコードを書かせる前に、まずは『安全なコード』を見分けさせるテスト」**を提案したものです。

  • 企業にとって: AI を導入する前に、このテストで「セキュリティ点数」をチェックすれば、危険な AI を選んでしまうリスクを減らせます。
  • 開発者にとって: AI に指示を出すとき、「安全なコードを選んで」と一言添えるだけで、より安全な結果が得られることがわかりました。

つまり、**「AI がハッカーの味方にならないよう、安全なリンゴを選べるか、いつもテストしてチェックしましょう!」**というのが、この論文が伝えたいメッセージです。


要約:
AI のセキュリティ能力を測る新しい「テスト」を作りました。それは「コードを書く」のではなく、「安全なコードと危険なコードのどちらを選ぶか」を問うゲームです。これなら、新しいハッキングの手口が出てもすぐにテストを追加でき、AI が本当に安全な判断ができるかが、わかりやすい点数でわかります。