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

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

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

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

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

多個國家的開發(fā)人員參與了該調(diào)查，其中大多數(shù)來自以下三個國家：

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

該調(diào)查的關(guān)鍵發(fā)現(xiàn)如下：

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

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

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

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

開發(fā)者最常用的提示詞

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

整改建議

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

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

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

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

結(jié)論

使用人工智能助手寫代碼開發(fā)者在大多數(shù)編程任務中更有可能引入安全漏洞。此外，查詢?nèi)斯ぶ悄苤值奶崾驹~越專業(yè)具體（例如提供幫助函數(shù)或調(diào)整參數(shù)），生成的代碼越安全。