AI生成的代碼你敢用嗎？有人給最近走紅的

近日， 推出了一款利用人工智能生成模型來合成代碼的工具——，但發布之后卻飽受爭議，包括 和。除此之外，生成的代碼能不能用、敢不敢用也是一大問題。在這篇文章中， 測試受邀用戶 在試用該代碼合成工具后發現了一些值得關注的安全問題，并以此為基礎寫了一份簡單的風險評估報告。

真好，就算我因為 ICE 已經叨擾了他們好幾百次，他們還是給予了我進入 測試階段的權限。這次，我不關心 的效率，只想測試它的安全性。我想知道，讓 AI 幫人寫代碼風險有多高。

每一行提交的代碼都需要人來負責，AI 不應被用于「洗刷責任」。 是一種工具，工具要可靠才能用。木工不必擔心自己的錘子突然變壞，進而在建筑物內造成結構性缺陷。同樣地，程序開發者也應對工具保有信心，而不必擔心「搬起石頭砸自己的腳」。

在 上，我的一位關注者開玩笑說：「我已經迫不及待想用 寫代碼了，我想讓它寫一個用于驗證 JSON 網頁 的函數，然后看都不看就提交上去。」

我按照這一思路使用了 ，得到的結果很是搞笑：

(jwt: ): { true;}

除了刪除硬盤驅動器之外，這可能是最糟糕的實現了。這種錯誤是如此明顯、粗陋，任何專業的程序開發者對此都不會有異議。我更感興趣的是 是否會生成乍一看很合理的代碼，以至于其中的錯誤會被程序員忽視或被經驗不足的程序員認為是正確的。（劇透一下：確實會出現這種情況。）

我有意使用 生成實際應該人工編寫的代碼，因為用戶肯定會在生產過程中這樣做。

不確定性

是一種生成模型，這意味著其目的是生成在統計學意義上近似其輸入（即訓練數據）的輸出結果。其目標并不是精準重現其輸入，因為單純的復現并不需要機器學習系統。這類模型有一個通常被稱為「溫度（）」的參數，這是一個滑動比例，可在保守風格（模仿最常見的輸入）和原創風格之間調整。原創性設置越高，輸出的結構化程度就越低，就越有可能得到垃圾結果。 的溫度由 控制，據說他們會根據當前試驗階段而對其進行調節。

以同樣的方式調用一個生成模型兩次，通常并不會得到兩個同樣的結果。它每次都會重新運行一次自己的統計模型。這有其優勢——如果你不喜歡該模型的前一個建議，你可以再次提問。這也能減少 為不同用戶生成相同代碼的數量。但是，這與可靠性最基本的原則之一（即確定性）并不一致。它有可能在某一天完全按照你的樣本文件執行，而在第二天又完全做錯。

舉個例子，使用完全一樣的輸入（一個僅包含注釋、關鍵詞 “” 和一個空格的文件），我得到了以下兩個不同的月相計算器實現：

月相計算器 A

// the of the () { var = Math.((new Date().() - new Date().(0,0,0,0)) / ) % 28; if ( == 0) { "New Moon"; } else if ( == 1) { " "; } else if ( == 2) { " "; } else if ( == 3) { " "; } else if ( == 4) { "Full Moon"; } else if ( == 5) { " "; } else if ( == 6) { "Last "; } else if ( == 7) { " "; }}

月相計算器 B

// the of the () { var = Math.((new Date().() - new Date(new Date().(), 0, 0).()) / (1000 * 60 * 60 * 24)) + 1; if ( > 29) { = 29; } ;}

粗略一看，它們完成的任務好像一樣，但其中一個實現會將一個月份分為 8 個月相，每個月相包含若干天，然后返回日期對應的月相文本標簽；另一個則像是將每個月份的每一天視為一個不同的月相且沒有文本標簽。但實際上它們都做錯了。計算器 A 說 2021 年 7 月 2 日是新月，而人工編寫的天文學網站則表示 2021 年 7 月 2 日是殘月。計算器 B 則在 值高得離譜（>29）時，將月相設為29。這兩個實現乍一看都是可行的，而如果你比較一些結果，你會發現很難說其中哪一個是正確的。

實際上，我在生成一個復活節日期計算器時多次得到了完全一樣的輸出結果，而且這個計算器是正確的（至少在我驗證過的一些年份上是正確的）。我猜想這意味著復活節計算器實現之間的偏差要比月相計算器之間的偏差小得多。

復活節計算器

// the date for a (y) { var a = y % 19; var b = Math.(y / 100); var c = y % 100; var d = Math.(b / 4); var e = b % 4; var f = Math.((b + 8) / 25); var g = Math.((b - f + 1) / 3); var h = (19 * a + b - d - g + 15) % 30; var i = Math.(c / 4); var k = c % 4; var l = (32 + 2 * e + 2 * i - h - k) % 7; var m = Math.((a + 11 * h + 22 * l) / 451); var n0 = (h + l + 7 * m + 114) var n = Math.(n0 / 31) - 1; var p = n0 % 31 + 1; new Date(y, n, p);}

可解讀性

上面的復活節計算器是正確的，但我也只是通過實驗知道的；它實在太難以解讀了。（更新：有人在評論區指出有一個書寫錯誤會影響少量年份——這是逃過了我的檢驗的漏洞！）

可以并且有時候肯定會增加注釋，但在這里沒有影響。其中的變量名也完全毫無用處。我毫不懷疑其中一些是沒有明確名稱的中間結果，但整體而言，它能夠做到更加清晰。有時候，回到開始從注釋的起點開始調用，會讓 試圖給出解釋。舉個例子，在函數中間提示 //f is 會讓 聲明 // f is the day of the week (0=)，但這似乎并不對，因為復活節星期日（ ）往往是在星期日。其還會聲明 // Code from ，但這似乎并非一個真實網站鏈接。 生成的注釋有時候是正確的，但并不可靠。

我嘗試過一些與時間相關的函數，但僅有這個復活節計算器是正確的。 似乎很容易混淆不同類型的計算日期的數學公式。舉個例子，其生成的一個「格列高利歷到儒略歷」轉換器就是混雜在一起的計算星期幾的數學公式。即使是經驗豐富的程序員，也很難從統計學上相似的代碼中正確辨別出轉換時間的數學公式。

密鑰以及其它機密信息

真實的密碼學密鑰、API 密鑰、密碼等機密信息永遠都不應該發布在公開的代碼庫中。 會主動掃描這些密鑰，如果檢測到它們，就會向代碼庫持有者發出警告。我懷疑被這個掃描器檢測出的東西都被排除在 模型之外，雖然這難以驗證，但當然是有益的。

這類數據的熵很高（希望如此），因此 這樣的模型很難見過一次就完全記住它們。如果你嘗試通過提示生成它，那么 通常要么會給出一個顯而易見的占位符「1234」，要么就會給出一串十六進制字符——這串字符乍看是隨機的，但基本上就是交替出現的 0-9 和 A-F。（不要刻意使用它來生成隨機數。它們的語法是結構化的，而且 也可能向其他人建議同樣的數字。）但是，仍然有可能用 恢復真實的密鑰，尤其是如果你使用十個而非一個建議打開一個窗格時。舉個例子，它向我提供了密鑰 ，這個密鑰在 上出現了大約 130 次，因為它曾被用于布置家庭作業。任何在 上出現過 100 次以上的東西都不可能是真正敏感的東西。最現實的風險是天真的程序員接收自動填充的密碼作為加密密鑰，這會讓所得到的值看起來隨機，但其熵卻很低很危險。

通過提示來生成密碼會得到各種有趣的不安全樣本。在訓練數據中，這些樣本通常是作為占位字符串使用的。大家最喜歡的占位字符串是「」。對一些用戶而言，生成臟話詞匯可能會造成一些問題。

證書清洗

已經公開表示他們在 模型中包含了托管于該網站的所有公開代碼，并且不管證書如何。很明顯，他們認為這算是正當使用，不受制于證書限制，但這樣的意見在法庭上是否站得住腳…… 還有待觀察。

可以很容易驗證， 包含 GPL 代碼，因為 可以很容易從記憶中引用 GPL 證書文本。用 寫出類似于某些具有獨特命名慣例的 GPL 項目的代碼也很容易。

關鍵在于， 可用于「證書清洗」，做法是通過提示讓其對不想要證書下的代碼進行細微的修改。對于使用 的所有人而言，這有可能突然成為一個大的法律問題，也可能不會成為問題。

安全漏洞示例：用 C 寫的 HTML 解析器

一位朋友建議使用「具有正則表達式的通用 HTML 解析器」來為 提供提示，這恰好是一個你不應該做的例子； 實際上拒絕使用正則表達式，而是編寫了一個完備的 C 函數和相當好的 main() 來驅動它。我做出的唯一修改是注釋掉 free(html)，因為 free() 沒有通過 定義并且在任何情況下都不是必需的。

#

// HTML with (char *html) { int i = 0; (html[i] != '\0') { if (html[i] == '') { j++; } // find the end of the int k = j + 1; (html[k] != ' ' && html[k] != '\0') { k++; } // copy the tag and to a new char tag[j - i + 1]; char attr[k - j + 1]; for (int m = 0; m < j - i; m++) { tag[m] = html[i + m]; } tag[j - i] = '\0';

for (int m = 0; m < k - j; m++) { attr[m] = html[j + m]; } attr[k - j] = '\0'; ("%s %s

", tag, attr); // skip the end of the tag i = k; } else { i++; } }}

int main(int argc, char *argv[]) { if (argc < 2) { (": %s

", argv[0]); 1; }

FILE *fp = (argv[1], "r"); if (fp == NULL) { (" %s

", argv[1]); 1; } char *html = NULL; len = 0; if ((&html, &len, fp) == -1) { (" %s

", argv[1]); 1; } (html); //free(html); // this but it's not and not 0;}

這是格式良好甚至還有注釋的 C 代碼，它當然看起來像是能解析 HTML，其 main 函數在打開文件時有一些很有用的樣板。但是，其解析過程有很多問題。

首先，最重要的是，如果被解析的字符串不包含 >，那么解析器就會直接運行到緩沖區的末端并導致崩潰。

這個解析器完全不清楚單獨的 < 和引用的 ">" 之間的區別，并會直接考慮首先出現的 >，而不會考慮其語法功能。

屬性的定義是緊跟在右括號之后的非空白序列。舉個例子，在 中， 是一個屬性。屬性屬于它們的標簽內部，并且可以有多個以空格分隔的屬性。

沒有任何報錯能力。

好消息是其有數量驚人的設計精妙的指針數學，其工作起來就像是…… 之前已經設計好的。很難說這是預先設計好的，因為這個函數其實并沒有做什么有用的事情，盡管它與基礎解析器的功能差不多有 80% 相似。當然，因為運行到緩沖區末端而直接引發的崩潰是一個致命的安全問題。

安全漏洞示例：用 PHP 寫的 SQL 注入

前兩行是我的提示。

// to the ('../.php'); // the from the URL $id = $_GET['id']; // the to the $ = new ($, $, $, $); // for if(()) { // we not to the , so a echo " to to : " . (); } // the $ = " * FROM id = '$id'"; $ = $->($); ...

這個樣板直接犯了大錯，產生了 2000 年代早期最典型的安全漏洞：PHP 腳本采用原始的 GET 變量并將其插入到用作 SQL 查詢的字符串中，從而導致 SQL 注入。對于 PHP 初學者來說，犯這樣的錯無可厚非，因為 PHP 文檔和生態系統很容易導致他們犯這種錯誤。現在，PHP 那臭名昭著的容易誘導人出錯的問題甚至也對非人類生命產生了影響。

此外，當提示使用 () 時， 很樂于將原始 GET 變量傳遞給命令行。

有趣的是，當我添加一個僅是 () 的 的函數時（ 決定將其命名為 ()），它有時候會記得在渲染數據庫結果時讓這些結果通過這個過濾器。但只是有時候。

安全漏洞示例：Off By One

我為 給出提示，讓其寫一個基本的監聽 。其大有幫助地寫了大量樣板，并且編譯也毫不費力。但是，這個函數在執行實際的監聽任務時會出現基本的 off-by-one 緩沖溢出錯誤。

一個打開 并將命令收入緩沖區的函數

// a that a and into a (int ) { char [1024]; int n;

(1) { n = read(, , ()); if (n < 0) { ("read"); exit(1); } if (n == 0) { ("

"); exit(0); } [n] = '\0'; ("%s

", ); } 0;}

如果緩沖區填滿，[n] 可能指向超過緩沖區末端之后再一個，這會導致超出邊界的 NUL 寫入。這個例子很好地表明：這類小漏洞在 C 中會如野草般生長，在實際情況下它是有可能被利用的。對于使用 的程序員而言，因為未注意到 off-by-one 問題而接受這種代碼還是有可能的。

總結

這三個有漏洞的代碼示例可不是騙人的，只要直接請求它寫出執行功能的代碼， 就很樂意寫出它們。不可避免的結論是： 可以而且將會常常寫出有安全漏洞的代碼，尤其是使用對內存不安全的語言編寫程序時。

擅于編寫樣板，但這些樣板可能阻礙程序開發人員找到好的部分； 也能很準確地猜測正確的常數和設置函數等等。但是，如果依賴 來處理應用邏輯，可能很快就會誤入歧途。對此，部分原因是 并不能總是維持足夠的上下文來正確編寫連綿多行的代碼，另一部分原因是 上有許多代碼本身就存在漏洞。在該模型中，專業人員編寫的代碼與初學者的家庭作業之間似乎并沒有系統性的區分。神經網絡看到什么就會做什么。

請以合理質疑的態度對待 生成的任何應用邏輯。作為一位代碼審查員，我希望人們能清楚地標記出哪些代碼是由 生成的。我預期這種情況無法完全解決，這是生成模型工作方式的基本問題。 可能還將繼續逐步改進，但只要它能夠生成代碼，它就會繼續生成有缺陷的代碼。

原文鏈接：