English translation follows Japanese (draft).

AIが見つける脆弱性に違い！

生成AIの活用範囲は、ソフトウェア開発にも広がっています。最近では、コードを書く作業だけでなく、開発したソフトウェアに問題がないかを確認する作業にもAIが使われるようになっています。特に、セキュリティ評価の分野では、これまで人間が中心に行っていた確認作業をAIによって補助し、ソフトウェアに潜む脆弱性を見つけ、修正につなげることが最近の潮流になりつつあります。

本稿では、AIモデルを使ってソフトウェアの脆弱性を見つける試行的な評価を行い、モデルによってどのような違いが検出結果に出るのかを確認してみました。

今回使用したのは、一般的に利用できるAIモデルです。最近の高性能なAIモデルでは、同じモデルであっても、一般的な利用者向けの安全制御が施されたものや、サイバー防御等の限定的な用途向けに提供先や利用目的を絞って提供されるもの等がありますが、本稿ではそうした特別なモデルではなく、通常利用できるAIで確認しています。

評価の具体的なタスクとしては、あるソフトウェアのコードを対象に、3つのAIモデルで脆弱性検証を行い、その結果を比較しました。
ここでいう脆弱性とは、ソフトウェアの中にある「悪用される可能性のある弱点」のことです。こうした弱点は、開発時に見落とされていたものや、運用を続ける中で問題となるものとして残っている場合があります。例えば、すでに利用が推奨されなくなった古いAPIを使い続けていたり、脆弱性が報告されているオープンソースライブラリを更新せずに利用していたりするケースが考えられます。このような問題は、長期間運用されているシステムのソフトウェアに含まれている可能性もあります。
こうした問題に対応するために、AIを活用して修正が必要な候補を洗い出し、必要に応じて修正やライブラリ更新を行うことが重要になってきています。

今回の検証では、こうした脆弱性の候補がいくつか見つかり、AIモデルによって得られた結果には違いがあることが分かりました。
なお、本検証は脆弱性を発見する（そしてより安全なソフトウェア構築に繋げる）ことを目的として行いましたが、安全制御により出力の一部が得られないことがありました。この制御は、攻撃目的のAI利用を防ぐための機能ですが、脆弱性を見つけるという目的と区別することが難しいために起こりうる正常な動作です。従って、件数についてはあくまで参考であることをお断りしておきます。

得られた脆弱性は、AIモデルによって「とても深刻」「深刻」「中」「軽い」のいずれかに分類されます。これらは、問題の重要度を表しており、簡単に言えば「どれくらい急いで直すべきか」を表しています。
具体的な結果としては、Model 1はとても深刻(Critical)4件、深刻(High)5件、中(Medium)6件、Model 2はとても深刻(Critical)3件、深刻(High)5件、中(Medium)4件、軽い(Low)1件、Model 3は深刻(High)5件、中(Medium)6件、軽い(Low)2件でした。3つのモデルで見つかった問題の総数については、2件の差があったことになります。なお、この結果はそれぞれ1度の試行によるものです。

ただし、この件数差は、そのまま「件数が多いモデルほど優れている」という解釈ができるわけではありません。実は、Model 1は、似た種類の問題を発生箇所や経路ごとに細かく分けて指摘していたため、件数が多くなった面があると考えられます。そのため、15件、13件、13件という件数は比較の参考にはなりますが、件数だけでAIモデルの優劣を判断することはできません。

ここで留意すべき点は、同じ分析をしても、AIモデルによって見つける問題が完全には一致せず、さらに問題の数え方や重要度の付け方にも違いが出るということです。同じ問題でも、あるモデルは「すぐに直すべき重大な問題」と見なし、別のモデルは「使い方によって重大になる問題」と見なす場合があるようです。したがって、AIの結果を見る際には、件数だけでなく、重要度の付け方や、どのような利用環境を前提にしているかにも注意を払う必要があります。

一方で、AIモデルの検証結果は異なっていても、「このソフトウェアのコードには放置すべきではない問題がある」という大きな見立てでは一致しています。
生成AIを使った検証では、複数のモデルが共通して指摘している問題にまず注目し、実際の利用環境に照らして影響評価を行ったうえで対処することが有効ではないかと考えられます。
この結果は、AIによる検証結果を1つだけ見て終わりにするのではなく、複数の視点で確認する価値があることを示しているとも言えます。

また、重要度だけでなく、指摘する問題そのものにも違いがありました。例えば、あるモデルは、画面やレポートに、本来そのまま表示してはいけない内容が出てしまう問題を指摘していました。一方で別のモデルは、データを初期化できてしまう機能や、ファイルの保存場所・読み取り場所を不正に指定されてしまう問題を指摘していました。このように、AIを活用した脆弱性検証では、「AIに聞けば答えが1つに決まる」と考えるのではなく、「AIごとに注目しやすい箇所が異なる」と解釈する方が自然なようです。

なお、AIモデルの利用条件や回答内容は、常に同じとは限りません。同じモデル、同じような依頼であっても、試行ごとに指摘内容や件数が変わる場合があります。また、AI提供側の更新や修正により、性能や挙動が変わることも考えられます。さらに、問題を見つける力と、危険な使われ方を防ぐ仕組みのバランスが、実際に得られる結果に影響する可能性もあります。特にセキュリティに関する検証では、脆弱性の指摘内容や重要度が変わることがあるため、どのモデルを、いつ、どの条件で使ったのかを記録することが欠かせません。

AIによって発見の速度が上がるほど、検出された候補を検証し、優先順位を付け、修正を適用・展開する運用体制の重みも増します。セキュリティ対応では、何件見つかったかだけでなく、何から直すべきかを判断する必要があります。AIは脆弱性検証を支援する強力なツールになり得ます。ただし、AIが出した結果は、あくまで「修正すべき候補」であり、その候補の重要度や、どの順番で直すべきか、直した後に安全になったかを確認するのは、人や組織の役割です。AIの結果を参考にしながら、人や組織が最終判断を行い、その結果に責任を持つことが重要です。

AI Models Differ in the Vulnerabilities They Find!

The use of generative AI is expanding into software development. Recently, AI has been used not only to write code, but also to help check whether developed software has any issues. In the field of security assessment in particular, there is a growing trend toward using AI to support review processes that have traditionally been performed mainly by humans, helping to identify vulnerabilities in software and support remediation.

This article presents an exploratory evaluation using AI models to identify software vulnerabilities and examines how the results differed across the models.

The AI models used in this evaluation were all generally available models. Among recent frontier AI models, even the same AI model may be made available in different forms: some versions are offered to general users with strong safety controls applied, while others are made available only for limited purposes, such as cyber defense, with restrictions on who may access them and how they may be used. In this article, rather than using such special-purpose models, the evaluation was conducted using AI models available for ordinary use.

As the specific task for this evaluation, three AI models were asked to assess the code of a specific piece of software for vulnerabilities, and the results were then compared.

In this context, a vulnerability means a “weakness that could potentially be exploited” in software. Such weaknesses may have been overlooked during development, or they may remain in the software and become problems during continued operation. For example, software may continue to use an old API that is no longer recommended, or it may rely on an open-source library with known vulnerabilities without updating it. Issues like these may also exist in software used in long-running systems.

To address such problems, it is becoming increasingly important to use AI to identify candidates that may require remediation and, where necessary, to apply fixes or update libraries.

In this evaluation, several candidate vulnerabilities were identified, and the results were found to differ depending on the AI model.

This evaluation was conducted with the goal of discovering vulnerabilities and thereby contributing to safer software development. However, in some cases, safety controls prevented part of the output from being obtained. This is a safety feature designed to prevent the malicious use of AI. Because it can be difficult to automatically distinguish such misuse from the purpose of finding vulnerabilities, this kind of intervention can occur even during normal, defensive use. Accordingly, the number of findings reported here should be treated as reference information only.

The identified vulnerabilities were classified by each AI model as “Critical,” “High,” “Medium,” or “Low.” These categories indicate the severity of the issues. Put simply, they show how urgently each issue should be fixed.

Specifically, Model 1 identified 4 Critical issues, 5 High issues, and 6 Medium issues. Model 2 identified 3 Critical issues, 5 High issues, 4 Medium issues, and 1 Low issue. Model 3 identified 5 High issues, 6 Medium issues, and 2 Low issues. This means that the total number of issues found differed by up to two across the three models. These results are based on a single trial for each model.

However, this difference in the number of issues cannot simply be interpreted to mean that the model that found more issues was superior. In fact, Model 1 appears to have produced a higher count partly because it divided similar types of problems into separate findings based on where they appeared or which execution paths they involved. Therefore, while the totals of 15, 13, and 13 issues are useful for comparison, the number of findings alone cannot be used to determine which AI model is better.

The point to note here is that, even when the same analysis is performed, the issues found by different AI models do not completely match. Differences can also appear in how the issues are counted and how severity is assigned.

Even for the same issue, one model may treat it as a serious problem that should be fixed immediately, while another model may treat it as a problem that becomes serious depending on how the software is used. Therefore, when reviewing AI-generated results, it is necessary to pay attention not only to the number of findings, but also to how severity is assigned and what kind of usage environment the model appears to assume.

At the same time, although the assessment results differed among the AI models, they were broadly consistent in concluding that this software code contains issues that should not be left unaddressed.

When using generative AI for vulnerability assessment, it may be effective to first focus on issues commonly identified by multiple models, assess their impact in light of the actual usage environment, and then take appropriate action.

These results also suggest that there is value in checking from multiple perspectives, rather than relying on the results of a single AI-based assessment.

There were also differences not only in severity, but also in the specific issues pointed out by each model.

For example, one model pointed out a problem in which content that should not be displayed as-is could appear on a screen or in a report. Another model, by contrast, pointed out a function that could allow data to be reset, as well as a problem in which file paths used for saving or loading data could be manipulated. In this way, when using AI for vulnerability assessment, it seems more natural to interpret the results as showing that each AI model tends to focus on different areas, rather than assuming that asking AI will produce a single definitive answer.

It should also be noted that the conditions under which AI models are used, and the responses they generate, are not always the same. Even with the same model and a similar request, the content and number of findings may vary from one attempt to another. In addition, updates or modifications made by the AI provider may change the model’s performance or behavior. The balance between the model’s ability to find problems and the mechanisms designed to prevent dangerous use may also affect the assessment results obtained in practice. In security-related assessments in particular, the content and severity of vulnerability findings may change, so it is essential to record which model was used, when it was used, and under what conditions.

As AI increases the speed of discovery, the operational process for verifying identified candidates, prioritizing them, and applying and deploying fixes becomes increasingly important. In security response, it is necessary to judge not only how many issues were found, but also which ones should be fixed first.

AI can be a powerful tool for supporting vulnerability assessment. However, the results produced by AI should ultimately be treated only as candidates for remediation. It remains the role of people and organizations to assess the severity of those candidates, decide the order in which they should be addressed, and confirm whether the software is safe after fixes have been applied. Ultimately, people and organizations must make the final judgment based on AI-generated results and take responsibility for that judgment.