大模型漏洞修復插件是騰訊朱雀實驗室在安全垂類場景的一個重要實踐。我們希望通過AI大模型，實現研發安全場景的漏洞自動修復，給出修復建議并提供修復代碼，幫助更多開發人員提高研發效率。在騰訊混元大模型的支持下，漏洞修復插件通過精調后部署的私有化模型，實現了在帳密硬編碼、SQL注入、命令注入等漏洞類型的修復建議輸出和修復代碼生成等功能，實現安全左移，更有效地在編程中使用插件收斂漏洞風險。

圖1. IDE插件示意圖

一、研發安全場景的現狀和挑戰

利用傳統方法做漏洞修復提效，只適用于比較簡單的場景，比如根據版本號判斷使用的開源組件是否存在漏洞，更多高危險的如導致數據泄露的注入類漏洞/賬密類等，該方案難以通用。主要原因總結如下：

• 規則限制：傳統靜態分析技術通常基于預定義的規則和模式進行漏洞檢測和修復，無法覆蓋所有的漏洞類型和場景;
• 上下文和語義理解限制：傳統靜態分析技術通常難以理解代碼的上下文和語義信息，導致無法準確地理解代碼的含義和邏輯;
• 創造性限制：傳統靜態分析技術通常只能分析已有的代碼，無法創造新的代碼片段來修復漏洞，限制了漏洞修能力。

相比傳統程序分析技術，大模型具備強大的推理能力，尤其是在代碼生成方面表現突出，可通過訓練來學習漏洞修復的模式和規律。

二、為何在研發安全場景引入大模型?

1. 大模型可解釋性

大模型擁有豐富的預訓練語料信息，如：書籍文檔、代碼素材、網頁文本等等。基于預訓練語料信息，并對基座大模型進行垂類領域的精調，大模型能結合知識信息進行整合和解釋，產生有效的回復。對于研發安全場景來說，我們不僅需要生成有效的修復代碼，也希望為更多的開發同學提供具體和明確的修復分析指引，從而更好地提效。

2. 大模型代碼生成能力

各類基座大模型和代碼類Codex大模型，具有強大的代碼生成能力。這些模型可以理解自然語言指令，并根據這些指令生成相應的代碼。這種能力使得它們可以用于各種編程任務，包括但不限于編寫新的函數、修復代碼中的錯誤、優化現有代碼等。這些模型的代碼生成能力基于其在大量代碼庫上的訓練。在訓練過程中，模型學習了各種編程語言的語法和語義以及如何將自然語言指令轉化為代碼。因此，只要給出清晰的指令，這些模型就能生成相應的代碼。但這些生成的代碼中仍存在一些安全問題，即：潛在的不正確、含漏洞的代碼等。因此，我們需要利用大模型的代碼生成能力，同時希望通過精調等操作，使大模型能有效修復漏洞代碼，盡量生成安全無漏洞的代碼片段。

3. 大模型在安全防護領域的應用已成為趨勢

2023年，大模型成為了各行各業的熱門關注點，其中安全垂類領域的安全大模型也呈現了百花齊放的態勢，主要覆蓋安全咨詢、安全培訓、安全監控、安全修復等能力。微軟2023年3月份正式發布集成GPT-4的Microsoft Security Copilot，旨在更好地提供安全工具和專家知識，輔助企業識別和檢測安全風險。谷歌2023年4月發布“谷歌云AI安全工作臺”，利用 Sec-PaLM 來幫助用戶查找、總結和應對安全問題。國內公司也推出了自己獨有的安全大模型，主要對于安全場景，提供專家級別的咨詢建議，提效運營效率。

三、混元一站式如何快速定制司內自研的研發安全大模型

1. 騰訊混元大模型能力

(1) 訓練優化

騰訊混元大模型通過大量實驗，對預訓練數據進行了語料豐富擴充，已覆蓋 100 多種自然語言，32 種編程語言;并經過了數據清洗、過濾、去重等流程，對各類數據進行了大量的數據配比實驗，保證了較為平穩的訓練過程。同時，項目組對于長文能力、位置編碼等技術細節進行了改進和優化。

(2) 模型效果

騰訊混元項目組參考業界主流做法，一共選用數十個數據集合，分為中文NLP、英文NLP任務、代碼、數學、AGIEval、CMMLU、CEval等維度，綜合評估模型在各項維度上的能力。其中，騰訊混元十億級別大模型在代碼能力上的提升更加顯著，這點與我們使用中的精調體驗也非常一致。

2. 漏洞相關高質量數據的收集及模型結果

通用大模型的崛起，依賴于大規模的數據灌輸;大模型能否在垂直領域落地，同樣依賴是否有高質量的領域數據。對于研發安全場景，我們也積累了系統且豐富的高質量數據處理經驗。

(1) 漏洞修復數據的格式

漏洞修復數據，最基礎的是漏洞類型、漏洞代碼、修復后代碼三個屬性。

圖2. JavaScript SQL注入漏洞修復樣例

但在實踐過程中僅使用這三部分信息來精調大模型，效果并不好。為此，我們擴至漏洞類型、漏洞代碼、修復后代碼、代碼描述、漏洞信息、修復建議、修復過程七個屬性，組成“漏洞代碼 -> 代碼做了什么 -> 存在什么漏洞 -> 應該怎么修復 -> 修復后代碼 -> 具體修復過程”的整體邏輯，實際訓練效果更好。

圖3. Java SQL注入漏洞修復示例

(2) 漏洞修復數據源及處理方式

我們采用的漏洞修復數據源，包含GitHub數據、公開數據、業務數據等，數據質量依次上升。下面我們大致介紹各數據源的潛在問題和處理過程。

①GitHub數據

Github是主流開源社區之一，其歷史數據中含有大量的漏洞代碼及修復的記錄，但不同開發者的編程水平參差不齊。我們根據關鍵詞召回與漏洞相關的數據，但實踐中發現大部分(>90%)召回數據存在與漏洞修復無關、錯誤的修復方式、代碼質量低等等問題，因此我們需要一些自動化的方法來過濾這些數據。

缺點：

• 不可用數據的占比較高，人工審核成本上升;
• 單個樣本可能存在代碼塊分散、缺失上下文信息等問題;

優點：

• 數據量級較大;
• 代碼多樣性豐富;
• 可按需召回指定類型的漏洞;

②公開數據

公開數據，更多指的是學術界開源的數據。這類數據，已經被大量學術工作借鑒使用，本身具備一定的可信度。目前，我們使用的主要是CVE-Fixes數據集。

圖4. CVE-Fixes Top-5漏洞與SQL漏洞占比圖

缺點：

• 數據量級不大;
• 漏洞類型分布與實際業務漏洞類型分布差距大;

優點：

• 數據質量有一定保障;
• 代碼多樣性豐富;

③業務數據

業務數據，即收集公司業務歷史修復數據，清洗后作為訓練數據。業務數據優點非常多，最貼近模型使用的場景、含有更符合公司業務場景的修復方式。但業務數據與GitHub數據有相同的缺點，清洗難度較大。

缺點：

• 歷史誤報、錯誤修復的數據占比較高，人工審核壓力大;
• 符合實際訓練需求的高質量數據量級有限;

優點：

• 代碼多樣性豐富;
• 與落地場景完全契合;

(3) 訓練數據構造

基于上文獲取的漏洞數據，我們進行了大量的實驗。總結得到，在數據總量和質量不變的情況下，“Prompt工程”和“數據配比”對實驗結果會產生影響。同時，我們指出：不同垂直領域下得到的實驗結論大概率不同，例如我們在數據配比時配比了部分通用數據和代碼數據，而其他團隊可能只是用垂直領域的數據。所以，我們建議大家在聚焦的垂直領域多實驗、再總結。

(4) Prompt 工程

通過調整對模型提問的方式，使得模型的回答效果更好。具體的，我們通過業界的論文以及經驗分享，總結了一個相對通用的模板：expert+COT+輸出格式+變量。如圖5所示。其中，expert是一種增強提示策略，用于指示LLM像專家一樣回答問題。COT，即思維鏈，通過增加一系列中間推理步驟，能顯著提高大型語言模型復雜推理的能力。

圖5. prompt構造

(5) 數據配比

除了漏洞數據外，我們還收集了開源的通用、代碼、數學sft數據集，并進行了相應的配比實驗。我們發現，數學數據集對漏洞修復準確率的提升基本無影響，而適當比例的代碼、通用數據，有助于提升模型的漏洞修復準確率。

經過調優，我們的最佳數據配比如圖6所示。當我們代碼：通用：漏洞=1:2:4的時候，結果達到最優。

圖6. 最佳數據配比圖

我們將開源的通用(general)、代碼(code)、數學(math)、漏洞(vulnerability)數據集，輸入到模型中，抽取倒數第二層對應的embedding，使用t-sne算法對其進行可視化，得到的結果如圖7所示。可以看到數學數據集距離漏洞數據集最遠，這也解釋了為什么數學數據集對漏洞修復準確率的提升基本無影響。

圖7. t-sne結果圖

(6) 實驗結果

我們將實驗結果與gpt3.5進行比較，結果如表1所示。從表1中可以看出，我們的平均準確率比gpt3.5高1.67%，具體到每個漏洞類型，均超過或持平gpt3.5。

表1 自建模型與gpt3.5結果對比表

(7) 上下文長度對結果的影響

在前文介紹處理業務數據時，我們提出借助于污點傳播技術，只摘取漏洞觸發點所在行的上下文代碼。那么，這個上下文取多少行合適呢?這里我們在推理階段取不同大小的上下文進行了測試，如圖8所示。從結果中可以看出，不同大小的上下文確實對結果有影響，并且對于不同漏洞，影響不太相同。

對于SQL注入以及命令注入漏洞來說，適中大小的上下文有助于提升測試準確率。當上下文過少時，模型抽取的與漏洞相關的語義信息不足，通過這些信息無法判斷是否存在漏洞，導致準確率下降;相反，當上下文過多時，模型定位漏洞所在行可能存在困難，導致準確率下降。

對于帳密硬編碼漏洞來說，測試準確率隨著上下文行數的增多而減少，猜測可能是因為對于該漏洞類型，較少的行數就足以讓模型判斷存在帳密硬編碼，也足以讓模型進行修復。相反，當測試上下文過多時，模型定位漏洞所在行可能存在困難，導致準確率下降。

圖8. 不同漏洞類型修復準確率隨上下文長度的變換曲線圖

3. 插件支持漏洞檢測和修復

目前我們基于騰訊混元大模型，推出了漏洞檢出和修復功能的插件。插件目前重點發現三大類研發過程中對現網產生嚴重影響的漏洞：SQL注入、命令注入和賬密泄漏，并較業內大幅提升發現風險的準確性。目前插件已支持在vs code內使用，僅需在vs code內安裝插件，即可實現在提交代碼前檢測安全風險并及時修復。

(1) 插件的漏洞檢測+修復示例

圖9. 插件的漏洞檢測+修復示例圖

(2) 與競品模型回復的對比

我們將自建模型與gpt3.5模型的回復進行對比，其中一個典型案例如下。gpt3.5與自建模型均能判斷出代碼中存在SQL注入漏洞，但是gpt3.5無法對其進行正確修復，而自建模型可以。

圖10. 自建模型與gpt3.5回復對比

4. 插件模型版本的自動化測評和迭代

模型評測迭代的過程中，針對漏洞修復，我們完全自建了benchmark以及對應的評判規則：

• 待評測數據通過自研模型，拿到修復結果。
• 將修復前后的代碼，輸入到代碼相似度模型中，防止模型吐出與原始代碼不相關的代碼。
• 使用算法/工具判斷脫敏后的漏洞代碼是否修復。
• 根據實際測試，我們發現以上流程無法對修復前后代碼語義是否更改進行判斷。如圖11所示，修復后代碼漏掉了=號，導致語義的改變。因此我們補充設計了一套規則，來判斷修復前后代碼語義是否有更改。

圖11. 修復前后代碼語義改變示意圖

四、總結與展望

以研發安全場景為切入點，擁有均衡能力的騰訊混元大模型未來在安全領域會有更廣泛的應用場景和前景，幫助安全業務提高安全防護的效率，可以降低業務的投入成本，提高經濟效益。

• 在數據安全領域，大模型可以通過對大量數據的分析，發現數據中的異常行為，及時預警并采取措施，防止數據泄露、數據篡改等安全問題的發生。
• 在網絡安全領域，大模型可以通過對網絡流量的實時監控，發現并阻止網絡攻擊，保障網絡的正常運行。
• 在安全運營領域，大模型可以通過對用戶數據、設備狀態數據的持續監控，發現并預防各種安全風險，提高安全運營的效率。
• 同時，大模型還可以通過對安全審計的支持，幫助企業更好地遵守各種安全法規，避免因違規操作而帶來的法律風險。

總的來說，騰訊混元大模型的出現，將會在安全領域開辟出更廣闊的應用場景，充分利用好公司內已有的安全數據，做好業務數據處理和沉淀，將大大提高安全水位和業務效率。

本文轉載自騰訊技術工程，作者：騰訊程序員

原文李鏈接：???https://mp.weixin.qq.com/s/KwyuQPmInzXwqWjV46OmhQ????