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

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

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

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

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

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

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

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

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

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

此外，對所有AI生成的代碼執(zhí)行最小權(quán)限原則，并對智能體助手進行沙盒處理，可以防止?jié)撛诘膫ΑＭㄟ^培養(yǎng)一個開發(fā)者與AI作為隊友協(xié)作并致力于持續(xù)學習的環(huán)境，企業(yè)可以安全地利用這些強大的工具。這種整體方法確保了從AI中獲得的生產(chǎn)力提升不會以犧牲安全性為代價。

訓練數(shù)據(jù)和模型架構(gòu)在多大程度上影響代碼助手的安全態(tài)勢?它們是否容易復制不安全的編碼模式?

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

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

模型的架構(gòu)也增加了安全風險，當前模型往往缺乏對特定應用程序安全需求的深入上下文理解，生成語法正確但功能上不安全的代碼，它們難以區(qū)分受信任的開發(fā)者指令和不受信任的用戶輸入，使它們?nèi)菀资艿教崾咀⑷牍簟Ｒ环N稱為“生成式單一文化”的現(xiàn)象也可能出現(xiàn)，其中AI反復建議相似的代碼結(jié)構(gòu)。如果這種常見代碼存在缺陷，它可能會創(chuàng)建廣泛的漏洞。最終，這些模型優(yōu)先考慮復制所學的模式而非遵守安全原則，而且它們的復雜、“黑箱”性質(zhì)使得審計其推理和識別潛在弱點變得困難。

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

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

? 其訓練數(shù)據(jù)和微調(diào)的質(zhì)量和安全重點。

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

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

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

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

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

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

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

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