來源：arXiv

編輯：LRS

【新智元導讀】garbage in, garbage out耳熟能詳，如果你寫的開源代碼被輸入到了代碼生成工具Copilot中，會不會影響它的生成性能呢？紐約大學的研究員最近發現，Copilot生成的代碼有超過40%都含有高危漏洞，究其原因竟然是GitHub提供的源代碼自帶漏洞！

隨著AI技術的不斷進步，程序員們好像不止想取代傳統行業的人，而且還在積極思考如何取代自己，AI研究員們對「代碼自動生成」更情有獨鐘。

結對編程（Pair programming）是一種敏捷軟件開發的方法，兩個程序員在一個計算機上共同工作。一個人輸入代碼，而另一個人審查他輸入的每一行代碼。

輸入代碼的人稱作駕駛員，審查代碼的人稱作觀察員（或導航員），兩個程序員經常互換角色。

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

如果觀察員是一個AI，想象有一個AI助手和你一起結對編程是一種什么感覺？

今年六月，OpenAI 就和 GitHub 聯手發布了一個新工具 GitHub Copilot，一時風頭無兩，只要寫下注釋，后面的代碼內容基本都能預測正確，尤其對于寫utils之類的函數來說實在是太方便。

但后來GitHub Copilot又卷入各種倫理風波中，有人認為他這是背誦代碼，也有人認為可能會讓使用者無意中抄襲了其他程序員的勞動成果，最關鍵的是，GitHub Copilot收費，網友認為你既然用的開源代碼訓練的模型，怎么能收費呢？

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

對此，來自紐約大學的研究員們最近發表了一篇論文，系統地對Copilot進行實驗，通過為Copilot設計要完成的場景，并通過分析生成的代碼的安全弱點來深入了解這些問題。

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

garbage in, garbage out？

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

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

除了由人工進行手動評估外，還可以用其他工具和技術可以對軟件進行安全分析，例如源代碼分析工具、靜態應用程序安全測試（Static Application Security Testing, SAST）工具，都能夠發現代碼的安全缺陷，并且可以用于識別特定類型的漏洞。

使用Copilot時，當用戶向程序添加一行代碼后，Copilot會連續掃描程序，并定期上傳一些代碼、光標的位置和代碼的元數據，然后再根據這些特征生成一些候選代碼選項供用戶插入。

Copilot能夠生成與程序功能相關的代碼，例如注釋、docstring、函數名等，Copilot還能夠為每個候選代碼的置信度進行評分。

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

CWE（Common Weakness Enumeration，通用缺陷枚舉）成立于2006年，是由美國國土安全部國家計算機安全部門資助的軟件安全戰略性項目，是常見的源代碼漏洞詞典庫和通用標準。

使用Github CodeQL來分析靜態代碼。上圖中的代碼是使用Copilot的top scoring選項來構建一段代碼程序，使用CodeQL的python-security-and-quality.qls測試套件中檢查153個安全屬性，可以發現報告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內置的查詢對每個程序進行評估，對于一些需要額外代碼上下文或無法形成CodeQL可檢查屬性的CWE，需要由人工手動執行5c。在這一步中，CodeQL被配置為只檢查特定CWE，并且不評估正確性，只評估漏洞。

第6步中輸出評估結果。

論文中對25個CWE漏洞都有詳細的實驗描述，感興趣的小伙伴可以戳原文。

40.48%都是BUG

實驗結果總的來說不太理想。

從安全的角度來看，Copilot生成的代碼中有大量的漏洞，大概比例為40.48%。由于Copilot的訓練數據來自GitHub上可用的開源代碼的訓練，所以一定程度上認為這個安全質量評價也同樣適用于GitHub中的代碼。

也就是說，當某些bug在開源存儲庫中經常出現時，這些bug也更容易被Copilot生成出來。話雖如此，但也不應該對GitHub上存儲的開源存儲庫的安全質量輕易下結論。

開源軟件的另一個需要考慮安全質量的方面是時間的影響。隨著網絡安全形勢的發展，某些文章所說的最佳實踐（best practice）可能會慢慢變成反面教材，過時實踐可能會永久地存在于訓練數據中，并導致生成的代碼也是不可靠的。

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

未維護和遺留代碼也使用不安全的散列方式，Copilot從這些代碼中學習，所以也會對程序員繼續建議使用這些散列方法。

最后研究人員還是贊揚了Copilot，這樣的次時代AutoComplete工具將提高軟件開發人員的生產率，但使用Copilot作為結對編程的副駕駛時，開發人員應該保持警惕。

在理想情況下，在訓練和生成過程中，Copilot應該與安全工具相配合，將引入安全漏洞的風險降至最低。

參考資料：

arxiv.org/pdf/2108.09293v2.pdf