寫(xiě)在最前面

本文為鄒德清教授的《網(wǎng)絡(luò)安全專(zhuān)題》課堂筆記系列的文章，本次專(zhuān)題主題為大模型。

ISSTA 2023
How Effective Are Neural Networks for Fixing Security Vulnerabilities

評(píng)測(cè)現(xiàn)有的大模型和基于深度學(xué)習(xí)的自動(dòng)補(bǔ)丁修復(fù)模型對(duì)Java漏洞修復(fù)能力的工作

論文很長(zhǎng)很系統(tǒng)，學(xué)姐讀的很細(xì)節(jié)很深入

摘要

安全漏洞修復(fù)的兩種方向
（1）LLM，已對(duì)源代碼預(yù)訓(xùn)練，用于代碼補(bǔ)全等任務(wù)
（2）基于深度學(xué)習(xí)的自動(dòng)程序修復(fù)APR

貢獻(xiàn)

【注意】沒(méi)有構(gòu)建一種自動(dòng)java漏洞的技術(shù)
（1）提出數(shù)據(jù)集，并對(duì)當(dāng)前工作進(jìn)行測(cè)量
（2）設(shè)計(jì)代碼轉(zhuǎn)換，以解決訓(xùn)練和測(cè)試數(shù)據(jù)重疊對(duì)codex的威脅
（3）創(chuàng)建了新的Java漏洞修復(fù)基準(zhǔn)VJBench及其轉(zhuǎn)換版本VJBench-trans，以更好的評(píng)估
（4）評(píng)估

數(shù)據(jù)集上創(chuàng)建兩個(gè)benchmark
通過(guò)代碼轉(zhuǎn)換，來(lái)減輕llm和黑盒codex訓(xùn)練數(shù)據(jù)中可以看到評(píng)估數(shù)據(jù)的威脅

發(fā)現(xiàn)

比較DL和LLMs，更多數(shù)據(jù)vs數(shù)據(jù)格式匹配
對(duì)更多數(shù)據(jù)加微調(diào)vs數(shù)據(jù)格式匹配
微調(diào)的有效性

我們的發(fā)現(xiàn)包括:
（1）現(xiàn)有的llm和APR模型修復(fù)的Java漏洞很少。Codex修復(fù)了10.2個(gè)(20.4%)，漏洞數(shù)量最多。很多生成的補(bǔ)丁都是無(wú)法編譯的補(bǔ)丁。
（2）利用一般APR數(shù)據(jù)進(jìn)行微調(diào)，提高了llm修復(fù)漏洞的能力。
（3）新VJBench揭示了llm和APR模型無(wú)法修復(fù)許多常見(jiàn)弱點(diǎn)枚舉(CWE)類(lèi)型，例如CWE-325缺失加密步驟和CWE-444 HTTP請(qǐng)求走私。
（4）Codex修復(fù)了8.3個(gè)轉(zhuǎn)換漏洞，優(yōu)于所有其他llm

介紹

背景：漏洞修復(fù)需求和Java漏洞修復(fù)方向

1）漏洞修復(fù)的需求

• 及時(shí)性： 平均修復(fù)漏洞的時(shí)間（從發(fā)現(xiàn)到修復(fù)）應(yīng)在60到79天之間。強(qiáng)調(diào)了及時(shí)應(yīng)對(duì)漏洞的重要性，以降低潛在的安全風(fēng)險(xiǎn)。
• 完整性： 修復(fù)的漏洞修復(fù)必須被證明是充分有效的，不能存在后續(xù)漏洞。

2）Java漏洞修復(fù)方向需求

1. 廣泛的應(yīng)用范圍： Java廣泛用于關(guān)鍵服務(wù)器應(yīng)用，包括Web服務(wù)器和服務(wù)。這使得Java漏洞修復(fù)至關(guān)重要，涉及敏感數(shù)據(jù)和關(guān)鍵功能。
2. 缺乏Java漏洞修復(fù)工作： 目前，大多數(shù)漏洞數(shù)據(jù)集和修復(fù)方案主要關(guān)注C/C++和二進(jìn)制文件，Java領(lǐng)域存在漏洞修復(fù)的機(jī)會(huì)和需求。
3. 難以遷移的其他語(yǔ)言解決方案： 例如，C/C++中最常見(jiàn)的漏洞類(lèi)型是緩沖區(qū)溢出，但Java被設(shè)計(jì)成一種類(lèi)型安全的語(yǔ)言，以避免此類(lèi)漏洞，因此需要特殊的漏洞修復(fù)策略和工具。

動(dòng)機(jī)

基于深度學(xué)習(xí)的自動(dòng)程序修復(fù)技術(shù) (APR) 和 LLM (預(yù)訓(xùn)練語(yǔ)言模型) 在Java漏洞修復(fù)方面的比較研究

• 基于深度學(xué)習(xí)的自動(dòng)程序修復(fù)技術(shù) (APR)
  • 通過(guò)學(xué)習(xí)程序中的缺陷和相應(yīng)的修復(fù)方法。
• LLM（預(yù)訓(xùn)練的語(yǔ)言模型）的應(yīng)用于源代碼
  • 預(yù)訓(xùn)練的LLM在修復(fù)通用Java漏洞方面表現(xiàn)有競(jìng)爭(zhēng)力。
• 本文工作：
  • 不是構(gòu)建一種自動(dòng)修復(fù)Java漏洞的技術(shù)。
  • 研究和比較兩種技術(shù)類(lèi)型：基于深度學(xué)習(xí)的自動(dòng)程序修復(fù)和LLM，以探討自動(dòng)修復(fù)Java安全漏洞的可能性和適用性。
  • 比較基于深度學(xué)習(xí)的APR技術(shù)和LLM修復(fù)Java漏洞的能力。
• LLM vs DL based APR：
  • 問(wèn)題是在更多的數(shù)據(jù)和數(shù)據(jù)格式匹配之間進(jìn)行比較。
  • 哪種方法更有效？更多的數(shù)據(jù)勝出還是數(shù)據(jù)格式匹配更為關(guān)鍵？
• Fine-tuned LLM vs DL based APR：
  • 比較對(duì)更多數(shù)據(jù)進(jìn)行微調(diào)和數(shù)據(jù)格式匹配的有效性。
  • 這兩種方法哪種更為有效？微調(diào)的LLM是否勝出？

這篇文章旨在比較兩種不同的方法來(lái)自動(dòng)修復(fù)Java漏洞，其中一種是基于深度學(xué)習(xí)的自動(dòng)程序修復(fù)技術(shù)，另一種是使用預(yù)訓(xùn)練的語(yǔ)言模型（LLM）。
研究旨在探索：
1、哪種方法在不同條件下更為有效，是更多數(shù)據(jù)的支持更關(guān)鍵，還是數(shù)據(jù)格式匹配更為關(guān)鍵，
2、以及微調(diào)LLM是否有競(jìng)爭(zhēng)力。
3、有助于指導(dǎo)未來(lái)的自動(dòng)程序修復(fù)研究和實(shí)踐。

方法

第一次開(kāi)展評(píng)估和比較APR技術(shù)和LLM修復(fù)Java漏洞的能力的實(shí)驗(yàn)

這是一項(xiàng)初次評(píng)估和比較基于深度學(xué)習(xí)的自動(dòng)程序修復(fù)技術(shù)（APR）和預(yù)訓(xùn)練語(yǔ)言模型（LLM）在Java漏洞修復(fù)方面的實(shí)驗(yàn)研究。在此過(guò)程中，出現(xiàn)了兩個(gè)關(guān)鍵挑戰(zhàn)：

1. 數(shù)據(jù)集問(wèn)題：

   • Benchmark稀缺： 可用于評(píng)估的Benchmark數(shù)據(jù)集相對(duì)有限。
   • Vul4J： 包含79個(gè)可重現(xiàn)的Java漏洞，但它們只涵蓋了25個(gè)CWE（常見(jiàn)弱點(diǎn)枚舉）類(lèi)別。
   • 不均衡： 數(shù)據(jù)集中60%的CWEs（15種漏洞類(lèi)型）僅具有一個(gè)可重現(xiàn)的漏洞示例。

2. 評(píng)估有效性問(wèn)題：

   • Codex訓(xùn)練集未公布： 缺乏Codex的訓(xùn)練數(shù)據(jù)的公開(kāi)性，難以確定Vul4J和VJBench中的漏洞是否已經(jīng)包含在Codex的訓(xùn)練數(shù)據(jù)中。

為了解決這些挑戰(zhàn)，提出了以下解決方案：

1. 構(gòu)建新的Benchmark： 建議構(gòu)建一個(gè)新的Benchmark數(shù)據(jù)集，以更全面地評(píng)估和比較APR技術(shù)和LLM在Java漏洞修復(fù)中的性能。這將有助于覆蓋更多的CWE類(lèi)別，并減輕現(xiàn)有數(shù)據(jù)集的不均衡性。

2. 使用代碼轉(zhuǎn)換生成新的保留漏洞的等效程序： 另一個(gè)解決方案是通過(guò)對(duì)已有的漏洞程序進(jìn)行代碼轉(zhuǎn)換，生成新的包含相同漏洞類(lèi)型的等效程序。這將擴(kuò)大可用于評(píng)估的數(shù)據(jù)集，同時(shí)也有助于解決評(píng)估有效性問(wèn)題。

這些解決方案將有助于更全面和準(zhǔn)確地評(píng)估APR技術(shù)和LLM在Java漏洞修復(fù)方面的能力。

貢獻(xiàn)

實(shí)驗(yàn)結(jié)果關(guān)于LLM、Fine-tuned LLM和APR技術(shù)在Java漏洞修復(fù)能力的結(jié)論

實(shí)驗(yàn)初次評(píng)估了5個(gè)LLM、4個(gè)Fine-tuned LLM和4個(gè)APR技術(shù)在兩個(gè)Benchmark數(shù)據(jù)集（Vul4J和VJBench）上對(duì)真實(shí)Java漏洞的修復(fù)能力，得出以下結(jié)論：

1. LLM和APR技術(shù)修復(fù)能力有限： 現(xiàn)有的LLM和APR技術(shù)修復(fù)了很少的Java漏洞，表現(xiàn)出其修復(fù)能力的局限性。

2. Codex表現(xiàn)最佳： 在比較中，Codex顯示出最好的Java漏洞修復(fù)能力，相對(duì)于其他模型，它能夠更有效地修復(fù)漏洞。

3. 微調(diào)LLM： 使用一般的APR數(shù)據(jù)對(duì)LLM進(jìn)行微調(diào)可以提高其漏洞修復(fù)能力，這表明微調(diào)對(duì)提高LLM的性能具有積極作用。

4. 編譯率問(wèn)題： 生成修復(fù)的編譯率是一個(gè)重要指標(biāo)，Codex的最高編譯率為79.7%，而其他LLM和APR技術(shù)的編譯率都較低，表明它們?cè)谔幚砭幾g問(wèn)題時(shí)存在困難。這也可能表明它們?nèi)狈ψ銐虻恼Z(yǔ)法領(lǐng)域知識(shí)。

5. 漏洞類(lèi)型限制： 除Codex外，其他模型只修復(fù)一些簡(jiǎn)單的漏洞類(lèi)型，例如單一刪除、變量或函數(shù)替換。這意味著它們?cè)谔幚韽?fù)雜漏洞方面存在局限性。

6. 新VJBench數(shù)據(jù)集表現(xiàn)： 新的VJBench數(shù)據(jù)集揭示了LLM和APR模型的局限性，它們無(wú)法修復(fù)許多不同的CWE（常見(jiàn)弱點(diǎn)枚舉）類(lèi)型，包括CWE-172編碼錯(cuò)誤、CWE-325缺少加密步驟、CWE-444 HTTP請(qǐng)求竊取、CWE-668資源暴露到錯(cuò)誤的領(lǐng)域，以及CWE-1295調(diào)試消息顯示不必要的信息。

這些實(shí)驗(yàn)結(jié)果提供了有關(guān)LLM、Fine-tuned LLM和APR技術(shù)在Java漏洞修復(fù)方面性能，強(qiáng)調(diào)了Codex的優(yōu)越性，同時(shí)指出了其他模型在處理特定漏洞類(lèi)型和編譯問(wèn)題方面的限制。

普遍情況 微調(diào)效果

編譯率 影響編譯率，什么情況下不能編譯？案例？

只修復(fù)的案例類(lèi)型： CWE-172 Encoding error,CWE-325 Missing cryptographic step,
CWE-444 HTTP request smuggling, CWE-668 Exposure of resource to wrong
sphere, and CWE-1295 Debug messages revealing unnecessary information.

數(shù)據(jù)集和實(shí)驗(yàn)結(jié)果以及未來(lái)發(fā)展方向

1. 數(shù)據(jù)集創(chuàng)建： 為了評(píng)估自動(dòng)程序修復(fù)技術(shù)，研究人員創(chuàng)建了兩個(gè)Java漏洞Benchmark數(shù)據(jù)集：

   • VJBench： 包含42個(gè)可重復(fù)的真實(shí)世界Java漏洞，覆蓋12種新的CWE類(lèi)型。
   • VJBench-trans： 包含150個(gè)轉(zhuǎn)換過(guò)的Java漏洞，這擴(kuò)展了可用于評(píng)估的數(shù)據(jù)集。

2. 代碼轉(zhuǎn)換用于降低威脅： 研究人員使用代碼轉(zhuǎn)換來(lái)減輕LLM和黑盒Codex訓(xùn)練數(shù)據(jù)中可能已經(jīng)看到評(píng)估數(shù)據(jù)的威脅。這有助于確保評(píng)估的準(zhǔn)確性和可靠性。

3. 實(shí)驗(yàn)結(jié)果： 在實(shí)驗(yàn)中，評(píng)估了LLM和APR技術(shù)對(duì)于轉(zhuǎn)換漏洞（VJBench-trans）的修復(fù)能力。實(shí)驗(yàn)結(jié)果顯示：

   • 代碼轉(zhuǎn)換導(dǎo)致LLM和APR技術(shù)修復(fù)的漏洞數(shù)量減少。
   • 一些模型，如Codex和微調(diào)的PLBART，對(duì)于代碼轉(zhuǎn)換更為健壯。
   • 另一方面，有些轉(zhuǎn)換使漏洞更容易修復(fù)。

4. 未來(lái)發(fā)展方向： 提出了關(guān)于未來(lái)研究方向的啟示和建議。

   • 進(jìn)一步改進(jìn)LLM和APR技術(shù)，以提高對(duì)轉(zhuǎn)換漏洞的修復(fù)能力。
   • 開(kāi)發(fā)更多的漏洞Benchmark數(shù)據(jù)集，以更全面地評(píng)估自動(dòng)程序修復(fù)技術(shù)。
   • 探索更多的代碼轉(zhuǎn)換方法，以了解它們對(duì)修復(fù)漏洞的影響。
   • 研究如何提高LLM和APR技術(shù)在處理不同類(lèi)型漏洞時(shí)的健壯性和性能。

數(shù)據(jù)集

先前的數(shù)據(jù)集和Java漏洞Benchmark

這些Benchmark和數(shù)據(jù)集用于評(píng)估和比較自動(dòng)程序修復(fù)技術(shù)的性能和效果，以幫助改進(jìn)漏洞修復(fù)方法。

先前的數(shù)據(jù)集和Java漏洞Benchmark用于評(píng)估自動(dòng)程序修復(fù)技術(shù)：

1. Defects4j： 用于Java漏洞的Benchmark之一，提供了許多不同的項(xiàng)目和漏洞用例供研究和評(píng)估使用。

2. QuixBugs： 另一個(gè)用于Java漏洞的Benchmark，包含一系列有缺陷的程序用例，可用于自動(dòng)程序修復(fù)研究。

3. bugs.jar： 一個(gè)包含Java漏洞的Benchmark，提供了用于測(cè)試和評(píng)估自動(dòng)程序修復(fù)技術(shù)的數(shù)據(jù)集。

4. Bears： 也是一個(gè)用于Java漏洞的Benchmark，包括一系列漏洞用例，可用于研究漏洞修復(fù)。

5. Vul4J： 一個(gè)特定的Java漏洞Benchmark，數(shù)據(jù)來(lái)源包括National Vulnerability Database (NVD)和項(xiàng)目特定的網(wǎng)頁(yè)。它包含了來(lái)自51個(gè)項(xiàng)目的79個(gè)漏洞，覆蓋了25種CWE（常見(jiàn)弱點(diǎn)枚舉）類(lèi)型。值得注意的是，79個(gè)漏洞中有39個(gè)是single-hunk漏洞，由于某些原因，2個(gè)無(wú)法編譯，2個(gè)無(wú)法用Vul4J作者提供的docker重現(xiàn)，最終只能重現(xiàn)35個(gè)single-hunk漏洞。這些單一修補(bǔ)程序的漏洞適用于基于深度學(xué)習(xí)的自動(dòng)程序修復(fù)系統(tǒng)，因?yàn)樗鼈冎话粋€(gè)修補(bǔ)程序。

數(shù)據(jù)集擴(kuò)展要求

i) 相關(guān)的漏洞只能是Java源代碼。
ii) 修復(fù)提交必須包含至少一個(gè)測(cè)試用例 V_fix 通過(guò)，同時(shí) V_bug 不通過(guò)。
iii) 修復(fù)補(bǔ)丁應(yīng)該只包括與修復(fù)漏洞相關(guān)的變化，不應(yīng)引入無(wú)關(guān)的變化或重構(gòu)等特性。
iv) 漏洞不應(yīng)出現(xiàn)在Vul4J數(shù)據(jù)集中。

數(shù)據(jù)處理工作

• 在2022年5月13日，從National Vulnerability Database（NVD）下載了所有可用的JSON格式漏洞數(shù)據(jù)。
• 解析這些數(shù)據(jù)以獲取相關(guān)信息，包括GitHub項(xiàng)目的URL。
• 排除了Java代碼少于50%的項(xiàng)目，最終留下了400個(gè)Java項(xiàng)目，其中包含了933個(gè)獨(dú)特的漏洞。
• 進(jìn)行手動(dòng)檢查，識(shí)別包含漏洞修復(fù)提交的項(xiàng)目，最終得到了698個(gè)漏洞的漏洞修復(fù)提交。
• 過(guò)濾掉了185個(gè)修復(fù)提交中包含非Java更改的漏洞，以及314個(gè)修復(fù)提交中沒(méi)有測(cè)試用例的漏洞，剩下了199個(gè)漏洞，每個(gè)都有測(cè)試用例和相應(yīng)的僅Java修復(fù)提交。
• 使用構(gòu)建工具（如Maven或Gradle）來(lái)重現(xiàn)這些漏洞，確保它們可以在不同環(huán)境中成功編譯和運(yùn)行。
• 最終，得到了42個(gè)未包含在Vul4J數(shù)據(jù)集中的Java漏洞，這些漏洞滿足了先前擴(kuò)展數(shù)據(jù)集的要求。這些數(shù)據(jù)將用于進(jìn)一步研究和實(shí)驗(yàn)。

最終數(shù)據(jù)集 VJBench

• 42個(gè)新的可重現(xiàn)的真實(shí)世界Java漏洞，這些漏洞來(lái)自30個(gè)開(kāi)源項(xiàng)目。
• 其中，27個(gè)漏洞是 multi-hunk（包含多個(gè)補(bǔ)?。┞┒矗瑏?lái)自22個(gè)不同的項(xiàng)目；另外，15個(gè)漏洞是 single-hunk（只包含一個(gè)補(bǔ)?。┞┒矗瑏?lái)自11個(gè)項(xiàng)目。
• 這42個(gè)漏洞涵蓋了23種不同的CWE（常見(jiàn)弱點(diǎn)枚舉）類(lèi)型。

VJBench 與 Vul4J 的比較

• VJBench 擴(kuò)展了 Vul4J 數(shù)據(jù)集，引入了12種新的CWE類(lèi)型，這些類(lèi)型在 Vul4J 中尚未包含。
• 此外，VJBench 補(bǔ)充了 Vul4J 中只有一個(gè)示例的4種CWE類(lèi)型，包括 CWE-78、CWE-200、CWE-310 和 CWE-863。

在最終的研究中，研究人員使用了50個(gè) single-hunk 漏洞，其中包括：

• 15個(gè)漏洞來(lái)自 VJBench。
• 35個(gè)漏洞來(lái)自 Vul4J 數(shù)據(jù)集。

這些數(shù)據(jù)將在研究中用于評(píng)估和比較自動(dòng)程序修復(fù)技術(shù)的性能和效果，為進(jìn)一步研究提供了豐富的實(shí)驗(yàn)數(shù)據(jù)。

大語(yǔ)言模型和APR技術(shù)

大型語(yǔ)言模型

我們選擇了五個(gè)llm，即Codex, PLBART, CodeT5,CodeGen和InCoder，因?yàn)樗鼈兪?br> ⑴最先進(jìn)的，
(2)能夠在不修改模型或額外組件的情況下執(zhí)行代碼生成任務(wù)(例如，CodeBERT[26] GraphCode-BERT[33]除外)
(3)用足夠的源代碼訓(xùn)練，以便它們能夠在一定程度上理解代碼(例如，我們排除了T5[65]，GPT-2 [64],GPT-Neo[13]和GPT-J[71]，其訓(xùn)練數(shù)據(jù)超過(guò)90%是文本)。

在這項(xiàng)工作中，我們研究了兩種設(shè)置下的llm:與一般APR數(shù)據(jù)進(jìn)行微調(diào)。

CodeX[17]

CodeX是一個(gè)基于gpt -3[15,17]的語(yǔ)言模型，其中有12B個(gè)參數(shù)在自然語(yǔ)言和源代碼上訓(xùn)練。我們使用達(dá)芬奇-002模型(截至2022年7月)，這應(yīng)該是最準(zhǔn)確的llm模型[1]。我們關(guān)注的是llm插入模式，因?yàn)樗谖覀兂醪窖芯康娜N主要模式(補(bǔ)全、插入和編輯)中提供了最好的結(jié)果。

CodeT5 [73]

CodeT5是一個(gè)編碼器-解碼器轉(zhuǎn)換器模型[70]，使用標(biāo)識(shí)符感知降噪目標(biāo)和雙峰雙生成任務(wù)進(jìn)行預(yù)訓(xùn)練。它是在520萬(wàn)個(gè)代碼函數(shù)和830萬(wàn)個(gè)自然語(yǔ)言句子的語(yǔ)料庫(kù)上訓(xùn)練的，這些語(yǔ)料庫(kù)來(lái)自包括Java在內(nèi)的六種編程語(yǔ)言。在這項(xiàng)工作中，我們使用了目前發(fā)布的最大的CodeT5模型，它有770M個(gè)參數(shù)。

CodeGen [55]

CodeGen模型是一系列用于會(huì)話程序合成的自回歸解碼器轉(zhuǎn)換器。它們的訓(xùn)練數(shù)據(jù)由來(lái)自pile數(shù)據(jù)集的354.7B自然語(yǔ)言到kens和從谷歌BigQuery數(shù)據(jù)庫(kù)的子集中提取的150.8B編程語(yǔ)言token組成。在這項(xiàng)工作中，我們采用了包含6B個(gè)參數(shù)的CodeGen模型(由于我們機(jī)器的限制，沒(méi)有使用包含16B個(gè)參數(shù)的較大模型)。

PLBART [8]

PLBART使用編碼器-解碼器轉(zhuǎn)換器架構(gòu)，在編碼器和解碼器上有一個(gè)額外的規(guī)范化層。它通過(guò)去噪自動(dòng)編碼對(duì)從Java和Python GitHub存儲(chǔ)庫(kù)中提取的函數(shù)進(jìn)行預(yù)訓(xùn)練。有兩個(gè)不同尺寸的PLBART模型，我們使用包含400M參數(shù)的較大模型。

InCoder [28]

InCoder模型遵循XGLM[45]的純解碼器架構(gòu)，并在掩碼跨度預(yù)測(cè)任務(wù)上進(jìn)行預(yù)訓(xùn)練。它的預(yù)訓(xùn)練數(shù)據(jù)來(lái)自GitHub和GitLab上的開(kāi)源項(xiàng)目，以及StackOverflow帖子。有兩個(gè)不同大小的InCoder模型發(fā)布，我們使用較大的模型，包含6B個(gè)參數(shù)。

實(shí)驗(yàn)：對(duì)于帶有注釋錯(cuò)誤行的輸入

在研究中，由于不清楚帶有注釋錯(cuò)誤行的輸入會(huì)如何影響模型的修復(fù)能力，研究人員進(jìn)行了實(shí)驗(yàn)，比較了帶有注釋錯(cuò)誤行和不帶注釋錯(cuò)誤行的輸入對(duì)于每個(gè)模型的性能。這表示他們分別測(cè)試了兩種情況的輸入。

Suffix： 此外，文中提到了“Suffix”，這可能指的是一種用于截?cái)嗪蟮拇a的補(bǔ)充信息或后綴。這些信息可能有助于理解模型如何處理截?cái)嗪蟮拇a。

關(guān)于Large Language Models的微調(diào)

在研究中，使用了 Fine-tuned Large Language Models（微調(diào)的大型語(yǔ)言模型）來(lái)進(jìn)行漏洞修復(fù)。

• 微調(diào)數(shù)據(jù)來(lái)源： 微調(diào)數(shù)據(jù)來(lái)自開(kāi)源GitHub Java項(xiàng)目，共有143,666個(gè)實(shí)例。每個(gè)實(shí)例包括一對(duì)有bug的代碼和相應(yīng)的修復(fù)代碼。

• 漏洞不在微調(diào)數(shù)據(jù)中： 本文研究的漏洞都不包含在用于微調(diào)LLMs的APR訓(xùn)練數(shù)據(jù)中。這確保了研究的漏洞是新的且未在微調(diào)數(shù)據(jù)中見(jiàn)過(guò)的。

• 微調(diào)設(shè)置： 微調(diào)過(guò)程中使用的設(shè)置包括學(xué)習(xí)率（Lr = 1e-5）、Adam優(yōu)化器、批量大小（batch size = 1）以及訓(xùn)練周期（epoch = 1）。

• 微調(diào)的模型： 微調(diào)了LLMs，但除了Codex。Codex不提供用于微調(diào)的API，因此無(wú)法對(duì)其進(jìn)行微調(diào)。

• 微調(diào)數(shù)據(jù)格式： 在微調(diào)中，有bug的行作為注釋行給出，并將整個(gè)函數(shù)輸入到經(jīng)過(guò)微調(diào)的LLM中，以生成修復(fù)補(bǔ)丁。

• 微調(diào)方式： 微調(diào)的方式類(lèi)似于基于深度學(xué)習(xí)的自動(dòng)程序修復(fù)（DL-based APR）方法，使用相似的訓(xùn)練和微調(diào)流程。

這些微調(diào)的細(xì)節(jié)和設(shè)置用于訓(xùn)練大型語(yǔ)言模型，以提高其在漏洞修復(fù)方面的性能。微調(diào)的數(shù)據(jù)集的選擇和獨(dú)立性確保了模型在新的漏洞上的表現(xiàn)。

我們進(jìn)行了搜索，并確認(rèn)我們?cè)谶@項(xiàng)工作中研究的漏洞都不存在于用于微調(diào)llm的APR訓(xùn)練數(shù)據(jù)中

微調(diào)的損失函數(shù)？ Prior work [38] fine-tuned LLMs with a training dataset
containing 143,666 instances collected from open-source GitHub Java
projects

微調(diào)模型的loss

四種基于深度學(xué)習(xí)的自動(dòng)程序修復(fù) (DL-based APR) 開(kāi)源技術(shù)

在Java漏洞數(shù)據(jù)集上，研究人員進(jìn)行了訓(xùn)練和比較四種最先進(jìn)的基于深度學(xué)習(xí)的自動(dòng)程序修復(fù) (DL-based APR) 開(kāi)源技術(shù)。

1. CURE (Code-aware Neural Networks for Automated Program Repair):

   • 使用一個(gè)小型的語(yǔ)言模型（4.04M代碼實(shí)例）應(yīng)用于CoCoNuT的編碼器-解碼器架構(gòu)。
   • 學(xué)習(xí)代碼語(yǔ)法并提出了一種新的代碼感知策略，通過(guò)在推理過(guò)程中去除無(wú)效標(biāo)識(shí)符來(lái)提高編譯率。
   • CURE 在訓(xùn)練中使用了272萬(wàn)個(gè)APR實(shí)例。

2. Recoder:

   • 使用基于樹(shù)的深度學(xué)習(xí)網(wǎng)絡(luò)，在82.87K APR訓(xùn)練實(shí)例上進(jìn)行訓(xùn)練。
   • 側(cè)重于生成編輯以修改有缺陷的抽象語(yǔ)法樹(shù) (AST)，以形成修補(bǔ)的AST。

3. RewardRepair:

   • 在計(jì)算模型的損失函數(shù)時(shí)，包含編譯作為一項(xiàng)因素，以增加可編譯（和正確）補(bǔ)丁的數(shù)量。
   • 不同于CURE，損失函數(shù)在訓(xùn)練期間增加了可編譯補(bǔ)丁的數(shù)量。
   • RewardRepair 在訓(xùn)練中使用了3.51M APR訓(xùn)練實(shí)例。

4. KNOD (Knowledge-augmented Neural Program Repair with Overlap Decoding):

   • 提出了一種新的三階段樹(shù)解碼器來(lái)生成補(bǔ)丁的AST。
   • 使用領(lǐng)域知識(shí)蒸餾來(lái)修改損失函數(shù)，使模型能夠?qū)W習(xí)代碼的語(yǔ)法和語(yǔ)義。
   • KNOD 在訓(xùn)練中使用了576K APR訓(xùn)練實(shí)例，是最先進(jìn)的基于DL的APR技術(shù)。

這些技術(shù)在訓(xùn)練和推理過(guò)程中采用不同的方法，以提高其在自動(dòng)程序修復(fù)方面的性能。研究人員對(duì)它們進(jìn)行了比較，以確定它們?cè)贘ava漏洞修復(fù)中的相對(duì)性能。

代碼轉(zhuǎn)換：創(chuàng)建未見(jiàn)過(guò)的漏洞及其修復(fù)的目的和方法

研究的目的是為了解決訓(xùn)練-測(cè)試數(shù)據(jù)重疊的挑戰(zhàn)，即確保訓(xùn)練和測(cè)試數(shù)據(jù)之間沒(méi)有太大的重疊，以便更準(zhǔn)確地評(píng)估自動(dòng)程序修復(fù)（APR）技術(shù)的性能。為實(shí)現(xiàn)這一目的，研究人員采取以下方法：

目的： 創(chuàng)建漏洞和其修復(fù)，這些漏洞以前尚未在現(xiàn)有的大型語(yǔ)言模型（LLMs）或APR技術(shù)的訓(xùn)練數(shù)據(jù)中見(jiàn)過(guò)。

針對(duì)數(shù)據(jù)集： 主要針對(duì)兩個(gè)數(shù)據(jù)集，即Vul4J和VJBench，這些數(shù)據(jù)集用于評(píng)估APR技術(shù)的性能。

兩類(lèi)轉(zhuǎn)換：

1. Identifier Renaming（標(biāo)識(shí)符重命名）： 這種轉(zhuǎn)換涉及更改有bug的代碼和相應(yīng)的修復(fù)代碼中的標(biāo)識(shí)符（例如變量名、函數(shù)名等）。這可以幫助創(chuàng)建新的漏洞和修復(fù)，以確保它們與訓(xùn)練數(shù)據(jù)中的不同。

2. Code Structure Change（代碼結(jié)構(gòu)變更）： 這種轉(zhuǎn)換涉及手動(dòng)修改有bug的函數(shù)的代碼結(jié)構(gòu)。對(duì)于每個(gè)有bug的函數(shù)，會(huì)應(yīng)用一系列可應(yīng)用的轉(zhuǎn)換，從而改變函數(shù)的結(jié)構(gòu)。這也有助于創(chuàng)建新的漏洞和修復(fù)。

這些轉(zhuǎn)換的目的是在不改變程序的整體功能的前提下，生成新的漏洞和相應(yīng)的修復(fù)，以確保研究中使用的數(shù)據(jù)集包含未見(jiàn)過(guò)的情況，從而更準(zhǔn)確地評(píng)估APR技術(shù)的性能。

標(biāo)識(shí)符重命名過(guò)程

標(biāo)識(shí)符重命名是一種轉(zhuǎn)換方法，用于創(chuàng)建新的漏洞和修復(fù)，確保它們與訓(xùn)練數(shù)據(jù)中的不同。以下是標(biāo)識(shí)符重命名的具體過(guò)程：

針對(duì)對(duì)象： 對(duì)項(xiàng)目中定義的所有變量、函數(shù)和類(lèi)進(jìn)行同義詞重命名。這些標(biāo)識(shí)符的原始名稱(chēng)必須符合Java規(guī)范，不修改Java默認(rèn)庫(kù)或外部庫(kù)的標(biāo)識(shí)符。

流程：

1. 使用工具 src2abs，首先提取有bug的函數(shù)中的所有變量、函數(shù)和類(lèi)名。從中排除了來(lái)自Java或第三方庫(kù)中的標(biāo)識(shí)符。

2. 使用 Natural Language Toolkit (NLTK) WordNet 為每個(gè)單詞生成同義詞。WordNet是一種詞匯數(shù)據(jù)庫(kù)，包含單詞之間的語(yǔ)義關(guān)系。

3. 然后，重新組裝這些同義詞以形成一個(gè)完整的標(biāo)識(shí)符。這些同義詞可能是在轉(zhuǎn)換后的標(biāo)識(shí)符中的替代名稱(chēng)。

4. 最后，通過(guò)手動(dòng)檢查和調(diào)整同義詞，確保它們?cè)诖a的上下文中合適。這可以防止生成的標(biāo)識(shí)符與代碼的語(yǔ)法和語(yǔ)義不匹配。

這個(gè)過(guò)程有助于在不改變代碼功能的情況下，為代碼創(chuàng)建新的標(biāo)識(shí)符，從而生成新的漏洞和修復(fù)，以用于評(píng)估自動(dòng)程序修復(fù)技術(shù)的性能。

代碼結(jié)構(gòu)更改的六種轉(zhuǎn)換規(guī)則

為了改變代碼結(jié)構(gòu)，研究人員定義了六種不同的轉(zhuǎn)換規(guī)則。這些規(guī)則用于改變代碼的結(jié)構(gòu)，從而生成新的漏洞和修復(fù)，以用于評(píng)估自動(dòng)程序修復(fù)技術(shù)的性能。

1. if條件翻轉(zhuǎn)：

   • 對(duì)if條件進(jìn)行取反操作，并交換if和else分支中的代碼塊。

2. 循環(huán)轉(zhuǎn)換：

   • 將for循環(huán)轉(zhuǎn)換為while循環(huán)，或反之亦然。

3. 條件語(yǔ)句轉(zhuǎn)換：

   • 轉(zhuǎn)換一個(gè)三元表達(dá)式（var = cond ? exprTrue : exprFalse;）為if-else語(yǔ)句（if (cond) { var = exprTrue; } else { var = exprFalse; }），或?qū)⒁粋€(gè)switch語(yǔ)句轉(zhuǎn)換為多個(gè)if和elseif語(yǔ)句，反之亦然。

4. 函數(shù)鏈：

   • 將多個(gè)函數(shù)調(diào)用合并到一個(gè)調(diào)用鏈中，或反過(guò)來(lái)將一個(gè)函數(shù)調(diào)用鏈拆分為單獨(dú)的函數(shù)調(diào)用。例如，value.getClass().equals(...); 可以拆分為 Class value_class = value.getClass(); 和 value_class.equals(...);。

5. 函數(shù)實(shí)參傳遞：

   • 如果局部定義的變量或?qū)ο髢H用作函數(shù)實(shí)參，可以用其定義語(yǔ)句替換函數(shù)實(shí)參，或?qū)⒆鳛楹瘮?shù)實(shí)參傳遞的函數(shù)調(diào)用提取到單獨(dú)的變量/對(duì)象定義中。例如，可以提取參數(shù) parentPath.normalize() 并將其聲明為一個(gè)本地對(duì)象 normalizedParentPath。

6. 代碼順序更改：

   • 如果更改代碼語(yǔ)句的順序不影響執(zhí)行結(jié)果，可以更改語(yǔ)句的順序。例如，funcA(); int n = 0; 可以變換成 int n = 0; funcA();，因?yàn)檎{(diào)用 funcA() 和聲明 int n 之間互不影響。

這些轉(zhuǎn)換規(guī)則的目的是在不影響代碼功能的情況下，生成新的漏洞和修復(fù)，以用于評(píng)估自動(dòng)程序修復(fù)技術(shù)的性能。這確保了測(cè)試數(shù)據(jù)包含不同于訓(xùn)練數(shù)據(jù)的情況。

VJBench-trans 數(shù)據(jù)集轉(zhuǎn)換的結(jié)果

VJBench-trans 是一個(gè)包含經(jīng)過(guò)三組不同轉(zhuǎn)換的 Java 漏洞的數(shù)據(jù)集，旨在解決訓(xùn)練和測(cè)試數(shù)據(jù)重疊的挑戰(zhàn)。

轉(zhuǎn)換的三組：

1. 僅重命名標(biāo)識(shí)符： 這組轉(zhuǎn)換僅涉及標(biāo)識(shí)符的同義詞重命名，用以創(chuàng)建新的漏洞和修復(fù)。

2. 僅更改代碼結(jié)構(gòu)： 這組轉(zhuǎn)換專(zhuān)注于改變代碼的結(jié)構(gòu)，例如更改條件語(yǔ)句、循環(huán)等，以生成新的漏洞和修復(fù)。

3. 同時(shí)進(jìn)行重命名和更改代碼結(jié)構(gòu)： 這組轉(zhuǎn)換結(jié)合了前兩組的轉(zhuǎn)換，旨在同時(shí)重命名標(biāo)識(shí)符并更改代碼結(jié)構(gòu)。

創(chuàng)建過(guò)程：

• VJBench-trans 數(shù)據(jù)集是通過(guò)將這三組轉(zhuǎn)換應(yīng)用于 VJBench 和 Vul4J 數(shù)據(jù)集而創(chuàng)建的，從而生成了包含 150 個(gè)不同轉(zhuǎn)換 Java 漏洞的數(shù)據(jù)集。每組轉(zhuǎn)換應(yīng)用了 50 次，因此共有 3 × 50 = 150 個(gè)轉(zhuǎn)換漏洞。

驗(yàn)證轉(zhuǎn)換后的代碼：

• 轉(zhuǎn)換后的代碼仍然是真實(shí)的和人類(lèi)可讀的。為了評(píng)估可信補(bǔ)丁的正確性，維護(hù)了一個(gè)字典，其中存儲(chǔ)了重命名標(biāo)識(shí)符與其原始名稱(chēng)之間的映射。
• 為每個(gè)漏洞，還編寫(xiě)了相應(yīng)的補(bǔ)丁程序，以針對(duì)經(jīng)過(guò)代碼結(jié)構(gòu)轉(zhuǎn)換的版本，以便將來(lái)的數(shù)據(jù)集用戶參考。

這個(gè)數(shù)據(jù)集的創(chuàng)建和驗(yàn)證過(guò)程有助于確保其中包含了經(jīng)過(guò)不同類(lèi)型轉(zhuǎn)換的漏洞和修復(fù)，以用于評(píng)估自動(dòng)程序修復(fù)技術(shù)的性能，同時(shí)也提供了可信的補(bǔ)丁程序以驗(yàn)證其正確性。

實(shí)驗(yàn)

設(shè)置

• 數(shù)據(jù)集（Dataset）： 研究使用了Vul4J、VJBench 和 VJBench-trans 數(shù)據(jù)集來(lái)評(píng)估自動(dòng)程序修復(fù)（APR）技術(shù)的性能。
• LLM 設(shè)置（LLM Setups）： 采用了四種最先進(jìn)的基于深度學(xué)習(xí)的自動(dòng)程序修復(fù)（DL-based APR）技術(shù)，包括 CURE、Recoder、RewardRepair 和 KNOD。
• 補(bǔ)丁驗(yàn)證（Patch Validation）： 使用了字典來(lái)存儲(chǔ)重命名標(biāo)識(shí)符與原始名稱(chēng)之間的映射，以驗(yàn)證經(jīng)過(guò)轉(zhuǎn)換的代碼中的補(bǔ)丁程序的正確性。

步驟

1. 使用 VJBench 和原始數(shù)據(jù)集 Vul4J 作為基準(zhǔn)進(jìn)行測(cè)試。

   • 每個(gè)語(yǔ)言模型為每個(gè)漏洞生成 10 個(gè)補(bǔ)丁。
   • 每個(gè) APR 模型使用其默認(rèn)的波束搜索大小，并驗(yàn)證前 10 個(gè)補(bǔ)丁。

2. 在 VJBench 和 Vul4J 上應(yīng)用代碼轉(zhuǎn)換，生成 VJBench-trans，以評(píng)估代碼轉(zhuǎn)換對(duì)所有 LLMs、微調(diào) LLMs 和 APR 技術(shù)的漏洞修復(fù)能力的影響。

數(shù)據(jù)集：

• 針對(duì) single-hunk vulnerability（單一修補(bǔ)程序漏洞），共有 50 個(gè)，其中 35 個(gè)來(lái)自 Vul4J，15 個(gè)來(lái)自 VJBench。
• 使用開(kāi)發(fā)人員補(bǔ)丁中修改的代碼行作為錯(cuò)誤行。

波束搜索

• 波束搜索（beam search）是一種搜索算法，它同時(shí)保持多個(gè)修復(fù)候選，然后根據(jù)評(píng)分函數(shù)的計(jì)算結(jié)果選擇最有希望的修復(fù)候選路徑。
• “beam search size”（波束搜索大?。┦侵赣糜谏尚迯?fù)建議的搜索空間的大小。它決定了算法在搜索過(guò)程中保留多少個(gè)備選解決方案。更大的波束搜索大小可以增加搜索空間，但也可能增加計(jì)算成本。波束搜索是常用的搜索算法，用于在大的搜索空間中找到最優(yōu)解或最有可能的解。

LLM 設(shè)置

研究中使用了不同的 LLM 設(shè)置，包括兩種輸入方式，每種方式都觀察到不同的性能表現(xiàn)。

• 兩種輸入方式：

  1. 將錯(cuò)誤行作為注釋輸入： 在輸入中將包含錯(cuò)誤的行（buggy line）作為注釋。
  2. 去除錯(cuò)誤行： 在輸入中去除錯(cuò)誤的行，只保留修復(fù)前的代碼。

• 觀察到 InCoder 在輸入包含錯(cuò)誤行注釋時(shí)修復(fù)了更多漏洞，而其他 LLMs 在沒(méi)有錯(cuò)誤行時(shí)表現(xiàn)更好。

• 針對(duì)每個(gè)模型，選擇了最佳性能設(shè)置，并在該設(shè)置下生成 10 個(gè)補(bǔ)丁。

• 對(duì)于 微調(diào)的 LLMs，使用帶有錯(cuò)誤行注釋的輸入格式。

• 針對(duì)不同的 LLMs，設(shè)置波束搜索大?。╞eam search size）：

  • 對(duì)于 CodeT5、CodeGen、PLBART 和 InCoder，將波束搜索大小設(shè)置為 10。
  • 對(duì)于 Codex，設(shè)置參數(shù) n（要生成的候選數(shù)量）為 10。由于 Codex 采用的抽樣方法具有隨機(jī)性，對(duì)每個(gè)漏洞運(yùn)行 25 次，然后取平均結(jié)果以減小誤差范圍。運(yùn)行了 25 次以在 95% 的置信水平上控制誤差范圍（≤0.3）。

• 由于 Codex 的請(qǐng)求率限制，新生成令牌為 400 個(gè)，而所有其他 LLMs 的新生成令牌為 512 個(gè)。

這些設(shè)置用于確保在評(píng)估各種 LLMs 的漏洞修復(fù)能力時(shí)，使用了合適的輸入方式和參數(shù)配置，以便比較它們的性能。

補(bǔ)丁驗(yàn)證（Patch Validation）

在研究中，采用了不同的補(bǔ)丁驗(yàn)證方法，具體取決于使用的自動(dòng)程序修復(fù)（APR）技術(shù)。

• Codex 插入模式： Codex 使用插入模式生成代碼來(lái)替換原有的有 bug 行。它在前綴提示符和后綴提示符之間生成插入的代碼。前綴提示符包含有 bug 行注釋之前的代碼，而后綴提示符包含有 bug 行注釋之后的代碼。因此，Codex 生成的代碼替換原始的有 bug 代碼。

• CodeT5： CodeT5 生成代碼來(lái)替換其輸入中的屏蔽標(biāo)簽。

• PLBART： PLBART 生成整個(gè)補(bǔ)丁函數(shù)，用來(lái)替換整個(gè)有 bug 的函數(shù)。

• CodeGen 和 InCoder： 這兩種模型生成代碼的補(bǔ)全模型，根據(jù)前綴提示符生成代碼。研究中使用了這兩種模型生成的第一個(gè)完整函數(shù)來(lái)替換原有的有 bug 函數(shù)。

• Fine-tuned LLMs（微調(diào)的 LLM）： 經(jīng)過(guò)微調(diào)的 CodeT5、CodeGen、PLBART 和 InCoder 直接生成補(bǔ)丁代碼來(lái)替換有 bug 的代碼。

對(duì)于每個(gè) LLM 和 APR 技術(shù)，定義了不同類(lèi)型的補(bǔ)?。?/p>

• 合理的補(bǔ)?。≒lausible Patches）： 通過(guò)所有測(cè)試用例的補(bǔ)丁。這些補(bǔ)丁在語(yǔ)法和語(yǔ)義上都是合理的。

• 正確的補(bǔ)?。–orrect Patches）： 在語(yǔ)義上等同于開(kāi)發(fā)人員的補(bǔ)丁。這些補(bǔ)丁不僅通過(guò)測(cè)試用例，還與開(kāi)發(fā)人員的修復(fù)相匹配。

• 過(guò)擬合的補(bǔ)?。∣verfit Patches）： 雖然通過(guò)了所有測(cè)試用例，但在語(yǔ)義上與正確的補(bǔ)丁不等同。

• 測(cè)試是否為合理的補(bǔ)丁： 檢查生成的前 10 個(gè)補(bǔ)丁是否通過(guò)了測(cè)試用例。

• 測(cè)試是否為正確的補(bǔ)?。?/strong> 進(jìn)行手動(dòng)檢查，以驗(yàn)證每個(gè)可能的補(bǔ)丁是否在語(yǔ)義上等同于開(kāi)發(fā)人員的補(bǔ)丁。