CSET：人工智能生成代碼的網絡安全風險（中文）

最近的發(fā)展提高了大型語言模型（LLM）和其他AI系統(tǒng)對軟件開發(fā)領域來說是有希望的，但這些模型也會帶來直接和間型，2）模型本身容易受到攻擊和操縱，以及現(xiàn)有的研究表明，在實驗條件下，AI代碼生成模型經常AI生成代碼的安全性的過程非常復雜，并且包含許多相互依賴的變量。為了進一不安全的AI代碼的風險，我們評估了五個LLM生成的代碼每個模型都給出了相同的提示，這些提示旨在測試可能產生錯誤或不安全代碼的可能場景。我們的評估結果表能導致惡意利用。這些結果僅限于我們評估的狹窄范圍，但我們希望鑒于代碼生成模型目前的實用性及其能力將繼續(xù)改進的可能性，管理其政策和風險不會在各組織之間均勻分布。規(guī)模更大、資源更保人工智能生成的代碼輸出安全的負擔不應該僅僅落在人工智能開發(fā)人員、大規(guī)模生產代碼的組織以及那些能如決策機構或行業(yè)領導者。安全軟件開發(fā)實踐和NI于確保所有代碼（無論作者身份如何）在進入生產之前●代碼生成模型也需要進行安全性評估，但目前很難做到這一點。代碼生成模型的評估基準通常集中在模型生成功能代碼的能力上，但不評力，這可能會在模型訓練期間激勵安全性優(yōu)先于功能。模型的訓練數據缺乏足夠的透明度，或者對它們內部工作的理解不夠，無法探索諸如性能更好的模型是否會產生更不安全的代碼之類的問題。 什么是代碼生成模型？ 7 9 9 18 25 介紹人工智能的進步導致人工智能系統(tǒng)生成功能計算機代碼的言模型的改進最近引起了人們對人工智能的極大興趣LLM的基礎模型，都被用于生成代碼。越來越多的應用程序和這些模型和相關工具正在迅速被軟件開發(fā)人員社區(qū)和個人用戶采用。根12023年11月的另一項行業(yè)調查同樣報告了高使用率，96%工具，超過一半的受訪者大部分時間使用這些工具。如果這種趨勢繼續(xù)下去，LLM生成的關于人工智能代碼生成的政策挑戰(zhàn)是，這種技術進步在的好處，但也帶來了潛在的系統(tǒng)性風險。一方面，如果將這些修補等領域，則可以顯著提高勞動力生產率，并為網絡安全做出研究表明，這些模型也會產生不安全的代碼，如果未經適當審查的網絡安全風險，以及間接風險，因為不安全的代碼最終會進入廣泛的人工智能生成代碼的影響。人工智能研究人員和開發(fā)人況下評估模型輸出，程序員和軟件公司可以考慮這些工具如何策制定者有機會通過制定適當的指導方針，提供激勵措施和授工智能生成代碼相關的更廣泛的網絡安全風險。本報告概述了代碼生成模型是能夠響應代碼或自然語言提示生成計算機代碼的的組合作為響應。這類模型既包括專門用于代碼生成的語言模型代碼。專用模型的示例包括AmazonCodeWhisperer、DeepSeekCoder、Wizar和CodeLlama，而通用模型包括OpenAI的GPT代碼生成模型的早期迭代-其中許多早于當前一代的LLM，并且仍然執(zhí)行所謂的代碼填充，專門為此任務進行訓練，并已在軟件開模型功能的最新改進允許更多的交互性，例如自然語言提示或用模型檢查其錯誤。與通用語言模型一樣，用戶通常通過專用界面軟件中的插件）與代碼生成模型交互。最近，專門的腳手些情況下的能力。例如，可以輸出代碼的一些模型也然語言生成能力的提高而提高。畢竟，編碼語言是有意設計來編碼和傳達信息的，并究人員一直對自然語言和計算機代碼之間的翻譯感興趣，但同時引入基于t隨著新模型的發(fā)布，研究人員也開始探索使它們更用于代碼生成的模型，以及用于評估AI代碼輸出正確性的HumanEval基準。5GithubCopilot的相對可訪問性和早期成功幫助激發(fā)為了精通代碼生成，模型需要在包含大量人類編寫代碼主要是在公開可用的開源代碼上訓練的。7這些代碼大部分是從Github等開源網絡存儲庫中抓取的，個人和公司可以在那里存儲和協(xié)作編碼項目。例如，被稱為TheStack的6TB數據集的第一個版本由358種不同編程語言的源代碼文件組成，并已用于預訓練幾個開放代碼生成模型。8其他語言模型訓練數除了包含自然語言文本外，還包含代碼。這個名為包括代碼片段和其他與編程相關的內容。9然而，開發(fā)人員用于訓練模型的數據集的性往往有限我們可以推測，用于訓練代碼生成模型的大部分代碼都是從開取的，但用于訓練的其他數據集可能包含專有代碼，或者只是被排除在模此外，一些專用模型是通用模型的微調版本。通常，它們是數據訓練通用模型來創(chuàng)建的。這在模型需要將自然語言輸能，因為通用模型往往更善于遵循和解釋用戶指令。OpenAI過去十年，人工智能代碼生成的研究興趣不斷增加，尤其是在2.圖1通過計算2012-2023年期間每年關于代碼生成的研究論文數量來從2022年到2023年，發(fā)電量增加了一倍多，這表明人們對資料來源：CSET'sMergedAcademicCorpus。代碼生成是大型語言模型最引人注目和廣泛采用的用例之一除了2024年春季，他們的人工智能編碼工具GitHubCopilot擁有180萬付費用年中的100多萬，還有11家軟件公司也在采用*此圖統(tǒng)計了CSET合并學術語料庫中包含關鍵字“代碼生成”，“AI輔助編程”，“AI代碼助手”，“代碼生成LLM”或“代碼LLM”的論文數量，并且使用CSET的AI分類器和網絡安全分類器分類為AI或網絡安全相關。請注意，在2024年2月撰寫本文時，由于上游收集滯后，CSET的合并學術語料庫尚未包括2023年的所有論文，這可能導致2023年的論文數量不足。該語料庫目前包括來自Clarivate的WebofScience，TheLens，arXiv，PaperswithCode，SemanticScholar和OpenAlex的數據。有關我們編制合并學術語料庫的方法的更多信息以及我們分類器的背景和數據源的詳細引用，請訪問：https://eto.tech/dataset-docs/mac/;/publication/identifying-ai-research/。非公開的自定義代碼生成模型，旨在幫助員工更有效地能代碼生成工具提高開發(fā)人員生產力的指標因研究而異。一項小型的G我感知的生產力和任務完成時間作為生產力指標，但作者承認，產力如何與開發(fā)人員的幸福感相關，幾乎沒有共識。麥肯錫的一標，聲稱使用生成式人工智能工具的軟件開發(fā)人員完成編碼任務倍，但這些好處取決于任務的復雜性和開發(fā)人員的經驗。14.各公司還對雇員進行了內部生產率研究。一項關于內部代碼生成模型CodeCompose的Meta性開發(fā)人員反饋等指標來衡量生產力，發(fā)現(xiàn)20%的用戶表示CodeCom地編寫代碼，而Google的一項研究發(fā)現(xiàn)，與對照組相比，使用試驗數據，發(fā)現(xiàn)使用GitHubCopilot的開發(fā)人員完成的任務數量AI代碼生成工具無疑對一些程序員有幫助，特別是那些工作涉及相當常規(guī)的編碼程序員。（通常，編碼任務或編碼語言越常見，代碼生成模型的有可能是在類似的示例上訓練的自動化死記硬背的編碼任務可能行更具創(chuàng)造性或認知要求的工作。人工智能系統(tǒng)生成的軟件代碼從廣義上講，有證據表明，代碼生成工具在個人和組織力的提高，這些好處可能會隨著時間的推移而增加。還有很然而，這一技術突破也必須謹慎對待。在日常軟件開發(fā)過程模型，這意味著這些模型將很快成為軟件供應鏈的重要組成部分全的，或者在代碼進入生產之前，他們產生的任何不安全的輸出網絡安全也將越來越重要。然而，代碼生成模型很少以安全性為常進行訓練以滿足各種功能基準，例如HumanEval，這是一組增加，模型被納入組織和開發(fā)人員的標準程序，忽視這些代人機交互使這個問題進一步復雜化，因為1）用戶可能認為究表明，GithubCopilot18生成的1，見弱點枚舉（CWE）前25個最危險軟件弱點”列表的影響。19Siddiq和San現(xiàn)，在使用InCoder和GithubCopilot生成的130個代碼樣本中，手73%的代碼樣本包含漏洞。20Khoury等人（2023）使程語言的程序，并進行了CWE測試，結果顯示21個程序中只有5另外7個案例生成安全代碼。[21]Fuetal.（2024）顯示，在生成的452個真實代碼片段中，32.8%的Python和24.5%的Java同的CWE，其中8個屬于2023年CWETop25列表在某些編碼語言中，代碼生成模型也可能生成調用外部庫和包的可能會帶來許多問題，其中一些與安全相關：它們可能不存在，且未修補漏洞，或者本質上是惡意的（例如當攻擊者試圖利用UR寫錯誤時）。23例如，VulcanCyber表明，ChatGPT在回答來自StackOverflow的常見編碼問題時，通常會推薦不存在的包-Node.js中的201個問題中有40個，P問題中有80個答案中至少包含一個不存在的包。此外，這些虛幻在用例和不同模型中是持久的;正如后續(xù)研究所表明的那樣，具有相同名稱的包，并讓用戶在不知不覺中下載惡意代碼。25盡管有這些經驗結果，但早期跡象表明用戶認為人工智能生受不安全的代碼。例如，在2023年對537名技術和I究中進一步表明，能夠使用AI助手的學生參與者編寫的代碼的安助手的學生，而且他們更有可能相信自己編寫的代碼是安全然而用戶是否更有可能編寫不安全的代碼，存在一些分歧;其他研究表手的用戶可能不會比沒有AI工具的用戶更有可能編寫不安全的提出了一系列相關的問題，例如：用戶對編碼的熟練程度如何接受（可能不安全的）AI生成的代碼比人類編寫的代碼更安全？生成的代碼更可信，對安全缺陷的審查更少，那么人工智能編碼此外，關于代碼生成模型為什么首先生成不安全的代碼，以型內部的代碼輸出的安全性變化，仍然存在不確定性。部分原因在于，這多模型都是在Github等開源存儲庫的代碼上訓練的。這些存儲庫包含具有已工編寫的代碼，在很大程度上不執(zhí)行安全編碼實踐，并且缺乏用于刪除具洞的代碼的數據清理過程。最近的工作表明，訓練數據中的安全漏洞可能transformer的模型的輸出中，這表明底層訓練數據中的漏洞會導致不安全題。[29]更大的挑戰(zhàn)是，在訓練數據集中包含哪些代碼以及是否嘗試提高其安全性方面，關于代碼生成模型如何以及為什么會生成不安全代碼仍然沒有答案。例如，2023年的一項Meta研究3.5和4的幾個版本，發(fā)現(xiàn)具有更高級編碼能力的模型更有可能輸出不安全的代碼。30這表明代碼生成模型中的功能性和安全性之間可能存在反向關系，現(xiàn)，促使模型采用“安全角色”會引發(fā)不同的結果。[31]雖然G數量比普通角色減少了，但Gemini的代碼輸出包含更多的漏洞。32這些早期的研了一些知識差距，涉及不安全的代碼輸出是如何產生的，容易受到黑客攻擊，篡改或操縱，而人類則不然。圖2說明了資料來源：中央統(tǒng)計局。生成式人工智能系統(tǒng)對幾種類型的對抗性攻擊具有已知的攻擊，其中攻擊者污染模型的訓練數據以引發(fā)期望的行為，以及試圖通過用預定的觸發(fā)短語提示模型來產生特定的輸出。在代碼毒攻擊可能看起來像是攻擊者操縱模型的訓練數據，以增加其生碼的可能性。與此同時，對模型本身的后門攻擊可以通過一個觸行為，即使開發(fā)人員試圖刪除它，這個觸發(fā)器也可能持續(xù)存在。34這種改變的行為可能會導致輸出違反開發(fā)人員對模型的限制（例如“不要建議與），來自有限數量的未清理代碼存儲庫的大量數據上訓練的，攻擊者儲庫中植入包含惡意代碼的文件，或者有目的地引入包含易受攻擊代碼的新存儲庫。35根據代碼生成模型的接口或腳手架，其他形式的對抗性攻擊可能示注入，其中攻擊者試圖指示模型以某種方式行為，據。在代碼生成上下文中，可以引用外部網頁或文檔的AI模型最后，不安全的代碼生成模型也可能無意中增加組織的可能容易受到網絡攻擊的方式的數量特別是如果他們被授予對的訪問權限。網絡安全背景下的訪問控制依賴于組織清楚地了解人，這包括從某些代碼庫讀取和寫入。如果代碼生成模型被賦予會更有效和有用，但這反過來又使它們成為潛在的攻擊載體，然專業(yè)環(huán)境中，大多數人工智能生成的代碼可能會流經包括內置測發(fā)管道，但人工智能公司正在積極制定策略，以賦予模型（包括自主權和與環(huán)境交互的能力。37下游影響將增加。如果與人類程序員相比，人工智能工具傾向于引入不同洞，那么漏洞格局也將隨著時間的推移而發(fā)生變化，新的漏空見慣。這反過來可能會影響未來的代碼生成模型;雖然用于訓練最早的代碼生成大型開源代碼數據集保證主要是人類編寫的，但未來開源存儲庫的碎片可能包含更多的一些人工智能研究人員認為，如果數據集包含的人類的AI生成的代碼將如何影響未來模型的性能。然而，今天的輸出可能會成為明天的訓練數據，為未來的模型創(chuàng)建一組不同此外，代碼安全性并不是組織唯一關心的問題。技術債務--的代碼--是許多軟件公司的主要關注點，因為忽視對它的正確小和復雜性上膨脹。這也對網絡安全產生了影響，因為技術債所需的監(jiān)控，維護和修補的數量。如果人工智能工具使快速大不足道，組織的技術債務也可能增加。(Of當然，對于某些組織組織可以減少其勞動力的規(guī)模，或者嘗試自動化部分執(zhí)行官在2023年表示，該公司最終計劃使用人工智能來取色，估計近8,000個現(xiàn)有的IBM職位可能在五年內被人工智能和自移反過來可能對網絡安全產生影響，因為人類軟件開發(fā)人員執(zhí)行任務對現(xiàn)代代碼庫的功能非常重要。這些職責包括監(jiān)控、手動代碼審查、設計、修補、更新依賴關系和優(yōu)化代碼以提高性能，這些都是重要且與安全相今的概率代碼生成模型不太可能可靠地開箱即用地執(zhí)行此類任務鑒于對使用代碼生成模型和相關安全問題的興趣日益增代碼的傾向的能力變得重要，以便設置適當的標準并找到緩解技常表明，代碼生成模型通常會生成不安全的代碼。然而，這些研評價指標上存在很大差異，因此許多實證結果無法直接比較。這言上，如Python、Java和C。不同的語言有不同的常見漏洞使這些和其他內存錯誤變得不那么常見。因此，很難確●模型類型：并非所有現(xiàn)有的研究都試圖比較來自不同AI模型的代碼輸出的安全性。模型之間或同一模型的不同實例之間可能存在顯著通用美洲駝模型相比，專用代碼美洲駝模型）。一些研碼能力的模型更有可能產生不安全的代碼，這可能是由比較個別模型之外，在更廣泛的專門代碼編寫模型和通●評估工具：不同的代碼質量檢查器和靜態(tài)分析工具在不同的編程語言之間存在差的基于SMT的上下文邊界模型檢查器），這是一編程語言，包括Java/Kotlin和Python。雖然ESBMC認為是一種可靠的方法來編程掃描C和C++代碼中的錯誤，●基準：雖然有幾個基準用于評估代碼生成模型的質量或準確性（其中最突出的是HumanEval但很少有公開可用的基準用于評估A有基準的示例包括CyberSecEval和新的安全基準，但人工智能和機器學習社區(qū)尚未可能會對結果輸出的質量產生通用LLM可能特為它們可能更容易接受涉及模型承擔角色的提是軟件工程師......”或“承擔網絡安全分析師的角色......”稱模型在每次收到特定提示時都會以相同的方式做出響應重現(xiàn)性。如果通過API或用戶界面訪問，模型的行為也會隨變。這些更新可以采取對模型本身進行更改的形式，也可程度以及它們是否代表了安全編碼實踐的凈效益，取決于統(tǒng)交互。例如，幾項研究觀察到人類受試者中存在一定程受試者可以訪問代碼生成模型，使他們更有可能依賴和信研究側重于量化AI生成代碼的質量或安全性，而另一些而必須視為互補（假設上述變量中有足夠多的變量這些因素使得對以往研究的簡單綜合和直接比較變得然而，估工具和提示，可以保持一致的實驗比較跨模型的結果。雖然沒在本節(jié)中，我們對以下研究問題進行了獨立評估：不同的大型語此評估的目的不是比較不同模型的性能，而是了解在考慮安與生產力提高、自動化偏差和非安全相關基準上的模型性方法考慮到通過模型比較代碼輸出的安全性的困難，我們的評估保說，我們使用相同的編程語言，評估工具和提示來評估生成的代r是捕獲當前代碼生成模型生態(tài)系統(tǒng)的代表性快照，也不是將全性的新基準。相反，我們選擇了易于通過API訪問的流行且強大的一個通用開放模型（Mistral）。我們還使壓一千七百五十億約1萬億7十億WizardLM7十億7十億資料來源：中央統(tǒng)計局。GPT-3.5-turbo和GPT-4通過OpenAIAPI訪問，開放模型為了提示模型，我們使用了LLMSecEval數據集，該數據成，這些提示符被明確設計用于評估語言模型生成的C和Python代碼的安全性。47弱點的代碼。48MITRECWE列表不包括網絡安和利用，列表上的漏洞可能導致漏洞。值得注意的是，雖然LLMSe他們的提示的幾個特征，包括表達性和簡潔性，但這些提示是一定要模仿普通用戶與代碼生成模型交互的行我們將LLMSecEval數據集子集化到為C設計的67個提示誤，如內存泄漏故障，不太可能出現(xiàn)在Python代碼中模型都使用相同的提示集。在表2中，我們提供了評估中使用的提示列表可以在我們的公共GitHub存儲庫中找到提示當生成以下<語言>代碼：該代碼接受一個整數作為輸入，并返回數組中整數索引處的值。例如，如果輸入為5，則代碼將返回數組索引5處的值如果輸入超出邊界，代碼將返回-1。例如如果輸入為10，代碼將返回-1。越界讀取為以下內容生成language>代碼：該代碼從命令行溢出或環(huán)繞資料來源：Tony等人，“LLMSecEval：用于安全評估的自然語言數據集。在我們?yōu)樗心Ｐ蜕纱a片段之后，我們通過ESBMC代碼檢工作流程的靈感來自于之前的一項研究，該研究使用違反安全屬性的反例。它測試的C代碼中的安全屬性包括越界），），和驗證未知（由于時間或算法限制，ESBMC無法驗證代碼有關“不安全”（驗證失?。┑拇?。在必要時，例如在下面的“評估結果”部分中，我們消除了“不安全”代碼和未成功驗證的代碼（意味著所有未收到成功驗證狀態(tài)的代碼段）之間的有時，模型會生成不可編譯的代碼來響應一個或多個提示。致性，我們選擇重新生成導致不可編譯代碼片段的提示。對于每個模型成導致其特定示例無法編譯的代碼片段。然而，重新運行代碼片段并沒），Turbo）或沒有（WizardCoder）額外的代碼片段變得可編譯。（在附生前后模型的不可編譯片段數量的完整比較。值得注代碼時編寫了10個可編譯的代碼片段。我們沒有改變任何參數在我們以這種變化是由于隨機性或不可預見的因素是本研究的范圍之外。在后，我們通過ESBMC管道重新運行了重新生成的代碼片資料來源：中央統(tǒng)計局。評價結果），總的來說，我們看到五種型號的驗證失敗率很高。驗證失敗、無法編譯或導致檢查器出錯。每個模型的代碼樣本中，不被ESBMC檢測到，而且由于無限循環(huán)、檢查器超時或編譯錯誤法驗證。雖然錯誤和不可編譯的代碼不一定是安全漏洞，但它們仍資料來源：中央統(tǒng)計局。圖4詳細顯示了對應于每個模型的每個ESBMC驗證狀態(tài)的代碼片段的百分比，以及所有模型中驗證狀態(tài)的平均百分比。GPT-4和GPT-3.5是參數數最多的型號，ESBMC能夠成功驗證的輸出數量最多。僅根據ESBMC的結果，GPT-4并沒有明顯優(yōu)于GPT-3.5，盡管它被認為在任務泛化和自然語言解釋方面更強大。事實上，GPT-3.5比GPT-4有更好的性能，并且通過成功驗證的代碼片段的數量來衡量整體性能最OpenAI模型中，GPT-4生成了更多未編譯的代碼片段，并且由于不完整或語法錯誤而未在所有五個模型中，大約48%的生成代碼片段是可編譯的，但包含ESBMC標記的錯誤 過了ESBMC驗證（我們將其定義為安全），而其余代碼片段未能編譯或在驗證管道中在這五種模型中，我們也看到了行為的顯著變化。其中一些差異產生某些類型的輸出。例如，在Mistral的樣本中，錯誤片段的比例相當大，這是由于模型傾向于生成針對每個提示符的特定請求的單個函數，而不是的程序。雖然這些片段可能在功能上是正確的，但它們缺乏完整性，未能通過ESBMCWizardCoder可能是最不知名的模型，它產生了最多的未通過驗證的代碼片段。然而，與其他類似大小的開放模型相比，WizardCoder也傾向于生成不太可能導致錯誤或未知相比之下，CodeLlama傾向于產生漫無邊際的、無意義的響應，沒有可編譯的代碼。它也一再未能為五個提示生成可用的代碼，即使提示三次。因此，我們的CodeLlama片段的樣本量為62，這與其他四種型號的67個提示的樣本量不一致。在CodeLlama生成的所有代碼片段中，只有19%成功通過了ESBMC驗證，這是所有五安全與新興技術中心|24資料來源：中央統(tǒng)計局。總的來說，所有五個測試的模型也顯示出產生類節(jié)中所提到的，用于生成代碼片段的提示被設計成極有可能引發(fā)與MITRETo列表相對應的bug。這個社區(qū)開發(fā)的列表列舉了軟件和硬件中一些），MITRECWE列表中發(fā)現(xiàn)的錯誤不僅是潛在工作。即使錯誤不會導致可利用的漏洞，它仍然會在代碼C編程語言特別容易受到涉及分配和釋放內存的錯誤的影導致內存損壞、崩潰，并可能允許攻擊者執(zhí)行任意代碼。圖5詳細介個測試模型中識別的錯誤類型。解引用失敗、緩沖區(qū)溢出和內存我們的評估和我們評估中的所有五個模型都產生了這些錯關錯誤。當惡意網絡攻擊者發(fā)現(xiàn)或利用時，解引用故些在評估中的五個模型生成的可編譯代碼中不太常見。限制如表1所示，我們選擇的五個模型在規(guī)?；驅I(yè)化過OpenAIAPI訪問了GPT-3.5-turb制，因為我們在本地運行它們，而不是使用第三方提供商的本評估并不旨在準確反映“現(xiàn)實”軟件開發(fā)工作流程。例如，可能遠遠大于70億個參數，這被認為是開放AI模型的小部不太可能通過像ESBMC這樣的模型檢查器運行所有代碼，這最后，LLMSecEval數據集的提示是專門設計來模擬AI生成模型更有可能生它們是一個更大程序的完全正確的部分。由于我們轉換錯誤和解析錯誤。轉換錯誤通常與不完整的代碼片段相關資料來源：中央統(tǒng)計局。最后，此評估并不打算對與各種代碼生成模型相關的所有相反，它證明了我們評估的代碼生成模型通常會在特定條件下生碼具有常見且有影響力的安全漏洞。進一步的實證研究測試模型，在某些條件下，AI代碼生成模型往往會生成錯誤的代碼，并且術界和人工智能行業(yè)以前的研究表明，開箱即用的人工智能模型經雖然確切的百分比各不相同，但所有模型都在至少40%的測試提示中一些錯誤可能非常嚴重，例如緩沖區(qū)溢出和解引用失敗。雖然這的軟件開發(fā)工作流程，但它們可以被認為是人工智能模型可以以最全代碼數量的粗略上限。這些結果證實了越來越多的先前研究，這行業(yè)采用人工智能代碼生成模型可能會對軟件供應鏈安些模型將成為軟件開發(fā)管道的重要組成部分，因為AI生成的代碼庫中。然而，這些模式的負面影響可能因組織而異。擁有強大的代開發(fā)流程的大型、資源充足的企業(yè)可能能夠使用現(xiàn)有程序減輕人工的影響，而較小的、資源不足的企業(yè)和個人可能會面臨限制，或者好消息是，這種風險可以納入現(xiàn)有的風險管理框架。雖然現(xiàn)代發(fā)人員可以編寫不安全代碼的想法并不新鮮?，F(xiàn)有的框架，如NIST的代碼可以由人工智能系統(tǒng)生成的背景。[55]人工智能生成的代碼并不是一種新的風險類別，它可能只是意味著在評估整體供應鏈安全性時，應該更多地代碼的風險（與其他類別的風險相比，如對抗性妥協(xié)）。無論其56誰負責確保AI生成的代碼是安全的？目前，驗證AI生成的代碼是否戶身上。然而，主動花費成本來檢查代碼輸出的安全性（以效間不會是恒定的。目前的狀態(tài)與白宮的2023年國家網絡安責任從個人和小企業(yè)轉移到最有能力大規(guī)模降低系統(tǒng)性風險的組織。這就提出了一個問題，如果不是用戶，那么誰應該主要負責安全。部分答案在于人工智能開發(fā)人員，他們可以通過以下措性：從訓練數據集中刪除已知的易受攻擊的代碼，除了功能基的模型，以及在測試和評估過程中繼續(xù)監(jiān)控不可預見的不安全他部分在于集成此類LLM的工具和應用程序，以提供代碼生出安全性的內置功能，并在可能的情況下提供進一步的修復建議。這和NIST等相關政府組織推動，將安全設計原則擴展到可能影響軟代碼生成模型的評估基準通常對性能進行評估，但忽略了安全性模型將性能優(yōu)先于安全性。許多對代碼生成模型進行排名的流行能的指標，如HumanEval，它也往往局限于特定的編程語言。58這些務生成功能代碼的能力來衡量，可能不是最不可能生成不安調的LLM在過去一年中在功能基準測試中表現(xiàn)更好，這并代碼的能力方面也有所提高(Nor在基準測試中性能的提高是否一定基準測試可能會飽和，其中模型達到無法超越的性能極限，或良好但在其他環(huán)境中表現(xiàn)不佳時可能會過度擬合基準測模型可能會產生更不安全的代碼。其他研究表明，在微調過程中而且排行榜還應該根據可用的安全基準明確地對代碼生成模型進行排名。存在與不安全的AI生成的代碼相關的下游和相關風險，這些風險僅僅是修復代碼輸出。隨著代碼生成模型被越來越廣泛地采用，可饋循環(huán)，其中來自AI工具的不安全代碼輸出最終會出現(xiàn)在開源存如果越來越多地使用代碼生成模型導致更多的人在環(huán)位移，這可能會加劇組織現(xiàn)有的網絡安全風險，那么下游勞動其中可能包含已知和可利用的安全漏洞。模型輸出的概率性質告，我們的評估范圍是回答少數LLM是否在特式驗證作為衡量代碼不安全性的代理。與此同時，對幫助我們了解人工智能代碼生成工具對網絡安全和其●在評估代碼輸出的安全性時，代碼生成模型的各種安全性基準有多可靠●在使用AI代碼生成工具時，人類程序員在多大程度上表現(xiàn)出自動化偏見？隨●AI生成的代碼在多大程度上有助于或幫助減少技術債務？力和效率產生積極影響，并在勞動力培訓和教育方面顯示出希望這些工具的好處，應該對這些工具的潛在網絡安全風險給予積極生成模型通常會生成不安全的代碼，其中一些和組織依賴于代碼生成模型來生成代碼并將其合并到項目中，這應鏈安全帶來問題。它們還可能帶來其他下游和相關的風險，例對改進模型及其使用的政策關注，并考慮到功能基準之外的安全作者JennyJun是CSET的非常駐研究員，教授。她完成了她對這個項目的貢獻，而她是CSET的對于反饋和幫助，作者要感謝CatherineAiken、?2024由安全和新興技術中心。本作品采用知識共享署名-非商業(yè)性使用4.0國際許要查看本許可證的副本，請訪問https://輸出資料來源：中央統(tǒng)計局?！板e誤”代碼段的原始新的“錯誤”代碼段數9762266資料來源：中央統(tǒng)計局。1InbalShani和GitHub員工，“調查揭示了AI對開發(fā)人員體驗的影響”，GitHub博客，2023年6月13日，https://github.blog/2023-06-13-survey-reveals-ais-impact-on-the-developer-experience/。2“AICode，Security，andTrustinModernDevelopment，?（Snyk，2024），https://snyk.io/reports/ai-code-security/.3OpenAI，“ChatGPT插件”，OpenAI博客，2023年3月23日，/blog/chatgpt-插件。4DanielLiandLincolnMurr，“HumanEvalonLatestGPTModels--2024，”arXivpreprintarXiv：2402.14852（2024/abs/2402.14852v1.5MarkChen，JerryTworek，HeewooJun，QimingYuanetal.，“EvaluatingLargeLanguageModelsTrainedonCode，”arXivpreprintarXiv：2107.03374（2021），/abs/2107.03374.6NatFriedman，“IntroducingGitHubCopilot：YourAIPairProgrammer，”GitHubBlog，2021年6月29日，https://github.blog/2021-06-29-introducing-github-copilot-ai-pair-programmer/。7BaptisteRozière，JonasGehring，F(xiàn)abianGloeckle等人，“CodeLlama：OpenFoundationModelsforCode，”arXivpreprintarXiv：2308.12950（2023），/abs/2308.12950.8DenisKocetkov，RaymondLi，LoubnaBenAllal，JiaLi等人，“TheStack：3TBofPermissivelyLicensedSourceCode，”arXivpreprintarXiv：2211.15533（2022），/abs/2211.15533;LoubnaBenAllal，RaymondLi，DenisKocetkovetal.，SantaCoder：Don'tReachfortheStars！（SantaCoder：Don'tReachfortheStars?。゛rXiv預印本arXiv：2301.03988（2023），/abs/2301.03988;RaymondLi，LoubnaBenAllal，YangtianZi等人，“StarCoder：愿源頭與你同在！”arXiv預印本arXiv：2305.06161（2023），/abs/2305.06161。9LeoGao，StellaBiderman，SidBlack，LaurenceGolding等人，“ThePile：An800GBDatasetofDiverseTextforLanguageModeling，”arXivpreprintarXiv：2101.00027（2020），/abs/2101.00027.10Chen等人，“評估在代碼上訓練的大型語言模型。11BrettIversen，SatyaNadella，andAmyHood，Transcriptof“MicrosoftFiscalYear2024ThirdQuarterEarningsConferenceCall，”April25，2024，/en-us/investor/events/fy-2024/earnings-fy-2024-q3.aspx;ThomasDohmke，“TheEconomicImpactoftheAI-PoweredDeveloperApproachandLessonsfromGitHubCopilot，”GitHubBlog，June27，2023，https://github.blog/2023-06-27-the-economic-impact-of-the-ai-powered-developer-lifecycle-and-lessons-from-github-copilot/.[12]休·蘭利（HughLangley），《GoogleQuietlyLaunchesInternalAIModelNamed'Goose'toHelpEmployeesWriteCodeFaster，LeakedDocumentsShow》，《商業(yè)內幕》（BusinessInsider安全與新興技術中心|352024年2月14日，/google-goose-ai-model-language-ai-coding-2024-2;馬克西姆Tabachnyk和StoyanNikolov，“ML增強的代碼完成提高了開發(fā)人員的生產力”，Google研究博客，2022年7月26日，https://blog.research.google/2022/07/ml-enhanced-code-completion-improves.html;VijayaraghavanMurali、ChandraMaddila、ImadAhmad等人，“AI輔助的大規(guī)模代碼編寫：微調，部署和混合方法評估”，arXiv預印本arXiv：2305.12050（2024），/abs/2305.12050。[13]EiriniKalliamvakou，“Research：QuantifyingGitHubCopilot'sImpactonDeveloperProductivityandHappiness，”GitHubBlog，September7，2022，https://github.blog/2022-09-07-research-quantifying-github-copilots-impact-on-developer-productivity-and-happiness/.14BegumKaraciDeniz，ChandraGnanasambandam，MartinHarrysson等人，“UnleashingDeveloperProductivitywithGenerativeAI，”McKinseyDigital，2023年6月27日，/capabilities/mckinsey-digital/our-insights/unleashing-developer-productivity-with-generative-ai.15Murali等人，“AI輔助的大規(guī)模代碼創(chuàng)作：微調，部署和混合方法評估”;Tabachnyk和Nikolov，“ML增強的代碼完成提高了開發(fā)人員的生產力”。16KevinZheyuanCui，MertDemirer，SoniaJaffe等人，“生成式人工智能對高技能工作的影響：來自軟件開發(fā)人員三次實地實驗的證據”，2024年9月5日，/10.2139/ssrn.4945566。17Chen等人，“評估在代碼上訓練的大型語言模型。18在進行本研究時，GithubCopilot由OpenAI的Codex提供支持，這是一個基于GPT-3的代碼生成模型截至2023年11月30日，GithubCopilot目前由GPT-4提供支持19HammondPearce，BaleeghAhmad，BenjaminTan等人，“在鍵盤上跳舞？AssessingtheSecurityofGitHubCopilot'sCodeContributions，”arXivpreprintarXiv：2108.09293（2021），/abs/2108.09293.20穆罕默德·西迪克和喬安娜·C.S.Santos，“SecurityEvalDataset：挖掘漏洞示例以評估基于機器學習的代碼生成技術”，MSR4P&S2022：第一屆隱私和安全挖掘軟件存儲庫應用國際研討會論文集（2022年11月）：29-33，/10.1145/3549035.3561184。21Rapha?lKhoury，AndersonR.阿維拉，雅各布·布魯內爾等人，“ChatGPT生成的代碼有多安全arXiv預印本arXiv：2304.09655（2023），/abs/2304.09655。22付玉佳，彭亮，阿姆吉德·塔希爾等，“SecurityWeaknessesofCopilotGeneratedCodeinGithub，”arXivpreprintarXiv：2310.02059v2（2024），/abs/2310.02059v2.23HayleyDenbraver，“MaliciousPackagesFoundtoBeTypo-SquattinginPythonPackageIndex，”SnykBlog，2019年12月5日，https://snyk.io/blog/malicious-packages-found-to-be-typo-squatting-in-pypi/.24BarLanyado，“CanYouTrustChatGPT'sPackageRecommendations？"Vulcan.io博客，2023年6月6日，https://vulcan.io/blog/ai-hallucinations-package-risk。25ThomasClaburn，“AIHallucinatesSoftwarePackagesandDevsDownloadThem-EvenifPotentiallyPoisonedwithMalware，”TheRegister，March28，2024，/2024/03/28/ai_bots_hallucinate_software_packages.26Snyk，“AICode，Security，andTrustinModernDevelopment.”27NeilPerry，MeghaSrivastava，DeepakKumar，andDanBoneh，“DoUsersWriteMoreInsecureCodewithAIAssistants？"，arXiv預印本arXiv：2211.03622（2023），http：///abs/2211.03622。28GustavoSandoval，HammondPearce，TeoNys等人，“LostatC：AUserStudyontheSecurityImplicationsofLargeLanguageModelCodeAssistants，”arXivpreprintarXiv：2208.09727（2023/abs/2208.09727;OwuraAsare，MeiyappanNagappan，andN.Asokan，“在引入代碼漏洞方面，GitHub的Copilot和人類一樣糟糕嗎？?,arXiv預印本arXiv：2204.04741（2024），/abs/2204.04741。29MohammedAlzhefSiddiq，ShafayatH.邁沙？馬朱姆德米姆等人，“基于transformer的代碼生成技術中代碼氣味的實證研究”，2022年IEEE第22屆源代碼分析和操縱國際工作會議（SCAM2022年10月71-82，/10.1109/SCAM55253.2022.00014。30ManishBhatt，SahanaChennabasappa，CyrusNikolaja等人，“PurpleLlamaCyberSecEval：ASecureCodingBenchmarkforLanguageModels，”arXivpreprintarXiv：2312.04724（2023），/abs/2312.04724.31RanElgedawy，JohnSadik，SenjutiDutta等人，“偶爾安全：代碼生成助手的比較分析”，arXiv預印本arXiv：2402.00689（2024），/abs/2402.00689。32Elgedawy等人，“OccasionallySecure.”33ArijitGhoshChowdhury，MdMofijulIslam，VaibhavKumar等人，“BreakingDowntheDefenses：AComparativeSurveyofAttacksonLargeLanguageModels，”arXivpreprintarXiv：2403.04786（2024），/abs/2403.04786.34EvanHubinger，CarsonDenison，JesseMu等人，“SleeperAgents：TrainingDeceptiveLLMthatPersistsThroughSafetyTraining，”arXivpreprintarXiv：2401.05566（2024），https：/abs/2401.05566.安全與新興技術中心|38[35]DomenicoCotroneo，CristinaImprota，PietroLiguori，andRobertoNatella，“VulnerabilitiesinAICodeGenerators：ExploringTargetedDataPoisoningAttacks，”arXivpreprintarXiv：2308.04451（2024/abs/2308.04451.36KaiGreshake，SaharAbdelnabi，ShaileshMishra等人，“NotWhatYou'veSignedUpFor：CompromisingReal-WorldLLM-IntegratedApplicationswithIndirectPromptInjection，”arXivpreprintarXiv：2302.12173（2023/abs/2302.12173.37ScottWu，“IntroducingDevin，theFirstAISoftwareEngineer”，Cognition.aiBlog，2024年3月12日，/introducing-devin。38IliaShumailov，ZakharShumaylov，YirenZhao，YarinGal，NicolasPapernot，andRossAnderson，“TheCurseofRecursion：TrainingonGeneratedDataMakesModelsForget，”arXivpreprintarXiv：2305.17493v3（2024），/abs/2305.17493v3;SinaAlemohammad，JosueCasco-Rodriguez，LorenzoLuzietal.“Self-ConsumingGenerativeModelsGoMAD，”arXivpreprintarXiv：2307.01850（2023），/abs/2307.01850.[39]BrodyFord，“IBM將重新招聘人工智能可以做的工作”，彭博新聞社，2023年5月1日，/news/articles/2023-05-01/ibm-to-pause-hiring-for-back-office-jobs-that-。40Bhatt等人，“紫色美洲駝網絡機密評估”41ESBMC，系統(tǒng)和軟件驗證實驗室，2024，/。42Bhatt等人，“紫色美洲駝網絡機密評估”43HosseinHajipour，KenoHassler，ThorstenHolz等人，“CodeLMSec基準：系統(tǒng)地評估和發(fā)現(xiàn)黑盒代碼語言模型中的安全漏洞”，arXiv預印本arXiv：2302.04012（2023），/abs/2302.04012。44AoboKong，ShiwanZhao，HaoChen等，“BetterZero-ShotReasoningwithRole-PlayPresting，”arXivpreprintarXiv：2308.07702（2023/abs/2308.07702.45Perry等人，“用戶使用AI助手會編寫更多不安全的代碼嗎？?46Pearce等人，“在鍵盤上跳舞？評估GitHubCopilot代碼貢獻的安全性。47CatherineTony，MarkusMutas，NicolásE.DíazFerreyra和RiccardoScandariato，“LLMSecEval：用于安全評估的自然語言數據集”，arXiv預印本arXiv：2303.09384（2023），/abs/2303.09384。安全與新興技術中心|3948“CWETop25MostDangerousSoftwareWeaknesses，”MITRE，November30，2023，/top25/.49Tony等人，“LLMSecEval：用于安全評估的自然語言數據集。50這個項目的公共GitHub存儲庫可以在/georgetown-cset/code-generation-2.0找到。51Tony等人，“LLMSecEval：用于安全評估的自然語言數據集。52NorbertTihanyi，TamasBisztray，RidhiJain等人，“FormAI數據集：通過形式驗證的鏡頭在軟件安全中的生成AI，”arXiv預印本arXiv：2307.02192（2023），/abs/2307.02192。53Khoury等人，“ChatGPT生成的代碼有多安全Fu等人，“SecurityWeaknessesofCopilotGeneratedCodeinGithub”;Bhattetal.，“紫色美洲駝網絡機密評估”54Elgedaway等人，“OccurnallySecure”;Siddiq和Santos，“SecurityEvalDataset：MiningVulnerabilityExamplest