在采訪中，Sonar的安全專家兼安全治理負責人Silviu Asandei討論了AI代碼助手如何改變開發工作流程并影響安全性，他解釋了這些工具如何提高生產力，但如果未經過適當審查，也可能傳播漏洞。

AI代碼助手對開發者和企業可能忽視的安全風險有哪些?

雖然AI代碼助手提高了開發者的生產力，但它們在多個領域引入了重大且常被忽視的安全風險。在人為層面，過度依賴可能培養一種“虛假自信”，導致未經審查的不安全代碼和開發者技能下降，這可能創造一個“生成式單一文化”，其中流行AI建議中的一個缺陷會被廣泛復制。

技術上，這些工具可能生成包含SQL注入等漏洞的代碼，嵌入硬編碼的秘密，并建議過時的依賴項。使用基于云的助手會引發數據隱私問題，因為專有代碼可能會被暴露或用于訓練，從而導致知識產權和許可侵權。

AI模型本身也容易受到諸如提示注入和數據中毒等攻擊，正如OWASP針對大型語言模型(LLM)的十大威脅所強調的那樣。此外，AI助手可能成為軟件供應鏈攻擊的新載體，通過大規模引入漏洞來擴大潛在的攻擊面。這些多方面的風險遠遠超出了簡單的代碼錯誤，需要一種全面的安全方法，該方法涵蓋人為因素、數據治理、模型完整性以及更廣泛的軟件開發生命周期。

審查或保護AI代碼助手生成的代碼有哪些最佳實踐?

保護AI代碼助手生成的代碼需要一種多層次的策略，該策略結合了人類勤勉、穩健的技術和明確的組織治理，這種方法的核心是保持關鍵的人類監督。

開發者必須采取“信任但驗證”的心態，將AI建議視為來自經驗不足的助手的代碼，需要進行徹底審查。至關重要的是，不僅要驗證代碼的功能性，還要完全理解其底層邏輯和潛在的安全影響。這種警惕性應該通過加強代碼審查文化來正式化，其中AI生成的片段應接受額外審查。

技術上，所有代碼都應使用一套公正的安全工具進行掃描，這包括靜態(SAST)、動態(DAST)和軟件成分分析(SCA)，以分別檢測漏洞、運行時問題和不安全的依賴項。開發者還應通過提供詳細上下文并明確要求AI納入安全措施來實踐安全的提示工程，例如，通過請求防止 SQL 注入等特定攻擊的代碼。

這些個人實踐必須得到強大的組織護欄的支持，企業需要建立明確的AI使用政策，概述哪些工具獲得批準以及可以共享哪些數據，對開發者進行關于AI風險、安全提示以及對AI輸出進行批判性評估的全面培訓至關重要。

此外，對所有AI生成的代碼執行最小權限原則，并對智能體助手進行沙盒處理，可以防止潛在的傷害。通過培養一個開發者與AI作為隊友協作并致力于持續學習的環境，企業可以安全地利用這些強大的工具。這種整體方法確保了從AI中獲得的生產力提升不會以犧牲安全性為代價。

訓練數據和模型架構在多大程度上影響代碼助手的安全態勢?它們是否容易復制不安全的編碼模式?

AI 代碼助手的安全性從根本上由其訓練數據和模型架構決定，這兩者都可能導致生成不安全的代碼。

訓練數據，通常來源于龐大的公共倉庫，是一個主要關注點。如果這些數據包含不安全的編碼實踐、硬編碼的秘密(如 API 密鑰)或具有已知漏洞的過時庫，AI 就會學習并復制這些缺陷。這可能導致建議中包含 SQL 注入等漏洞或使用過時的加密函數。模型的知識僅限于其訓練數據，因此它可能會推薦較舊、易受攻擊的組件。此外，惡意行為者可以故意污染訓練數據，導致AI生成有害代碼。

模型的架構也增加了安全風險，當前模型往往缺乏對特定應用程序安全需求的深入上下文理解，生成語法正確但功能上不安全的代碼，它們難以區分受信任的開發者指令和不受信任的用戶輸入，使它們容易受到提示注入攻擊。一種稱為“生成式單一文化”的現象也可能出現，其中AI反復建議相似的代碼結構。如果這種常見代碼存在缺陷，它可能會創建廣泛的漏洞。最終，這些模型優先考慮復制所學的模式而非遵守安全原則，而且它們的復雜、“黑箱”性質使得審計其推理和識別潛在弱點變得困難。

在代碼生成方面，專有AI助手(如GitHub Copilot)和開源模型之間在安全性上是否存在可測量的差異?

最顯著的可測量的安全差異在于數據隱私，其中自托管的開源模型具有明顯優勢。就生成的代碼本身的安全性而言，兩種模型類型都容易受到從訓練數據中繼承的相似缺陷的影響。輸出的最終安全性更多地取決于訓練數據質量、提示工程以及應用于生成代碼的嚴格人類監督等因素，而非模型是專有還是開源。

? 其訓練數據和微調的質量和安全重點。

? 其架構在理解上下文和安全要求方面的復雜性。

? 開發者使用的提示的特異性和安全意識。

? 應用于生成代碼的人類審查、測試和驗證過程的嚴格性。

你是否觀察到AI代碼助手對安全開發生命周期或DevSecOps實踐產生任何影響模式?

AI代碼助手通過引入挑戰和機遇，顯著重塑了安全開發(DevSecOps)。一個主要模式是加速了開發，這產生了大量代碼，超出了傳統安全審查的能力范圍。這擴大了攻擊面并引入了新的漏洞，因為AI可以建議不安全的代碼、硬編碼的秘密或過時的庫。

這種新動態使得將“左移”(shift left)進一步推進為“開始左移”(start left)變得至關重要——在開發生命周期的開始階段就集成安全檢查，它還要求開發能夠掃描AI生成代碼的獨特潛在缺陷的“AI 感知”安全工具。人類監督仍然至關重要，開發者需要采取“信任但驗證”的方法并適應代碼審查過程。

采用“開始左移”的心態對于開發團隊自信地接受AI生成的代碼至關重要，這確保了從第一行代碼開始，無論是人類還是AI輔助的代碼，都符合最高的質量和安全標準。通過盡早識別潛在問題，團隊可以防止代價高昂的重做，提高開發速度，并在其代碼中建立更強的信任基礎。

雖然AI可能會通過“影子 AI”等增加合規和數據泄露的風險，但AI也為增強 DevSecOps 提供了機會。AI驅動的工具可以自動化威脅檢測、漏洞評估和補丁管理，從而形成一個新的范式，其中AI用于防御AI驅動的威脅并保護AI生成的代碼。