テストの方法
ベンチマークの価値は、その設定次第です。ここでは、モデルが実際の脆弱性を検出できるかどうか、またそのコストはどれくらいかを、どのように測定しているかをご紹介します。
-
1
実際の脆弱性を選ぶ
GitHubのアドバイザリデータベースから、さまざまな言語やプロジェクトタイプにわたる既知のCVEを抽出しています。
-
2
脆弱性のあるコミットをピン留めする
各リポジトリは、修正される直前のコミットからチェックアウトされます。
-
3
本番環境用ハーネス内で実行する
モデルは、Code Security Auditおよび Aikido Attackに同梱されているAIハネス内で実行されます。
-
4
問題のあるコード部分を指し示してください
各脆弱性 がどこにあるかを把握しているため、調査エージェントは脆弱なコードを的確にターゲットにできます。外れがあったとしても、それは推論の誤りによるものであり、リポジトリの誤った箇所をさまようことで予算を無駄にしているわけではありません。プロンプトは簡潔に保たれ、モデルに依存しません。
-
5
3回実行し、その結果をまとめてください
モデルは非決定論的です。各モデルを3回実行し、いずれか1回の実行でCVEが検出されれば、そのCVEは発見されたものとみなします。この集約処理により、1回の実行だけでは見逃されてしまうバグも検出できるようになり、エージェントの実際の展開状況をより現実的に反映することができます。
-
6
スコア範囲と費用を合わせて
各モデルが再発見したCVEの数と、そこに至るまでのコストを記録しています。なぜなら、最も強力なモデルが必ずしもコストパフォーマンスに優れているとは限らないからです。また、ベンダーが公開している場合は、推論の階層についても比較を行っています。
ハーネスのセットアップについて
ハーネスこそが、言語モデルを監査役へと変えるものです。汎用的なコーディングアシスタントは、タスクを受け取って動作するコードを生成するという、別の目的のために構築されています。リポジトリを指定して「これは安全か」と尋ねると、それは開発者のように明らかに不具合のある箇所をざっと探し回り、もっともらしい問題が見つかった時点で調査を停止します。 Aikido's Code Security Auditは、これとは異なる仕組みで構築されています。コードベースから候補となる侵入ポイントを探索し、不審なフローを一つひとつ詳細に調査した上で、その結果を精査し、真の脆弱性のみを抽出します。
脆弱性 把握していたため、調査担当エージェントをすべて、脆弱性のあるコードスニペットに直接向けました。そうすることで、見落としがあった場合でも、それは推論の誤りによるものであり、コードベースの誤った箇所をさまようことで予算を無駄にしたことにはなりません。モデルは依然としてフローを理解し、悪用可能性を判断し、それを正しく報告する必要があります。プロンプトは短く、モデルに依存しないものに統一したため、表現の仕方によって特定のベンダーが有利になることはありませんでした。
これらを動かすためのハーネスが欲しいですか?
ここでベンチマークを行っているのと同じ「AI Code Security Audit」エンジンが、コードベースを分析し、リリース前に多段階の脆弱性を検知します。
コードセキュリティ監査について詳しく見る ↗