Backslash Security 的最新研究揭示了一個令人擔憂的趨勢：大型語言模型 (LLMs)，如 GPT-4.1，以及其他廣泛使用的模型，傾向於預設產生不安全的代碼。這意味著，如果沒有針對安全性的特定指示或指南，這些 AI 系統產生的代碼通常容易受到常見弱點和漏洞的攻擊。然而，研究也表明，通過提供額外的安全指導或實施基於規則的治理，可以顯著提高生成代碼的安全性。
為了進一步探討這個問題，Backslash Security 宣布推出模型上下文協議 (Model Context Protocol, MCP) 伺服器，以及專為 Agentic 整合開發環境 (Integrated Development Environments, IDEs) 設計的規則和擴展。這些工具旨在解決 LLM 生成代碼中發現的安全漏洞，並為開發人員提供創建更安全應用程式的手段。
LLMs 與不安全代碼生成：預設情境
Backslash Security 對七個不同版本的流行 LLM 進行了一系列測試，包括 OpenAI 的 GPT 模型、Anthropic 的 Claude 和 Google 的 Gemini。目標是評估各種提示技術如何影響模型生成安全代碼的能力。代碼輸出的安全性是根據其對抗十個常見弱點列舉 (Common Weakness Enumeration, CWE) 用例的彈性來評估的，這些用例代表了一系列常見的軟體漏洞。
這些測試的結果一致表明，隨著更複雜的提示技術，生成代碼的安全性有所提高。然而，總體主題是，所有測試的 LLM 在沒有任何引導的情況下，通常會產生不安全的代碼。這表明這些模型在其預設配置中，沒有優先考慮安全性，並且常常無法解決常見的編碼弱點。
天真的提示：漏洞的配方
當呈現簡單的、’天真的’提示，沒有明確提及安全考量時，所有測試的 LLM 都生成了不安全的代碼，這些代碼容易受到至少四個常見 CWE 的攻擊。這突顯了這些模型在沒有特定指導的情況下運作時，內在缺乏安全意識。
安全導向提示的影響
通常指定需要安全性的提示，會產生更安全的結果，表明 LLM 有能力在明確指示這樣做時，生成更安全的代碼。此外，要求代碼符合開放網路應用程式安全專案 (Open Web Application Security Project, OWASP) 最佳實踐的提示，產生了更好的結果。OWASP 是一個非營利基金會，致力於提高軟體的安全性。然而，即使使用這些更複雜的提示，在七個測試的 LLM 中，仍有五個存在一些代碼漏洞，突顯了使用 LLM 持續生成安全代碼的挑戰。
基於規則的提示：通往安全代碼的道路
生成安全代碼最有效的方法是使用綁定到 Backslash 指定的規則的提示，以解決特定的 CWE。這些基於規則的提示產生了安全且不受測試 CWE 攻擊的代碼。這表明，為 LLM 提供具體的、有針對性的指導，對於確保生成代碼的安全性至關重要。
LLMs 之間的效能差異
總體而言，OpenAI 的 GPT-4o 在所有提示中的表現最低，當使用 ‘天真’提示時，僅獲得 10 分中的 1 分的安全代碼結果。即使在提示生成安全代碼時，它仍然產生不安全的輸出，容易受到十分之八的問題的攻擊。GPT-4.1 在使用天真提示時的表現也沒有明顯改善，得分為 10 分中的 1.5 分。
相比之下，Claude 3.7 Sonnet 成為測試的 GenAI 工具中表現最好的工具。它在使用天真提示時獲得 10 分中的 6 分，在使用以安全為重點的提示時獲得完美的 10 分。這表明，即使在沒有明確指示的情況下，某些 LLM 也能更好地處理安全考量。
Backslash Security 的安全編碼解決方案
為了應對其 LLM 提示測試揭示的問題，Backslash Security 正在引入多項旨在實現安全編碼的新功能。編碼指的是使用 AI 工具（如 LLM）生成代碼的做法。
Backslash AI 規則與策略
Backslash AI 規則與策略提供機器可讀的規則，可以注入到提示中，以確保 CWE 覆蓋率。這些規則可以與 Cursor 等工具一起使用，Cursor 是一個流行的代碼編輯器。此外，AI 策略透過 Backslash 平台控制哪些 AI 規則在 IDE 中處於活動狀態，允許組織客製化其安全設定。
Backslash IDE 擴展
Backslash IDE 擴展直接整合到開發人員現有的工作流程中，允許他們接收 Backslash 對人類和 AI 編寫的代碼的安全審查。這種整合對於確保在整個開發過程中解決安全考量至關重要。
Backslash 模型上下文協議 (MCP) 伺服器
Backslash 模型上下文協議 (MCP) 伺服器是一個上下文感知的 API，符合 MCP 標準。它將 Backslash 連接到 AI 工具，從而實現安全編碼、掃描和修復。MCP 標準為 AI 工具提供了一個通用的框架來溝通和共享資訊，從而促進了安全 AI 驅動應用程式的開發。
解決 AI 生成代碼的挑戰
Backslash Security 的共同創辦人兼技術長 Yossi Pik 強調了 AI 生成代碼對安全團隊構成的挑戰。他指出：’AI 生成的代碼 – 或編碼 – 對於安全團隊來說，可能感覺像是一場噩夢。它創造了大量的新代碼，並帶來了 LLM 風險，如幻覺和提示敏感性。’ 幻覺指的是 LLM 產生不正確或毫無意義的資訊的情況，而提示敏感性指的是 LLM 根據輸入提示的細微變化產生不同輸出的趨勢。
然而，Pik 也認為，當使用正確的控制時，AI 可以成為 AppSec 團隊的寶貴工具。他認為：’透過正確的控制 – 比如組織定義的規則和連接到專用安全平台的上下文感知 MCP 伺服器 – AI 實際上可以從一開始就賦予 AppSec 團隊更多的控制權。’ Backslash Security 旨在透過其動態的基於策略的規則、上下文敏感的 MCP 伺服器和 IDE 擴展來提供這些控制，所有這些都是為新編碼時代設計的。
不安全 AI 生成代碼的影響
Backslash Security 研究的發現對軟體開發行業具有重大影響。隨著 AI 驅動的代碼生成工具變得越來越普遍，了解在沒有適當安全措施的情況下依賴這些工具所帶來的風險至關重要。
增加遭受網路攻擊的風險
不安全 AI 生成的代碼可能會產生新的漏洞，網路罪犯可以利用這些漏洞。這些漏洞可能導致資料外洩、系統損害和其他安全事件。
難以識別和修復漏洞
AI 生成代碼的龐大數量使得識別和修復漏洞變得具有挑戰性。安全團隊可能難以跟上快速的代碼生成速度，導致安全問題的積壓。
開發人員缺乏安全意識
許多開發人員可能沒有完全意識到與 AI 生成代碼相關的安全風險。這種缺乏意識可能會導致開發人員無意中將漏洞引入到他們的應用程式中。
法規合規性挑戰
依賴 AI 生成代碼的組織可能面臨法規合規性挑戰。許多法規要求組織實施適當的安全措施來保護敏感資料。不安全 AI 生成的代碼可能使滿足這些要求變得困難。
安全 AI 驅動代碼生成的最佳實踐
為了降低與不安全 AI 生成代碼相關的風險，組織應採用以下最佳實踐：
向開發人員提供安全培訓
開發人員應接受關於與 AI 生成代碼相關的安全風險的培訓。該培訓應涵蓋常見 CWE、安全編碼實踐以及如何使用安全工具等主題。
實施安全策略和程序
組織應實施解決 AI 生成代碼使用的安全策略和程序。這些策略應定義可接受的用例、安全要求以及審查和批准 AI 生成代碼的流程。
使用安全工具掃描 AI 生成代碼
組織應使用安全工具掃描 AI 生成代碼中的漏洞。這些工具可以幫助識別常見 CWE 和其他安全問題。
實施安全開發生命週期 (SDLC)
組織應實施安全開發生命週期 (Secure Development Lifecycle, SDLC)，將安全考量納入整個開發過程。這包括對 AI 生成代碼進行安全審查、執行滲透測試以及實施安全監控。
建立漏洞賞金計劃
組織應建立一個漏洞賞金計劃，以鼓勵安全研究人員查找和報告 AI 生成代碼中的漏洞。這可以幫助識別內部安全團隊可能錯過的漏洞。
隨時了解最新的安全威脅
組織應隨時了解影響 AI 生成代碼的最新安全威脅和漏洞。這可以幫助他們主動解決潛在的安全問題。
與安全專家合作
組織應與安全專家合作，評估其 AI 生成代碼的安全性並制定降低風險的策略。
安全 AI 驅動代碼生成的未來
隨著 AI 驅動的代碼生成工具不斷發展，優先考慮安全性至關重要。透過實施上述最佳實踐，組織可以利用 AI 驅動代碼生成的好處，同時降低與不安全代碼相關的風險。
AI 安全的進步
正在進行的研究和開發工作集中在提高 AI 系統的安全性。這些努力包括開發用於檢測和預防對抗性攻擊的新技術、提高 AI 模型的穩健性以及創建更安全的 AI 架構。
將安全性整合到 AI 開發中
安全性正越來越多地整合到 AI 開發過程中。這包括將安全考量納入 AI 模型的設計中、使用安全編碼實踐以及在整個開發生命週期中進行安全測試。
AI 和安全專家之間的合作
AI 和安全專家之間的合作對於確保 AI 系統的安全性至關重要。這種合作可以幫助識別潛在的安全風險並制定有效的緩解策略。
提高對 AI 安全風險的認識
提高對 AI 安全風險的認識正在推動新的安全工具和技術的開發。這包括用於檢測對抗性攻擊、分析 AI 模型安全性和監控 AI 系統是否存在可疑活動的工具。
透過解決與 AI 生成代碼相關的安全挑戰，組織可以釋放 AI 驅動開發的全部潛力，同時保護其系統和資料免受網路攻擊。