コーディングにおいてどのAIモデルが最良か最悪かを一概に決めることはできませんが、開発環境やフレームワークによっては、組織にとって明らかに優れたモデルと、明らかに劣るモデルが存在します。
ソフトウェアガバナンス企業のSecure Code Warriorは本日、大規模言語モデル(LLM)搭載のコーディングツールによって生じるリスクの定量化を試みたデータ集「AI Trust Index」を発表しました。AIを活用した開発は組織レベルで爆発的に普及しており、コード生成、脆弱性テスト、全体的な整合性の監査などにツールが使われています。こうしたツールが高コストである一方で、効率化のメリットにかかわらず脆弱性やリスクを新たに持ち込むことも、もはや周知の事実です。
だからといって組織がAIコーディングツールを避けるべきだという意味ではありませんが、飛び込む前にリスクと緩和策を把握しておくべきであることは間違いありません。
こうしたリスクを具体的に示すため、AI Trust Index(専用ウェブサイトとして公開)は、RMIT大学と共同で構築した手法をもとにSecure Code Warriorが発表しました。研究チームは、OpenAI、Anthropic、Googleなどのベンダーが提供する16の最先端モデルによって生成された、合計1,760件の完全なコードベースを評価しました。
AI生成コードには、コードベース1件あたり平均15件の確認済み脆弱性が含まれており、そのうち4.3件は重大または高深刻度に分類されるものでした。全コードベースを通じて確認された脆弱性の総数は27,000件を超えました。
AIコーディングに明確な勝者なし
研究チームは、各モデルが生成したコードのテストで検出された脆弱性の少なさを、他モデルとの相対評価により0から100の信頼スコアとして評価しました。
主要ベンダー間では、普遍的な勝者は存在しませんでした。Anthropicの2つのClaudeモデル(Sonnet 5とFable 5)が最高スコア(それぞれ80.4と76.4)を記録した一方、OpenAIのGPT 5 Miniは最下位(21.6)に沈みました。全体としては、OpenAI、Anthropic、Googleの各社の最先端モデルが、リストの上位と下位の両方に散らばる結果となりました。
とはいえ、報告書によれば各AIモデルにはそれぞれ固有のセキュリティ上の「指紋」があることが判明しました。「評価したすべてのフレームワークにおいて、モデルはランダムな失敗ではなく、繰り返し現れる脆弱性パターンを一貫して示しました。SCW AI Trust Indexは、各モデルがOWASP脆弱性カテゴリーの再現性あるパターンを生み出すことを示しており、組織はセキュリティ上の弱点が最も生じやすい箇所をあらかじめ予測できるようになります」と報告書は述べています。
最も注目すべき点は、モデルの性能の高さがフレームワークによって大きく変動することです。Secure Code Warriorの調査によれば、あるフレームワーク(DjangoやReactなど)で好成績を収めたモデルが、別のフレームワークでは平凡な結果に終わったり、対策そのものを完全に見落としたりすることがあります。例えば、Claude Opus 4.8はDjangoでテストした際にTrust Indexスコア100を獲得しましたが、C-Basicではわずか57.3、C#-Basicでは28.5にとどまりました。
結局のところ、俯瞰的な全体の信頼スコアよりも、どのモデルをどのフレームワークと組み合わせるかの方がはるかに重要であることが結果から示されました。今回のテストでは合計11の開発フレームワークが対象となりました。
研究チームはまた、モデルの利用コストとセキュリティの間にはほとんど、あるいは全く相関関係が見られないこと、最も多く見られたセキュリティ上の失敗は積極的に危険なコードによるものではなく、モデルが実施し忘れたこと(認証チェックや入力検証など)に起因していること、そしてリスクは全体としてランダムではなく予測可能であることを明らかにしました。具体的には、モデルとフレームワークの組み合わせによって、研究者が発見する脆弱性の数や種類がある程度予測できることが分かりました。
自社のフレームワークを見極め、リスクの高い環境への研修を優先すべき
Secure Code WarriorのCEO兼共同創業者であるPieter Danhieux氏はDark Reading の取材に対し、データによればスコア最上位のフレームワークはスコア最下位のフレームワークに比べてリスクが40分の1に抑えられていたと述べました。JavaScriptとJava EE/JSPが露出リスクの多くを占める一方で、C#とJava Springは「ほとんど問題にならなかった」といいます。
「すべてのチームによるフレームワーク選定を個人で監査(あるいは覆すこと)はできません。しかし、リスクの高い環境で開発を行うチームには、環境内の他の高リスクシステムに追加の精査を求めるのと同様に、リリース前にセキュリティゲートと研修要件を必ず整備させることは可能です」と同氏は語ります。
同氏はさらに、開発者が遭遇し得るあらゆる状況を網羅しようとするのではなく、実際に普遍的に発生する状況に研修投資の優先順位を置くべきだと組織に提言しています。
「テストした16モデルすべてに共通して現れたCWEを17件確認しました。これは一度に全て義務付けるには多すぎるリストなので、CISOには発生件数が最も多い5つを優先するよう助言します。すなわち、ログへの機密データの漏洩、クロスサイトスクリプティング、ハードコードされた認証情報、予測可能なセッショントークンおよびリセットコード、そしてパストラバーサルです」と同氏は述べます。「これらはいずれも、新しい、あるいは克服不可能な脅威ベクトルではありません。AppSecチームはこの5つすべてに対して長年プレイブックを備えてきました。今なすべきは、こうしたプレイブックをAI生成コードに対しても、他のあらゆるものと同じ厳格さで確実に適用することです。これは、自ら一行もコードを書くことなく、トップダウンで課すことができる要件です」
翻訳元: https://www.darkreading.com/application-security/choose-wisely-ai-generated-coding-risk-varies
