AI編碼工具已從實驗階段發展成為日常開發輔助工具，幫助軟體團隊編寫功能、解釋不熟悉的程式碼、產生測試，並更快完成重複性變更。對於安全團隊而言，更棘手的問題是：在有人驗證其安全性之前，有多少AI產生的程式碼會提交到合併請求中？

Stack Overflow 最近的一項調查發現，46% 的開發者不信任 AI 工具輸出的準確性，而只有 33% 的開發者信任它。這種擔憂在例行安全審查中尤其明顯。例如，產生的 API 處理程序可能會編譯通過單元測試，但卻缺少物件層級授權。同時，建議的依賴項可能看起來合法，但實際上可能已被棄用、漏洞或名稱可疑。

OWASP Top 10 大型語言模型應用安全風險清單將供應鏈風險列為大型語言模型 (LLM) 系統面臨的主要風險之一。該清單涵蓋了即時注入、不安全的輸出處理、敏感資訊外洩、過度代理以及供應鏈漏洞等風險。如今，這些風險正日益滲透到開發環境、程式碼助理、管線自動化以及人工智慧 (AI) 應用中。

應用安全平台如何適應

人工智慧輔助開發給傳統的應用安全流程（程式碼審查、掃描、提交工單和修復）帶來了壓力。在更短的時間內可以產生更多程式碼，如果團隊不斷重複使用產生的程式碼範例，同樣的安全漏洞模式可能會在多個服務中重現。

這凸顯了應用安全平台的必要性，它需要將整個開發工作流程中的發現結果串聯起來，而不是將掃描視為一個獨立的檢查點。一個由人工智慧輔助實現的小改動可能會影響多個層面：新的軟體包、API 路由、設定檔、容器鏡像或基礎設施腳本都可能在下游產生影響。

只有將漏洞發現與可存取性、資料暴露、權限等級以及受影響的服務聯繫起來，該發現才有意義。涉及客戶資料的公共 API 中的漏洞與不可存取的測試程式碼中的類似缺陷需要區別對待。

最有用的回饋往往出現在開發者已經做出決策的地方，尤其是在拉取請求、整合開發環境 (IDE) 和持續整合/持續交付 (CI/CD) 檢查中。程式碼審查者可能需要仔細檢查程式碼的變更之處，以及產生的程式碼在專案中所包含的假設。

為什麼需要審查產生的程式碼變更

AI 產生的程式碼看起來比實際情況更像生產就緒程式碼，它可能使用熟悉的命名、常見的框架模式和精雕細琢的結構。這種精雕細琢可能會掩蓋授權薄弱、預設設定不安全或依賴項選擇不當等問題，而這些問題在繁忙的開發週期中可能會被程式碼審查人員忽略。問題通常出現在細節中。產生的程式碼可能過於信任客戶端輸入，跳過伺服器端授權，暴露詳細錯誤訊息，過度記錄敏感數據，使用過時的加密範例，或推薦某個軟體包而未檢查其維護歷史。

這些都是普通的應用安全故障，但人工智慧工具可以快速產生這些故障，而產生的形式看起來已經可以投入生產。

人工智慧產生的修復程式與人工智慧產生的功能一樣，都應受到嚴格審查。例如，開發者可能會要求助手修復注入風險，但收到的修補程式可能只解決了一個參數的問題，卻遺留了其他漏洞。在身份驗證、支付、管理和客戶資料工作流程中，人工智慧產生的修復程序需要與生成的功能進行同等的審查。

SDLC 控制應該在哪些地方發生變化

治理應放在首位。組織應明確規定哪些人工智慧編碼工具獲得批准，哪些資料可以與它們共享，以及哪些程式碼庫、文件或機密資訊禁止存取。即使程式碼是由助手協助編寫的，開發者也要應對其提交的程式碼負責。

程式碼審查還需要風險篩選。低風險的輔助函數無需像涉及身分、付款、客戶記錄或管理權限的程式碼那樣經過相同的審查流程。拉取請求範本可以詢問：AI 是否參與了此次變更？是否引入了新的依賴項？以及是否修改了安全敏感邏輯？

威脅建模應考慮產生的程式碼在工作流程中的進入位置、它所做的假設，以及當這些假設不成立時攻擊者可能採取的行動。安全的軟體開發實踐應整合到軟體開發生命週期（SDLC）中，而不是作為最終發布檢查的一部分。

降低人工智慧輔助程式碼風險的控制措施

依賴項檢查需要在 AI 建議的軟體包進入專案之前就將其捕獲。開發人員不應在未檢查原始程式碼、命名、維護情況、許可證和已知漏洞的情況下安裝 AI 建議的軟體包。當建議的庫出現在快速編碼流程中時，更容易忽略域名搶注和軟體包混淆的問題。

密鑰偵測應在程式碼合併到主分支之前運行。產生的範例可能包括佔位符金鑰、弱令牌、暴露的憑證或不安全的設定模式。在提交或拉取請求階段阻止私鑰、API 令牌、雲端憑證和資料庫金鑰可以減少不必要的風險暴露。

授權測試應證明錯誤的使用者無法存取、變更或刪除其他使用者的資料。公共 API 和管理功能應包含橫向和縱向權限檢查。

輸入輸出驗證應結合上下文進行審查。產生的程式碼應檢查是否有註入風險、不安全的反序列化、不安全的文件處理、不正確的編碼以及薄弱的內容類型控制。對於人工智慧應用，模型輸出在到達瀏覽器、資料庫、shell 命令、插件或第三方服務之前，應被視為不可信資料。

如果同樣的 AI 輔助模式不斷導致缺少授權檢查、不安全的驗證或弱依賴項選擇，那麼修復措施應該轉向安全模板、編碼標準和更具體的開發人員指導。

優先考慮曝光度，而非數量

在進行原始碼安全檢查時，AI輔助開發可能會增加發現的問題數量。如果對所有警報都採取相同的緊急程度，會拖慢團隊進度，並削弱對安全工具的信任。問題分類應該從實際暴露的問題開始。

處理客戶資料的公共 API中存在的中等嚴重性漏洞，可能比無法存取的測試程式碼中存在的嚴重問題需要更快地處理。支付服務中的易受攻擊軟體包與內部原型中的相同軟體包的緊急程度也不同。一個有效的優先排序模型會考慮易受攻擊的路徑是否可存取、是否面向互聯網、是否與特權操作相關，或者是否與敏感資料連接。

開發人員還需要能夠解釋受影響路徑和最安全修復方案的發現結果。在發布壓力下，通用警告很容易被忽略。如果發現結果能夠指出受影響路徑、解釋該上下文中的風險，並提出適合當前框架的修復方案，那麼開發人員就更容易採取行動。

應用安全需要與時俱進

人工智慧編碼工具如今已成為日常開發的一部分，因此安全方案需要考慮它們如何改變程式碼量、審查速度和程式碼來源。產生的程式碼仍然需要所有權、測試和問責制。能夠更好地適應的團隊，會將安全檢查提前到程式碼建立階段，在採用前驗證依賴關係，並優先處理最有可能進入生產環境的風險。

資料來源：https://hackread.com/application-security-strategies-ai-generated-code-sdlc/