摘要

代碼漏洞檢測是軟件安全領(lǐng)域的研究熱點，涌現(xiàn)出了大量的工具與算法，但受制于代碼復(fù)雜抽象的邏輯實現(xiàn)，高效的漏洞檢測仍未實現(xiàn)。近年來，由于大語言模型技術(shù)展現(xiàn)出極強的語言理解和文本生成能力，大語言模型賦能漏洞檢測的研究應(yīng)運而生。選取了 4 款大語言模型在 juliet-test-suite 基準數(shù)據(jù)集上對其漏洞檢測效能進行實證研究，并與傳統(tǒng)的靜態(tài)分析工具進行對比。實驗結(jié)果顯示，當前商業(yè)大語言模型具備一定的漏洞檢測能力，但無法完全替代傳統(tǒng)的檢測方法。最后，分析梳理了大語言模型在漏洞挖掘領(lǐng)域的能力評估、現(xiàn)有局限和未來發(fā)展趨勢，有助于未來大語言模型在漏洞挖掘領(lǐng)域的普及和應(yīng)用。

內(nèi)容目錄：

1 相關(guān)工作
2 術(shù)  語
3 效能評估
3.1 工具選擇
3.2 基準數(shù)據(jù)集
3.3 提示詞
3.4 結(jié)果解析與標準化
3.5 評估指標與評估場景
4 結(jié)果分析
4.1 RQ1：大語言模型 C/C++ 代碼漏洞檢測效能
4.2 RQ2：大語言模型與靜態(tài)分析工具 C/C++ 漏洞檢測效能對比
4.3 RQ3：基于大語言模型的代碼漏洞檢測的挑戰(zhàn)與局限性
4.4 RQ4：如何使用大語言模型賦能軟件漏洞檢測
5 有效性威脅
5.1 內(nèi)部有效性威脅
5.2 外部有效性威脅
5.3 構(gòu)造有效性威脅
6 結(jié)  語

軟件漏洞是指軟件在其生命周期（即設(shè)計、開發(fā)、部署、運維）中產(chǎn)生的缺陷，這些缺陷可被黑客利用，從而繞過系統(tǒng)的訪問控制，非法獲得訪問權(quán)限，盜竊數(shù)字資產(chǎn)，造成用戶隱私數(shù)據(jù)泄露，導(dǎo)致企業(yè)和個人巨大的經(jīng)濟損失。美國國家漏洞數(shù)據(jù)庫（National Vulnerability Database，NVD） 公 布 的數(shù)據(jù)顯示，截至 2023 年 8 月，公布的代碼漏洞超過 22 萬個，其中大多數(shù)漏洞來源于 C/C++ 編寫的軟件。

軟件安全的需求日益增長。對于 C/C++ 編寫的軟件而言，其語言自身的復(fù)雜度、代碼規(guī)模、抽象的邏輯實現(xiàn)等因素深刻影響漏洞檢測方法的效果。研究人員一直在探索軟件漏洞檢測方法，包括人工審查、滲透測試、動態(tài)測試、靜態(tài)分析等。其中，靜態(tài)分析是指在不運行代碼的情況下，通過詞法分析、語法分析、規(guī)則匹配等方法對源代碼進行掃描，從而挖掘出潛在缺陷。

隨著生成式人工智能的突破，以 ChatGPT 為代表的大語言模型表現(xiàn)出的語義理解、文本生成和代碼理解能力引發(fā)了筆者的思考。通過研究以下問題，研究大語言模型賦能代碼漏洞檢測領(lǐng)域，為網(wǎng)絡(luò)空間安全引入新的變革，提升安全領(lǐng)域的整體勢能。

（1）RQ1：大語言模型 C/C++ 代碼漏洞檢測效能如何？

（2）RQ2：大語言模型與靜態(tài)分析工具 C/C++代碼漏洞檢測能力對比。

（3）RQ3：基于大語言模型代碼漏洞檢測的挑戰(zhàn)與局限性。

（4）RQ4：大語言模型如何賦能軟件漏洞檢測？許多實證工作已經(jīng)對傳統(tǒng)的漏洞檢測方法和其代表性工具的檢測效能進行了研究，并刻畫了工具的使用場景、擅長挖掘的漏洞類型、檢測置信度等特點。本文對 4 種大語言模型的 C/C++ 漏洞檢測能力進行實證研究，評估大語言模型在具有代表性的 C/C++ 代碼缺陷類型數(shù)據(jù)集上的檢測能力，總結(jié)出大語言模型在代碼漏洞檢測領(lǐng)域的優(yōu)勢特點與局限，以期為后續(xù)研究大語言模型在靜態(tài)代碼漏洞檢測的工作奠定基礎(chǔ)，以及提供有益的啟示。

本文的主要貢獻如下：

（1）以覆蓋缺陷類型廣泛、數(shù)據(jù)量充足的測試集為基準開展了大語言模型在代碼漏洞檢測方面的效能評估工作。

（2）基于商業(yè)模型與開源模型，針對傳統(tǒng)代碼漏洞檢測方法和大語言模型代碼漏洞檢測方法進行了交織對比，深入剖析了各方法的優(yōu)勢與局限，對于該領(lǐng)域的研究和實踐有重要的參考意義。

（3）針對大語言模型的能力、應(yīng)用場景等方面，對大語言模型在代碼漏洞檢測領(lǐng)域的應(yīng)用進行了討論和展望，指出下一步研究方向。

1 相關(guān)工作

圍繞代碼漏洞檢測技術(shù)效能的實證研究一直在進行。早在 2004 年，Zitser 等人就構(gòu)建了包含14 個緩沖區(qū)溢出漏洞的代碼測試集，對 5 款靜態(tài)分析工具進行了評估，并指出靜態(tài)分析工具的誤報率較高的問題。之后 Zheng 等人、Chatzieleftheriou等人、KAUR 等人、AUSTIN 等人通過相似的研究模式，利用代碼漏洞數(shù)據(jù)集評估開源或商業(yè)的靜態(tài)分析工具。2022 年，Lipp 等人基于不同類型的漏洞進行工具的差異化分析，得到通過多分析工具組合的方法能降低靜態(tài)分析誤報率的結(jié)論，但該研究也從側(cè)面驗證，經(jīng)過 18 年的技術(shù)迭代，仍然沒有解決靜態(tài)分析高誤率報的問題。

自從研究人員引入深度學(xué)習(xí)解決漏洞檢測靜 態(tài) 分 析 技 術(shù) 的 固 有 缺 陷， 許 多 先 進 的 漏 洞 檢測 模 型 被 提 出， 例 如 華 中 科 技 大 學(xué) 研 究 團 隊 提出 的 VulDeePecker，利用代碼切片作為深度學(xué)習(xí)模型的輸入，從而檢測漏洞。之后，為了解決VulDeePecker 的局限性，進一步提出了基于深度學(xué)習(xí)的漏洞檢測框架 SySeVR。Zhou 等人通過提取代碼屬性圖特征，訓(xùn)練門控圖神經(jīng)網(wǎng)絡(luò)，對比現(xiàn)有技術(shù)，該模型的漏洞檢測準確率提升了 10.51%。但 Steenhoek 等人開展的針對基于深度學(xué)習(xí)的漏洞檢測實證研究指出，模型的輸出難以保持一致性，34.9% 的測試數(shù)據(jù)會在反復(fù)實驗中呈現(xiàn)不同的結(jié)果。

隨著大語言模型的流行，不少研究人員開始評估大語言模型在專業(yè)領(lǐng)域的效能。Ye 等人對GPT-3 和 GPT-3.5 系列模型的能力進行了詳細分析，分析涵蓋了各種任務(wù)，包括文章總結(jié)、情感分析和問答，對模型的優(yōu)點和缺點有了一定的了解。微軟研究院的 Bubeck 等人在技術(shù)報告《通用人工智能的火花：GPT-4 的早期實驗》中比較了 GPT-4、GPT-3.5 和 GPT-3 在代碼理解、代碼生成、編程挑戰(zhàn)、代碼推理執(zhí)行、代碼描述等方面的能力，GPT 均表現(xiàn)優(yōu)異。此外，還有研究工作在網(wǎng)絡(luò)安全領(lǐng)域開展，例如 Chen 等人 在 2021 年研究了大語言模型在代碼訓(xùn)練時的性能，探索了該模型理解和生成代碼的能力，提出了使用大語言模型執(zhí)行與代碼相關(guān)的任務(wù)的見解。該研究驗證了 Codex 生成 SQL 注入和腳本注入惡意載荷的能力，同時指出 Codex 在漏洞檢測方面的能力不及最基本的靜態(tài)分析工具。同樣有報告指出，ChatGPT 在代碼缺陷二分類檢測和CWE 多標簽分類檢測任務(wù)中表現(xiàn)欠佳。該報告中，作者從 Github 上收集了大量包含漏洞的 Java 工程，并邀請了安全專家對 Java 漏洞數(shù)據(jù)集進行了人工確認，數(shù)據(jù)集包含 18 種 CWE 缺陷類型，檢測效果最好的缺陷類型精確率也未超過 50%。隨著模型能力的提高，需要開展進一步的研究，以了解大語言模型在網(wǎng)絡(luò)安全領(lǐng)域應(yīng)用的潛力。應(yīng)該考慮思維鏈提示的方式，增強大語言模型的逐步推理能力，從而獲得較好的檢測效果。甚至，可以結(jié)合代碼理解能力，挖掘傳統(tǒng)靜態(tài)分析工具不擅長挖掘的邏輯型漏洞。

２ 術(shù) 語

（1）通用缺陷枚舉（Common Weakness Enumeration，CWE）。缺陷廣泛存在于軟件、固件、硬件或服務(wù)中，在某些特定的條件下將導(dǎo)致漏洞。CWE 是由 MITRE 開發(fā)的軟件和硬件缺陷類型分類分級體系，可作為通用的規(guī)范性缺陷描述語言、安全工具的衡量標準，以及缺陷的識別、緩解和預(yù)防工作的基線。

（2）常見漏洞披露（Common Vulnerability Exposure，CVE）。漏洞是指軟件在其生命周期（設(shè)計、開發(fā)、部署、執(zhí)行整個過程）中存在的違反安全策略的錯誤，這些錯誤可被攻擊者利用來獲取系統(tǒng)控制權(quán)限或隱私數(shù)據(jù)。漏洞可被看作某一類型缺陷的實例。CVE 是 MITRE 發(fā)起的識別、定義、公開披露網(wǎng)絡(luò)安全漏洞的項目，每個漏洞都有對應(yīng)的 CVE 記錄，漏洞信息由世界各地的安全從業(yè)者發(fā)現(xiàn)、分配和發(fā)布。

３ 效能評估

本節(jié)介紹效能評估的實證研究方法，評估的整體流程如圖 1 所示。首先利用基準數(shù)據(jù)集測試大語言模型和靜態(tài)分析工具的漏洞檢測能力；其次收集工具檢測結(jié)果，對其進行歸一化和標準化處理；最后基于效能評估指標得出結(jié)論。

圖 1 方法流程

3.1　工具選擇

本次評估對象包括 4 種大語言模型和 1 款作為對比參照的靜態(tài)分析工具。靜態(tài)分析和大語言模型在漏洞檢測領(lǐng)域的使用場景類似，可在不運行代碼的條件下進行代碼安全檢測，通過源代碼的詞法、語法、語義等特征挖掘出潛在缺陷。代碼靜態(tài)分析是軟件漏洞檢測的經(jīng)典方法之一，其他的漏洞檢測技術(shù)有動態(tài)分析、協(xié)議模糊測試、交互式安全測試等，但此類技術(shù)都需要運行程序，使用場景和大語言模型不同。大語言模型的選取主要聚焦世界頂尖的科技公司和高校所推出的模型，本次實證研究中選擇的 ChatGPT、LLaMA、PaLM 和 ChatGLM2分 別 來 自 OpenAI、Meta（Facebook）、Google 和清華大學(xué)。

（1）CodeQL。CodeQL 是 Github 開 源 的 代碼靜態(tài)分析工具，本次實證研究中使用 2.1.3 版本的 CodeQL。CodeQL 使用了代碼語法分析技術(shù)，在漏洞檢測過程中考慮了程序語法特征，需要編譯代碼獲取中間表示，再結(jié)合規(guī)則集進行漏洞檢測。CodeQL 預(yù)定義的規(guī)則集由社區(qū)共同維護。先前的實證研究工作中指出，CodeQL 是一款優(yōu)秀的靜態(tài)分析工具，其性能略低于商業(yè)的靜態(tài)分析工具，但超過 Flawfinder、Cppcheck 等 C/C++ 的靜態(tài)分析工具。

（2）LLaMA。LLaMA 為 Facebook 開源的大語言模型，有 70 億、130 億、330 億和 650 億參數(shù)的版本，最小尺寸的模型經(jīng)過一萬億詞符語料的訓(xùn)練。本次實證研究中，本地部署了 70 億參數(shù)的模型。

（3）ChatGPT。ChatGPT 是 OpenAI 發(fā) 布 的GPT 系列大語言模型，預(yù)訓(xùn)練時使用了大量從社交媒體、聊天記錄、問答網(wǎng)站、代碼倉庫等多個來源收集的數(shù)據(jù)。OpenAI 并沒有公開 ChatGPT 模型的具體參數(shù)量，但 GPT-3 最大版本的模型參數(shù)規(guī)模就已經(jīng)高達 1 750 億個。GPT4 目前為該系列最新的多模態(tài)大模型，支持圖像、文本的輸入。本次實證研究中，通過調(diào)用 API 接口進行測試。

（4）ChatGLM2。ChatGLM2 為 開 源 的 中 英雙語對話模型，使用了生成式語言模型（General Language Model，GLM）混合目標函數(shù)，經(jīng)過了 1.4 TB中英文詞符的與人類偏好對齊訓(xùn)練，模型參數(shù)量為6 億。本次實證研究中，本地部署了 6 億參數(shù)的模型。

（5）PaLM。PaLM 是 Google 公 司 推 出 的 大語言模型，訓(xùn)練過程中加入了大量代碼語料，擅長Python 和 JavaScript 的代碼編程，具備一定的代碼安全分析能力。本次實證研究中，通過調(diào)用 API 接口進行測試。

3.2　基準數(shù)據(jù)集

為了評估上述漏洞檢測工具的效能，本文調(diào)研了不同類型的 C/C++ 漏洞代碼基準測試集，包括由真實代碼構(gòu)成、用于評估協(xié)議模糊測試工具效能的基準測試集 Magma，以及通過抓取代碼倉庫安全相關(guān) commit 所構(gòu)建的真實代碼數(shù)據(jù)集 Devign和 MSR。為了盡可能多地覆蓋代碼缺陷類型，降低測試用例的詞符輸入，本次實證研究工作選用具有多種代表性缺陷類型，且文檔豐富、被廣泛用于靜態(tài)分析工具性能評估的基準數(shù)據(jù)集 Juliet-test-suite， 許 多 先 前 的 工 作 同 樣 使 用 了 Juliet-test-suite 進行性能驗證?；鶞蕯?shù)據(jù)集 Juliet-test-suite 由 NIST 提供，包含 64 099 個構(gòu)造的 C/C++ 漏洞代碼測試用例，涵蓋 118 種 CWE 缺陷類型。

Juliet-test-suite 中 包 含 了 大 量 CodeQL 無 法檢測的缺陷類型，完整使用 118 種測試用例會導(dǎo)致 CodeQL 大量的漏報，影響最終的效能評估結(jié)果。因此，需要對基準數(shù)據(jù)集進行裁剪，篩選出CodeQL 支持檢測的缺陷類型與基準測試集缺陷類型的交集。圖 2 顯示了最終的缺陷類型分布和測試用例數(shù)量，一共有 47 種缺陷類型，共計 36 470 個測試用例，會被用于本次研究。結(jié)合 CWE 分級分類體系對每個 CWE 類型進行根溯源，47 種缺陷類型分別屬于 CWE-682、CWE-664、CWE-691、CWE-697、CWE-703、CWE-707、CWE-710 這 7種高層級的缺陷類別。

圖 2 C/C++ 測試用例分布

3.3　提示詞

提示詞是指導(dǎo)大模型生成高質(zhì)量的與特定主題或內(nèi)容相關(guān)的響應(yīng)。經(jīng)過多種提示詞的測試，選定以指令、背景信息、輸入數(shù)據(jù)為主要組成部分的提示詞進行基于大語言模型的漏洞檢測。指令部分是任務(wù)的具體描述。背景信息部分告訴大語言模型檢測結(jié)果需要符合 CWE 的分類，指出缺陷的具體位置，并按照一定結(jié)構(gòu)化的數(shù)據(jù)格式返回檢測結(jié)果。輸入數(shù)據(jù)部分則是被測對象的源代碼。提示詞的示例如下文所示。

Prompt:

You are a code security expert, analyze the following code snippet for any vulnerabilities, provide your findings in a JSON format like {“cwe”: “CWE-121”, “line”: 9}.```C

<testcases here>

LLM Response:

The given code snippet has a vulnerability, which is a stack-based buffer overflow in the memcpy function call. The json format for the vulnerability would be:

{“cwe”: “CWE-121”, “line”:”11”, “description”:“...”},

safe function: [{“function”: “f1”, “line”: 31,“description”: “...”}, {“function”: “f2”, “line”:31, “description”: “...”}]

3.4　結(jié)果解析與標準化

對不同的工具和模型輸出的分析結(jié)果進行關(guān)鍵信息提取和關(guān)鍵信息歸一化處理，其中，Codeql 將檢測結(jié)果輸出為 CSV 格式，按照規(guī)則與 CWE 的映射表進行映射，得到統(tǒng)一標準化后的檢測結(jié)果。大語言模型判斷回復(fù)是否按要求返回 json 格式，如果是，則進行下一步；如果不是，判斷回復(fù)的整個文本中是否包含 json 數(shù)據(jù)，如果是，則單獨抽取 json數(shù)據(jù)，如果不是，則解析文本，檢查數(shù)據(jù)中是否包含了需要的關(guān)鍵信息，提取缺陷函數(shù)、缺陷類型、缺陷行等漏洞相關(guān)信息。至此完成了關(guān)鍵信息提取步驟，進行關(guān)鍵信息歸一化處理步驟。歸一化處理為判斷缺陷類型、缺陷位置及缺陷函數(shù)等的描述方式是否符合預(yù)定義的標準，如檢查缺陷類型是否僅包含了 CWE 編號，缺陷位置是否是 int 整型，缺陷函數(shù)是否包含形參等。通過統(tǒng)計處理規(guī)則、解析規(guī)則及異常處理情況，可從側(cè)面反映出具體模型在代碼漏洞檢測工作流中的可操作性。

3.5　評估指標與評估場景

建立合理的評估指標是開展評估活動的必要前提。混淆矩陣是表示精度評價的一種標準格式，本文借鑒混淆矩陣來建立效能評估指標。

（1）正報 TP：使用工具分析測試用例時，期望的結(jié)果之一是工具能夠報告目標類型的一個缺陷，這種類型的報告被認為是“真陽性”或正報。

（2）誤報 FP：如果工具在不存在漏洞的測試用例中錯誤地報告任何類型的缺陷，則該條報告被視為“假陽性”，即誤報。

（3）漏報 FN：如果工具在分析存在漏洞的測試用例時沒有報告目標類型的缺陷，則認為工具在測試用例上的結(jié)果為“假陰性”或漏報。

（4）真陰 TN：如果工具在分析不存在漏洞的測試用例時沒有報告任何類型的缺陷，則認為工具在該測試用例上的結(jié)果為“真陰性。”但在本基準測試集中，測試用例需要引用其他的輔助文件或輔助函數(shù)，無法確定具體的關(guān)聯(lián)關(guān)系，因此無法確定真陰性。

漏洞檢測的粒度會影響評估指標，因此本文定義 3 種粒度場景，用來評估漏洞檢測模型和靜態(tài)分析工具是否能提供準確的缺陷點位和非誤導(dǎo)性的缺陷類型，從而輔助加速代碼漏洞確認。

場景 1：如果工具在測試用例的具體漏洞代碼行報告了準確的缺陷類型，則視為該漏洞被檢測到。

場景 2：如果工具在測試用例的漏洞函數(shù)片段中報告了準確的缺陷類型，即便代碼行未對齊，也視為該漏洞被工具檢測到。

場景 3：如果工具在測試用例的漏洞函數(shù)片段中報告了代碼缺陷，即使缺陷類型不正確，也視為該漏洞被工具檢測到。在該場景下，漏洞檢測工具由于輸出的缺陷類型與基準測試集的缺陷類型不在同一個層級，但存在繼承關(guān)系，因此被認定為正報。

受 Lipp 等人工作的啟發(fā)，選擇一款漏洞檢測工具的理由，無外乎在盡可能多地挖掘出代碼中漏洞的同時，最大限度地減少誤報。由于TN 不確定，無法計算涉及TN 的評估指標，如準確率、誤報率等。因此，在功能性和可靠性層面，工具的效能主要由檢出率（召回率）和精確率共同評估。召回率及精確率的計算公式如下：

此外，由于源代碼具有高度的敏感性，工具是否能離線部署同樣也是一個重要的評估指標。因此，在工具的可操作性層面，工具的效能主要由是否支持離線部署、結(jié)果是否易理解、工具的自動化程度等指標評估。

４  結(jié)果分析

本節(jié)介紹測試結(jié)果，并圍繞提出的研究問題進行結(jié)果分析評估。

4.1 RQ1：大語言模型 C/C++ 代碼漏洞檢測效能

本文對 4 種大語言模型和 1 種靜態(tài)分析工具的C/C++ 代碼漏洞檢測能力進行了測試，使用的測試用例涵蓋 47 種 CWE 缺陷類型，共計 36 470 個。在預(yù)定義的 3 種評估場景下，每種 CWE 類型的精確率和檢出率詳細結(jié)果顯示在附錄中。

在測試過程中，結(jié)合不同的測試用例和提示詞進行測試發(fā)現(xiàn)：LLaMa 模型雖然知道 CWE 的含義，但只能輸出提示詞中的 CWE 類型，無法分析代碼，不能指出代碼缺陷的位置，不具備代碼漏洞檢測能力；ChatGLM2 無法輸出代碼缺陷位置行，只能通過函數(shù)名稱進行比對。在評估場景 1 中，ChatGLM2即使輸出了正確的 CWE 類型，也因為不能對應(yīng)代碼行而被算作誤報和漏報，精確率和檢出率都為 0，因此 ChatGLM2 不具備行級代碼漏洞檢測的能力。此外，提示詞明確要求模型返回 json 格式的結(jié)果，但 ChatGLM2 的輸出仍然是純文本，這給后續(xù)的解析與標準化處理引入了困難。

測試結(jié)果顯示，ChatGPT 在場景 1~3 中，準確率和檢出率都優(yōu)于 PaLM 和 ChatGLM2。ChatGLM2 的檢出率在場景 2、3 中優(yōu)于 PaLM，但精確率卻不及 PaLM。

實證研究結(jié)果表明，當前大語言模型具備一定的 C/C++ 代碼漏洞檢測能力，檢測粒度可以是代碼行或函數(shù)段。商業(yè)的大語言模型在提示詞理解、結(jié)果輸出和檢測效能上優(yōu)于開源的大語言模型。

4.2 RQ2：大語言模型與靜態(tài)分析工具 C/C++ 漏洞檢測效能對比

圖 3、圖 4 顯示了 3 種大語言模型和靜態(tài)分析工 具 CodeQL 在 本 次 測 試 中 C/C++ 代 碼 典 型 缺 陷類型的精確率和檢出率對比。典型的缺陷類型主要是與 C/C++ 語言特性相關(guān)的，包括緩沖區(qū)溢出相關(guān)的缺陷、整數(shù)溢出相關(guān)的缺陷和內(nèi)存操作相關(guān)的缺陷。在多數(shù)缺陷類型中，ChatGPT 的精確率都高于CodeQL，其余的大語言模型則在場景 1 中和 CodeQL一致，精確率和檢出率多數(shù)為 0。在場景 2 中，ChatGPT 漏洞檢測的精確率和檢出率高于 CodeQL，但 在 場 景 3 中 不 及 CodeQL。在 場 景 3 中，CodeQL的漏洞檢出率高于 ChatGPT，此現(xiàn)象產(chǎn)生的原因是CodeQL 的檢測犧牲了精確率，以大量的誤報換取高檢出率?？紤] ChatGPT 目前和 CodeQL 的效能差異，可以推測其性能也超過了大部分傳統(tǒng)的靜態(tài)分析工具。

圖 3 典型 C/C++ 漏洞的檢測精確率對比

圖 4 典型 C/C++ 漏洞的檢測檢出率對比

實證研究的結(jié)果表明，在漏洞檢測精確率方面，ChatGPT 超過了傳統(tǒng)的靜態(tài)分析工具 CodeQL。但在場景 3 以函數(shù)段為粒度的缺陷檢測中，CodeQL對部分缺陷類型的檢出率高于大語言模型。綜合觀察精確率和檢出率，本次實證工作中，ChatGPT 的C/C++ 漏洞檢測效能全面超過靜態(tài)分析工具。

4.3 RQ3：基于大語言模型的代碼漏洞檢測的挑戰(zhàn)與局限性

檢 測 效 果 受 限 于 特 定 類 型 的 缺 陷：統(tǒng) 計 評估 場 景 1、2 中 CodeQL 精 確 率 和 檢 出 率 指 標 高于 ChatGPT 的 缺 陷 類 型， 得 到 CWE-{242、482、676、685、457}5 種。上述缺陷主要為使用危險函數(shù)，使用未初始化變量，函數(shù)調(diào)用參數(shù)錯誤等，屬于非上下文敏感型的缺陷。檢測這種類型的缺陷通常使用規(guī)則匹配即可，不需要理解代碼上下文信息，因此靜態(tài)分析工具檢測此類缺陷更有效。

詞符輸入限制：大模型限制了詞符上下文，比如 GhatGLM 和 LLaMa 只支持 2 048 詞符序列長度的輸入。在測試過程中，一些測試用例由于長度超過限制，丟失了分析結(jié)果。本次實證工作使用的基準測試集是構(gòu)造代碼，在代碼復(fù)雜度、代碼邏輯上下文信息、代碼多樣性等方面無法比擬現(xiàn)實中的代碼工程。大語言模型的詞符上下文限制會影響真實代碼工程的檢測，而傳統(tǒng)的靜態(tài)分析工具不存在此問題。

結(jié)果解析與格式化困難：大模型輸出的結(jié)果是文本數(shù)據(jù)，如果接入自動化的工作流中，需要規(guī)定其輸出格式，對輸出內(nèi)容進行檢查。在實證研究中，僅 ChatGPT 可以完全輸出 json 格式的回答，其余大模型會附加額外的文本，給關(guān)鍵信息提取工作造成困難。表 1 顯示了模型和工具的結(jié)果解析處理所需的步驟。

表 1  漏洞檢測模型 / 工具的結(jié)果處理與輸入限制

虛假答案：生成式人工智能會產(chǎn)生虛假答案，ChatGPT 就輸出了很多已經(jīng)棄用或者不存在的 CWE缺陷類型。因此，需要檢查大模型的輸出，處理的異常情況越多，集成到自動化工作流中越困難。

計算資源與成本：對單個測試用例的響應(yīng)時間進行記錄，大語言模型平均檢測時間為 1~2 s，完 成 基 準 測 試 集 的 檢 測 平 均 耗 時 約 為 20 h， 而CodeQL 完成基準測試集的測試只需 30 min。本次實證工作用于部署開源大語言模型的服務(wù)器搭載8 張 A100 顯卡，部署開源大語言模型對計算資源有較高的要求。而商業(yè)大語言模型按照請求、響應(yīng)的詞符個數(shù)進行收費，會產(chǎn)生使用成本。

4.4 RQ4：如何使用大語言模型賦能軟件漏洞檢測

（1）工具融合：先前的工作證明了多種靜態(tài)分析工具的組合能有效提升漏洞檢測的檢出率，并大幅度降低誤報。通過刻畫大語言模型針對具體缺陷類型的置信度，并與其他漏洞檢測工具進行組合，漏洞檢測結(jié)果將會有所提高。

（2）代碼理解：大語言模型，特別是 ChatGPT在代碼理解方面表現(xiàn)出色，具有覆蓋的語言種類多、代碼理解能力強的特點。充分挖掘模型的代碼理解能力，可以克服編程語言間的語法和規(guī)則差異，幫助安全專家更好地應(yīng)用與貫徹攻擊面分析方法、典型漏洞模式知識和漏洞挖掘經(jīng)驗，從而提升代碼安全分析效果。（3）人機協(xié)同：2018 年，美國國防部高級研究計劃局公布了 CHESS 項目，旨在通過人機協(xié)同的方式推動軟件漏洞檢測的工作，開發(fā)適應(yīng)不斷增長的復(fù)雜軟件生態(tài)的 0Day 漏洞發(fā)現(xiàn)和解決系統(tǒng)，人機協(xié)同被視作提升漏洞檢測效能的一項技術(shù)。使用大語言模型可以增強人與計算機間的信息鴻溝表征，支撐代碼理解、攻擊面分析、代碼摘要生成等漏洞挖掘中的子任務(wù)，從而挖掘傳統(tǒng)方法無法檢測的漏洞，例如邏輯型和組件交互關(guān)系復(fù)雜型的漏洞。

5 有效性威脅

5.1　內(nèi)部有效性威脅

一個與基準測試集有關(guān)的內(nèi)部有效性威脅，是測試用例中代碼注釋明確寫出了缺陷相關(guān)信息，函數(shù)的命名方式也明確指出了缺陷類型，這些語義信息會直接被大語言模型學(xué)習(xí)，使用虛假特征給出答案。針對該情況，本文對測試用例進行了預(yù)處理，修改函數(shù)名稱，刪除代碼注釋。另一個內(nèi)部有效性威脅主要涉及 CWE 映射的正確性。CodeQL 的漏洞檢測規(guī)則由社區(qū)共同編寫，并沒有完全對應(yīng) CWE缺陷分級分類體系，因此存在工具檢測結(jié)果未正確匹配 CWE 類型而算作誤報的情況出現(xiàn)，從而影響 CodeQL 的效能評估結(jié)論。針對存在規(guī)則與 CWE映射的情況，進行了人工核查，確保檢測規(guī)則與CWE 缺陷描述一致。對于缺少 CodeQL 檢測規(guī)則與CWE 映射的情況，根據(jù)規(guī)則內(nèi)容，人為分配了近似的 CWE 類別。

5.2　外部有效性威脅

外部有效性威脅主要與基準測試集有關(guān)。由于缺少樣本充足的覆蓋多種缺陷類型的由真實漏洞代碼構(gòu)建的基準數(shù)據(jù)集，實證工作采用了被廣泛使用在靜態(tài)分析工具性能評估中的人工構(gòu)造漏洞數(shù)據(jù)集Juliet-test-suite 進行效能評估。但構(gòu)造的基準測試用例在代碼復(fù)雜度、代碼邏輯上下文信息、代碼多樣性等方面無法比擬現(xiàn)實中的代碼工程，缺少基于真實漏洞樣本的實驗可能會限制評估結(jié)果的通用性。

5.3　構(gòu)造有效性威脅

盡管本次實證工作嘗試了多種提示詞的組合，但未針對具體的模型去優(yōu)化提示詞，所使用的提示詞是否適用于每個大語言模型，是否會給某個模型帶來不公平的優(yōu)勢，是否會引起模型的固有局限和偏差是一個構(gòu)造有效性威脅。

6 結(jié)  語

本文在 47 種缺陷類型的測試集上評估了 4 款大語言模型的 C/C++ 代碼漏洞檢測能力，并將其與靜態(tài)分析工具進行對比。實證研究的結(jié)果表明，ChatGPT 對上下文敏感型漏洞的檢測精確率和檢出率超過了靜態(tài)分析工具 CodeQL，其余的大語言模型也沒有顯著優(yōu)勢，此外，商業(yè)模型檢測性能優(yōu)于開源模型。通過實驗，本文調(diào)查并總結(jié)了當前大語言模型在漏洞檢測領(lǐng)域存在的局限和挑戰(zhàn)，包括詞符上下文限制、檢測缺陷類型有限、虛假答案、計算資源與成本等。以人機協(xié)同機制為牽引，推進大語言模型代碼理解能力和安全專家經(jīng)驗的結(jié)合，是下一步代碼漏洞檢測的研究方向。

筆者認為本研究為未來研究大語言模型在靜態(tài)代碼漏洞檢測方面的應(yīng)用奠定了基礎(chǔ)。后續(xù)將進一步擴展測試集，將不同類型的真實漏洞代碼納入實證研究工作中。同時，以實證工作中的相關(guān)結(jié)論為基礎(chǔ)，權(quán)衡大語言模型和靜態(tài)分析工具的使用場景，以緩解靜態(tài)漏洞檢測中的高誤報率問題。

引用格式：和達 , 余尚仁 , 王一凡 , 等 . 大語言模型 C/C++ 代碼漏洞檢測效能的實證研究 [J]. 通信技術(shù) ,2024,57(5):519-528.
作者簡介 >>>
和  達，男，碩士，工程師，主要研究方向為軟件安全；
余尚仁，男，碩士，工程師，主要研究方向為漏洞分析；
王一凡，男，碩士，工程師，主要研究方向為人工智能；
權(quán)趙恒，男，碩士，工程師，主要研究方向為軟件安全。
選自《通信技術(shù)》2024年第5期（為便于排版，已省去原文參考文獻）
重要聲明：本文來自信息安全與通信保密雜志社，經(jīng)授權(quán)轉(zhuǎn)載，版權(quán)歸原作者所有，不代表銳成觀點，轉(zhuǎn)載的目的在于傳遞更多知識和信息。

相關(guān)閱讀：
安卓應(yīng)用軟件代碼簽名的風(fēng)險挑戰(zhàn)與應(yīng)對措施
軟件數(shù)字簽名是什么？軟件數(shù)字簽名有什么作用？