garbage in, garbage out耳熟能詳，如果你寫的開源代碼被輸入到了代碼生成工具Copilot中，會(huì)不會(huì)影響它的生成性能呢？紐約大學(xué)的研究員最近發(fā)現(xiàn)，Copilot生成的代碼有超過40%都含有高危漏洞，究其原因竟然是GitHub提供的源代碼自帶漏洞！

隨著AI技術(shù)的不斷進(jìn)步，程序員們好像不止想取代傳統(tǒng)行業(yè)的人，而且還在積極思考如何取代自己，AI研究員們對(duì)「代碼自動(dòng)生成」更情有獨(dú)鐘。

結(jié)對(duì)編程（Pair programming）是一種敏捷軟件開發(fā)的方法，兩個(gè)程序員在一個(gè)計(jì)算機(jī)上共同工作。一個(gè)人輸入代碼，而另一個(gè)人審查他輸入的每一行代碼。

輸入代碼的人稱作駕駛員，審查代碼的人稱作觀察員（或?qū)Ш絾T），兩個(gè)程序員經(jīng)?；Q角色。

審查代碼的人有時(shí)候也扮演「小黃鴨」，作用是聽著駕駛員耐心地向自己解釋每一行程序的作用，不用說話就可以激發(fā)駕駛員的靈感，還有助于發(fā)現(xiàn)bug。

如果觀察員是一個(gè)AI，想象有一個(gè)AI助手和你一起結(jié)對(duì)編程是一種什么感覺？

今年六月，OpenAI 就和 GitHub 聯(lián)手發(fā)布了一個(gè)新工具 GitHub Copilot，一時(shí)風(fēng)頭無兩，只要寫下注釋，后面的代碼內(nèi)容基本都能預(yù)測(cè)正確，尤其對(duì)于寫utils之類的函數(shù)來說實(shí)在是太方便。

但后來GitHub Copilot又卷入各種倫理風(fēng)波中，有人認(rèn)為他這是背誦代碼，也有人認(rèn)為可能會(huì)讓使用者無意中抄襲了其他程序員的勞動(dòng)成果，最關(guān)鍵的是，GitHub Copilot收費(fèi)，網(wǎng)友認(rèn)為你既然用的開源代碼訓(xùn)練的模型，怎么能收費(fèi)呢？

除了上述問題不談，Copilot的安全性又怎么樣？能不能生產(chǎn)出讓人民放心、讓百姓安心的好代碼？

對(duì)此，來自紐約大學(xué)的研究員們最近發(fā)表了一篇論文，系統(tǒng)地對(duì)Copilot進(jìn)行實(shí)驗(yàn)，通過為Copilot設(shè)計(jì)要完成的場景，并通過分析生成的代碼的安全弱點(diǎn)來深入了解這些問題。

論文地址：
https://arxiv.org/pdf/2108.09293v2.pdf

garbage in, garbage out？

代碼的質(zhì)量由許多因素決定，但代碼生成(code generation)更強(qiáng)調(diào)功能的正確性，這點(diǎn)通過能否正常編譯和單元測(cè)試來衡量質(zhì)量，或者使用文本相似性度量來衡量與預(yù)期的代碼之間的差距。

與生成代碼的功能正確性度量不同，評(píng)估Copilot提供的代碼的安全性是一個(gè)開放的問題，并沒有特定的解決方法。

除了由人工進(jìn)行手動(dòng)評(píng)估外，還可以用其他工具和技術(shù)可以對(duì)軟件進(jìn)行安全分析，例如源代碼分析工具、靜態(tài)應(yīng)用程序安全測(cè)試（Static Application Security Testing, SAST）工具，都能夠發(fā)現(xiàn)代碼的安全缺陷，并且可以用于識(shí)別特定類型的漏洞。

使用Copilot時(shí)，當(dāng)用戶向程序添加一行代碼后，Copilot會(huì)連續(xù)掃描程序，并定期上傳一些代碼、光標(biāo)的位置和代碼的元數(shù)據(jù)，然后再根據(jù)這些特征生成一些候選代碼選項(xiàng)供用戶插入。

Copilot能夠生成與程序功能相關(guān)的代碼，例如注釋、docstring、函數(shù)名等，Copilot還能夠?yàn)槊總€(gè)候選代碼的置信度進(jìn)行評(píng)分。

了解如何使用Copilot后，需要定義問題：如果一段代碼包含了CWE中展示的特點(diǎn)，那么這段代碼就是有漏洞的（vulnerable）。

CWE（Common Weakness Enumeration，通用缺陷枚舉）成立于2006年，是由美國國土安全部國家計(jì)算機(jī)安全部門資助的軟件安全戰(zhàn)略性項(xiàng)目，是常見的源代碼漏洞詞典庫和通用標(biāo)準(zhǔn)。

使用Github CodeQL來分析靜態(tài)代碼。上圖中的代碼是使用Copilot的top scoring選項(xiàng)來構(gòu)建一段代碼程序，使用CodeQL的
python-security-and-quality.qls測(cè)試套件中檢查153個(gè)安全屬性，可以發(fā)現(xiàn)報(bào)告SQL查詢生成方法有漏洞（第14-16行），可能允許用戶插入惡意SQL代碼，在CWE的術(shù)語中是CWE-89（SQL注入）。

隨后研究人員通過引導(dǎo)Copilot生成2021 CWE Top 25 相關(guān)的漏洞進(jìn)行實(shí)驗(yàn)。首先對(duì)每個(gè)CWE漏洞，寫下多個(gè)相關(guān)的代碼提示（CWE scenarios），然后把這些這些不完整的代碼片段輸入到Copilot中生成代碼。

為了簡化實(shí)驗(yàn)過程，主要對(duì)Python, C和Verilog這三種語言進(jìn)行試驗(yàn)。CodeQL能夠很完善地Python和C的代碼檢測(cè)，選擇Verilog的原因是測(cè)試Copilot對(duì)于非明星語言的代碼生成能力。

每個(gè)代碼片段，Copilot都要生成25個(gè)補(bǔ)全代碼，然后，將每個(gè)候選代碼與原始程序片段組合成為完整的代碼，如果某些選項(xiàng)存在重大語法問題，即無法編譯/解析，則會(huì)丟棄4b中的某些候選代碼。如果簡單的編輯操作（例如添加或刪除單個(gè)大括號(hào)）就能夠可編譯的輸出結(jié)果，那就可以基于正則表達(dá)式的工具自動(dòng)進(jìn)行這些更改。

在5a步，使用CodeQL內(nèi)置的查詢對(duì)每個(gè)程序進(jìn)行評(píng)估，對(duì)于一些需要額外代碼上下文或無法形成CodeQL可檢查屬性的CWE，需要由人工手動(dòng)執(zhí)行5c。在這一步中，CodeQL被配置為只檢查特定CWE，并且不評(píng)估正確性，只評(píng)估漏洞。

第6步中輸出評(píng)估結(jié)果。

論文中對(duì)25個(gè)CWE漏洞都有詳細(xì)的實(shí)驗(yàn)描述，感興趣的小伙伴可以戳原文。

40.48%都是BUG

實(shí)驗(yàn)結(jié)果總的來說不太理想。

從安全的角度來看，Copilot生成的代碼中有大量的漏洞，大概比例為40.48%。由于Copilot的訓(xùn)練數(shù)據(jù)來自GitHub上可用的開源代碼的訓(xùn)練，所以一定程度上認(rèn)為這個(gè)安全質(zhì)量評(píng)價(jià)也同樣適用于GitHub中的代碼。

也就是說，當(dāng)某些bug在開源存儲(chǔ)庫中經(jīng)常出現(xiàn)時(shí)，這些bug也更容易被Copilot生成出來。話雖如此，但也不應(yīng)該對(duì)GitHub上存儲(chǔ)的開源存儲(chǔ)庫的安全質(zhì)量輕易下結(jié)論。

開源軟件的另一個(gè)需要考慮安全質(zhì)量的方面是時(shí)間的影響。隨著網(wǎng)絡(luò)安全形勢(shì)的發(fā)展，某些文章所說的最佳實(shí)踐（best practice）可能會(huì)慢慢變成反面教材，過時(shí)實(shí)踐可能會(huì)永久地存在于訓(xùn)練數(shù)據(jù)中，并導(dǎo)致生成的代碼也是不可靠的。

一個(gè)明顯的例子是密碼散列的DOW CWE-522方案，不久前MD5被認(rèn)為是安全的，SHA-256被認(rèn)為是安全的，但現(xiàn)在的最佳實(shí)踐仍然要么涉及多輪簡單的散列函數(shù)，要么使用像bcrypt一樣上了年紀(jì)的加密庫（優(yōu)雅，但也老了）。

未維護(hù)和遺留代碼也使用不安全的散列方式，Copilot從這些代碼中學(xué)習(xí)，所以也會(huì)對(duì)程序員繼續(xù)建議使用這些散列方法。

最后研究人員還是贊揚(yáng)了Copilot，這樣的次時(shí)代AutoComplete工具將提高軟件開發(fā)人員的生產(chǎn)率，但使用Copilot作為結(jié)對(duì)編程的副駕駛時(shí)，開發(fā)人員應(yīng)該保持警惕。

在理想情況下，在訓(xùn)練和生成過程中，Copilot應(yīng)該與安全工具相配合，將引入安全漏洞的風(fēng)險(xiǎn)降至最低。