類似Github Copilot這樣的人工智能代碼助手能大大提高開發人員的開發效率和生產力，并降低開發技術門檻（不熟悉語言或概念的程序員的進入）。然而，缺乏經驗的開發人員可能會輕易相信人工智能助手的輸出內容，從而引入安全漏洞風險。

近日，斯坦福大學的一項研究發現，使用人工智能助手編寫的代碼比“手工代碼”的安全性差很多，而且人工智能工具還會導致用戶對其代碼中的安全性過于自信。

調查還發現，人工智能助手輸出的代碼通常在滿足“正確性”的同時，很少了解密碼應具有的安全屬性，并且在某些情況下，可能會創建無意中使用戶感到困惑的代碼。

該調查設計了一個全面的用戶研究項目，共有47名參與者使用三種不同的編程語言（Python、JavaScript和C）執行了五項與安全相關的編程任務。三個核心研究問題如下：

• 當用戶使用人工智能編程助手時，是否會編寫更多不安全的代碼？
• 用戶相信人工智能助手能夠編寫安全的代碼嗎？
• 用戶與人工智能助手交互時的語言和行為如何影響其代碼中的安全漏洞程度？

多個國家的開發人員參與了該調查，其中大多數來自以下三個國家：

• 美國         57%
• 中國         15%
• 印度         13%

該調查的關鍵發現如下：

人工智能代碼在五項測試中的安全性表現普遍低于人工代碼

在所有五個類型的安全錯誤測試（下圖）中，人工智能助手所犯的編碼錯誤都超過手工編碼，與對照組相比，67%的使用AI助手的開發者提供了正確的解決方案，而“人工編碼”的對照組的這一比例為79%。這表明，依賴人工智能輔助開發可能會導致更多安全錯誤。

AI實驗組（藍色）和人工對照組（黃色）五項測試的代碼安全錯誤占比

例如，在SQL注入漏洞測試中，使用AI助手的參與者提供的解決方案安全性明顯較低（36%對50%）。有36%的使用人工智能助手的參與者編寫了容易受到SQL注入攻擊的解決方案，而不使用AI助手的對照組的這一比例僅為7%。

開發者最常用的提示詞

開發者通常會選擇使用用多種策略提示人工智能助手：64%的開發者嘗試直接任務規范；21%的開發者選擇向AI助手提供函數聲明指令（例如“編寫一個函數……”）；49%的人指定了編程語言；61%使用先前模型生成的提示詞來提示代碼助手（這可能會強化模型提供的漏洞）；53%的開發者指定了特定API調用的特定庫；Python開發者提供函數聲明更為常見；而參與者更有可能為SQL和C問題指定編程語言。

整改建議

一、優化提示詞。調查發現，使用AI的開發者用戶的語言和提示參數的選擇存在顯著差異。建議未來的系統在將用戶的提示用作系統的輸入之前，應考慮改進用戶的提示（例如修復拼寫錯誤并包含設計人員易于實施的有關安全性的語言），以更好地優化整體性能。

另一種方法可以考慮基于機器學習的方法來預測用戶提示的意圖（或者他們的任務可能產生的特定類別的安全問題），然后修改提示以防范已知漏洞或AI輸出。

二、減少AI的代理權。提供不安全代碼的開發者不太可能主動修改人工智能助手的輸出或調整參數，這意味著不能給予人工智能助手太多的代理權（例如自動參數選擇），因為這樣可能會導致用戶疏于防范安全漏洞。隨著人工智能代碼助手變得越來越普遍，這些都是需要考慮的重要解決方案。例如，與GitHubCopilot集成的VSCode等IDE可以調整默認行為，根據AI助手建議的庫，實時清晰地顯示庫文檔和使用警告。

三、凈化訓練數據。許多人工智能編程助手都使用GitHub上的不安全代碼進行模型訓練。開發者需要對這些輸入（開源代碼）運行靜態分析工具，僅使用通過安全檢查的輸入（代碼）進行訓練，以及設計更聰明的方法，利用庫文檔和“專家”代碼示例在訓練前重新加權整個數據集，可以顯著提高數據的安全性。

結論

使用人工智能助手寫代碼開發者在大多數編程任務中更有可能引入安全漏洞。此外，查詢人工智能助手的提示詞越專業具體（例如提供幫助函數或調整參數），生成的代碼越安全。