來源：arXiv
編輯：LRS
【新智元導讀】garbage in, garbage out耳熟能詳，如果你寫的開源代碼被輸入到了代碼生成工具Copilot中，會不會影響它的生成性能呢？紐約大學的研究員最近發(fā)現(xiàn)，Copilot生成的代碼有超過40%都含有高危漏洞，究其原因竟然是GitHub提供的源代碼自帶漏洞！
隨著AI技術的不斷進步，程序員們好像不止想取代傳統(tǒng)行業(yè)的人，而且還在積極思考如何取代自己，AI研究員們對「代碼自動生成」更情有獨鐘。
結對編程（Pair programming）是一種敏捷軟件開發(fā)的方法，兩個程序員在一個計算機上共同工作。一個人輸入代碼，而另一個人審查他輸入的每一行代碼。
輸入代碼的人稱作駕駛員，審查代碼的人稱作觀察員（或導航員），兩個程序員經(jīng)常互換角色。
審查代碼的人有時候也扮演「小黃鴨」，作用是聽著駕駛員耐心地向自己解釋每一行程序的作用，不用說話就可以激發(fā)駕駛員的靈感，還有助于發(fā)現(xiàn)bug。
如果觀察員是一個AI，想象有一個AI助手和你一起結對編程是一種什么感覺？
今年六月，OpenAI 就和 GitHub 聯(lián)手發(fā)布了一個新工具 GitHub Copilot，一時風頭無兩，只要寫下注釋，后面的代碼內(nèi)容基本都能預測正確，尤其對于寫utils之類的函數(shù)來說實在是太方便。
但后來GitHub Copilot又卷入各種倫理風波中，有人認為他這是背誦代碼，也有人認為可能會讓使用者無意中抄襲了其他程序員的勞動成果，最關鍵的是，GitHub Copilot收費，網(wǎng)友認為你既然用的開源代碼訓練的模型，怎么能收費呢？
除了上述問題不談，Copilot的安全性又怎么樣？能不能生產(chǎn)出讓人民放心、讓百姓安心的好代碼？
對此，來自紐約大學的研究員們最近發(fā)表了一篇論文，系統(tǒng)地對Copilot進行實驗，通過為Copilot設計要完成的場景，并通過分析生成的代碼的安全弱點來深入了解這些問題。
論文地址：arxiv.org/pdf/2108.09293v2.pdf
garbage in, garbage out？
代碼的質量由許多因素決定，但代碼生成(code generation)更強調(diào)功能的正確性，這點通過能否正常編譯和單元測試來衡量質量，或者使用文本相似性度量來衡量與預期的代碼之間的差距。
與生成代碼的功能正確性度量不同，評估Copilot提供的代碼的安全性是一個開放的問題，并沒有特定的解決方法。
除了由人工進行手動評估外，還可以用其他工具和技術可以對軟件進行安全分析，例如源代碼分析工具、靜態(tài)應用程序安全測試（Static Application Security Testing, SAST）工具，都能夠發(fā)現(xiàn)代碼的安全缺陷，并且可以用于識別特定類型的漏洞。
使用Copilot時，當用戶向程序添加一行代碼后，Copilot會連續(xù)掃描程序，并定期上傳一些代碼、光標的位置和代碼的元數(shù)據(jù)，然后再根據(jù)這些特征生成一些候選代碼選項供用戶插入。
Copilot能夠生成與程序功能相關的代碼，例如注釋、docstring、函數(shù)名等，Copilot還能夠為每個候選代碼的置信度進行評分。
了解如何使用Copilot后，需要定義問題：如果一段代碼包含了CWE中展示的特點，那么這段代碼就是有漏洞的（vulnerable）。
CWE（Common Weakness Enumeration，通用缺陷枚舉）成立于2006年，是由美國國土安全部國家計算機安全部門資助的軟件安全戰(zhàn)略性項目，是常見的源代碼漏洞詞典庫和通用標準。
使用Github CodeQL來分析靜態(tài)代碼。上圖中的代碼是使用Copilot的top scoring選項來構建一段代碼程序，使用CodeQL的python-security-and-quality.qls測試套件中檢查153個安全屬性，可以發(fā)現(xiàn)報告SQL查詢生成方法有漏洞（第14-16行），可能允許用戶插入惡意SQL代碼，在CWE的術語中是CWE-89（SQL注入）。
隨后研究人員通過引導Copilot生成2021 CWE Top 25 相關的漏洞進行實驗。首先對每個CWE漏洞，寫下多個相關的代碼提示（CWE scenarios），然后把這些這些不完整的代碼片段輸入到Copilot中生成代碼。
為了簡化實驗過程，主要對Python, C和Verilog這三種語言進行試驗。CodeQL能夠很完善地Python和C的代碼檢測，選擇Verilog的原因是測試Copilot對于非明星語言的代碼生成能力。
每個代碼片段，Copilot都要生成25個補全代碼，然后，將每個候選代碼與原始程序片段組合成為完整的代碼，如果某些選項存在重大語法問題，即無法編譯/解析，則會丟棄4b中的某些候選代碼。如果簡單的編輯操作（例如添加或刪除單個大括號）就能夠可編譯的輸出結果，那就可以基于正則表達式的工具自動進行這些更改。
在5a步，使用CodeQL內(nèi)置的查詢對每個程序進行評估，對于一些需要額外代碼上下文或無法形成CodeQL可檢查屬性的CWE，需要由人工手動執(zhí)行5c。在這一步中，CodeQL被配置為只檢查特定CWE，并且不評估正確性，只評估漏洞。
第6步中輸出評估結果。
論文中對25個CWE漏洞都有詳細的實驗描述，感興趣的小伙伴可以戳原文。
40.48%都是BUG
實驗結果總的來說不太理想。
從安全的角度來看，Copilot生成的代碼中有大量的漏洞，大概比例為40.48%。由于Copilot的訓練數(shù)據(jù)來自GitHub上可用的開源代碼的訓練，所以一定程度上認為這個安全質量評價也同樣適用于GitHub中的代碼。
也就是說，當某些bug在開源存儲庫中經(jīng)常出現(xiàn)時，這些bug也更容易被Copilot生成出來。話雖如此，但也不應該對GitHub上存儲的開源存儲庫的安全質量輕易下結論。
開源軟件的另一個需要考慮安全質量的方面是時間的影響。隨著網(wǎng)絡安全形勢的發(fā)展，某些文章所說的最佳實踐（best practice）可能會慢慢變成反面教材，過時實踐可能會永久地存在于訓練數(shù)據(jù)中，并導致生成的代碼也是不可靠的。
一個明顯的例子是密碼散列的DOW CWE-522方案，不久前MD5被認為是安全的，SHA-256被認為是安全的，但現(xiàn)在的最佳實踐仍然要么涉及多輪簡單的散列函數(shù)，要么使用像bcrypt一樣上了年紀的加密庫（優(yōu)雅，但也老了）。
未維護和遺留代碼也使用不安全的散列方式，Copilot從這些代碼中學習，所以也會對程序員繼續(xù)建議使用這些散列方法。
最后研究人員還是贊揚了Copilot，這樣的次時代AutoComplete工具將提高軟件開發(fā)人員的生產(chǎn)率，但使用Copilot作為結對編程的副駕駛時，開發(fā)人員應該保持警惕。
在理想情況下，在訓練和生成過程中，Copilot應該與安全工具相配合，將引入安全漏洞的風險降至最低。
參考資料：
arxiv.org/pdf/2108.09293v2.pdf
