LLMによるAI生成コードは依然として極めて安全性が低い

出典：Gorodenkoff（Shutterstockより）

大規模言語モデル（LLM）によって生成されるコードは、時間の経過とともにいくらか改善されてきました。より新しいLLMはコンパイルできる可能性の高いコードを生成するようになっています。しかし同時に、他の面では停滞しています。特にセキュリティ面では依然として不十分であり、特にAI生成のJavaコードで顕著です。脆弱性を生み出すだけでなく、LLMは存在しないソフトウェアライブラリを幻覚するなどのエラーを起こしやすく、データセットの悪意ある汚染といった問題にも脆弱です。

今週発表された100以上のLLMを対象とした調査で、アプリケーションセキュリティ企業Veracodeは、AIチャットボットが4つの言語の正しい構文でコードを生成できるかをテストし、そのコードに脆弱性がないかをスキャンして安全性を評価しました。AI生成コードの構文は大幅に改善し、過去1年以内にリリースされたLLMによるコードの90%以上がエラーなくコンパイルされました（2023年6月以前は20%未満）。しかし、その後のセキュリティスキャンを通過したのはわずか55%であり、この数字は長期間ほとんど変化していません。

「LLMは、必要なセキュリティ作業から誰かを解放してくれるものではありません」とVeracodeのCTO、Jens Wessling氏は述べています。「LLMが学習しているコードは構文的には正しいですが、ほとんどの開発者、特にエンタープライズやオープンソース以外のプロジェクトの開発者は、自分たちの決定が持つセキュリティ上の意味を十分に理解していません。そのため、そうした問題が残り続けます。LLMの出力は実際のコードをモデルにしており、その実際のコード自体に脆弱性が含まれているのです。」

過去2年間で、開発者によるLLMのコード生成利用は爆発的に増加しています。2つの調査によれば、開発者の約4分の3がオープンソースプロジェクトでAIコード生成を利用しており、ブラジル、ドイツ、インドの開発者の97%もLLMを活用しています。

そして、非開発者が専門知識なしにLLMを使ってコードを生成する場合（いわゆる「バイブコーディング」）、セキュリティ脆弱性が本番コードに残る危険性が劇的に高まります。

AI支援開発は今後ますます普及するため、企業は自社のコードをどのように守るかを考える必要があると、クラウドソーシング型セキュリティサービス提供企業Bugcrowdの創業者Casey Ellis氏は述べています。

「AI支援コーディングが良いことか悪いことかとよく聞かれますが、それは間違った問いだと思います」と彼は言います。「もし何かが本当により良く、より速く、より安くなるなら、それは爆発的に広まるものです。人々はより良く、より速く、より安いものを求めるからです。」

驚き：LLMのサイズは関係ない

Veracodeは、最も人気のあるLLM（どれをテストしたかはレポートで明示せず）向けに分析パイプラインを作成し、コード生成能力が時間とともにどう進化したかのデータを取得しました。各AIチャットボットに80以上のコーディングタスクを与え、その生成コードを分析しました。

最初期のLLM（2023年前半リリース）はコンパイルできないコードを生成していましたが、過去1年にリリースされた最新版の95%は構文チェックを通過するコードを生成しました。

一方で、コードのセキュリティはほとんど改善されておらず、LLMが生成したコードのおよそ半分にOWASP Top-10のセキュリティ脆弱性が検出されたとVeracodeは述べています。最新のLLMでも成功率は40～60%にとどまり、平均すると55%の確率で安全なコードを生成しています。

おそらく今回の調査で最大の驚きは、大規模言語モデルのサイズが構文やコードのセキュリティに影響しないことです。パラメータが200億未満の小型モデルも、1000億超の大型モデルも同等の性能を示しました。

「どれも概ね似たような性能を示しており、『良いコードや正確なコードを生成するか、期待通りの動作をするか』という点では一部例外がある程度です」とWessling氏は述べています。「それはまったく別の問題です。」

AI生成Javaコードのセキュリティは薄い

もう一つの驚きは、LLMが特にJavaで安全なコードを生成するのが苦手なことです。Javaは本来、プログラムのセキュリティ強化のために作られた言語ですが、他のテスト対象言語（Python、JavaScript、C#）が55～62%の成功率でセキュリティチェックを通過したのに対し、Javaは平均29%にとどまりました。

Wessling氏は、Javaの長い歴史により、セキュリティが重視される前に作られたコードが大量に存在することが一因だと推測しています。そうしたコードがLLMの学習データセットに含まれていれば、生成されるコードにも当然エラーが現れるといいます。

「何年にもわたるJavaプログラムの例が今も存在し、LLMによってスキャンされ続けています。Javaには模範例として書かれたが、必ずしも安全なコーディング実践に則っていないサンプルコードが多く存在します」とWessling氏は説明します。「そうしたものが取り込まれてしまうのです。」

さらに、LLMは特定の種類の欠陥をあまり生成しない傾向もありました。AIコードツールによるプログラムの大多数はSQLインジェクションや暗号化エラーのセキュリティチェックを通過しましたが、クロスサイトスクリプティング（XSS）や暗号化エラーのテストには失敗したと、Veracodeのレポートは述べています。

セキュリティ負債は増大しつつある

これらの問題の解決には時間がかかる見込みであり、AIコード生成ツールの利用が減速することは考えにくいため、懸念すべきギャップが生じています。

LLMを利用する開発者はより速いペースでコードを作成しています。スタンフォード大学が10万人の開発者を対象に行った調査では、 平均して30～40%多くのコードを生産していることが分かりました。しかし、そのコードのかなりの部分は機能バグを排除するために手直しが必要であり、全体としての生産性向上は15～20%にとどまると同じ調査は示しています。

アプリケーションセキュリティプロバイダーBlack Duckのシニアセキュリティソリューションマネージャー、Mike McGuire氏は、セキュリティ欠陥の発見と修正はこうした生産性向上をさらに損なうだろうと述べています。

「企業はAIシステムにコード生成を依存することでセキュリティ負債を生み出しています」と彼は言います。「これは必ずしもエラー率が上昇しているからではなく、AIがコード生産を加速させているからです。チームはより短時間でより多くのコードを生産しており、そのうち半分近くがセキュリティテストに失敗している場合、リスクの量は急速に増大します。」

BugcrowdのEllis氏は、セキュリティ負債に関して嵐の到来を予見しています。

「脆弱性は、コード行数の確率的関数として存在します」と彼は述べます。「私たちはインターネット上にますます高速で大量のコードを送り出しており、コードが増えれば脆弱性も増えます。さらに、スピードは品質の敵であり、セキュリティは品質の副産物です。」

しかし、AI支援コーディングは避けられない流れであり、企業は安全なコードへの対応策を模索すべきです。

「誰かがLLMに[セキュリティバグ]を自然に特定させたり、LLMの学習時に安全でないコードを除外する方法を見つければ、状況は劇的に変わる可能性があります。私たちはそれを注視しています」とWessling氏は述べます。「今はこうでも、1年後も同じとは限りません。今後の動向に注目しています。」