在Salt的受訪者中,29%的人直指不安全的編碼模式為首要風險,另外有15%的人則將程式碼與內部安全政策不一致當成最大的隱憂 。這兩種恐懼其實源自同一個病灶:AI編碼助理是在公開程式碼上訓練出來的模型,它並不了解任何個別組織的內部安全政策、行業框架或合規要求
。
Salt報告定義了「安全漂移」這個概念,解釋為何這個普及矛盾會演變成真實的曝險。原理很簡單:一家組織將安全規則寫在維基頁面、PDF檔案和口耳相傳的「部落知識」裡,而AI助理根本沒有閱讀過這些東西。當它生成出一段語法正確、功能合用的程式碼時,這行程式碼可能已默默地違反了那些內部政策。由於審查流程早已追不上程式碼產生的速度,所以根本沒人會抓出來 。
這帶出了Salt報告中最具行動意義、也最令人憂心的治理數字:當今仍有38%的組織,主要依賴人工程式碼審查(Code Review)來處理AI編碼助理產出的海量程式碼。AI程式碼的產量早已超過人類審查者能有意義檢視的規模,而Salt預測到2027年,這道產能與監督之間的鴻溝只會更進一步擴大 。目前只有極少數的組織,真正將自動化的安全護欄整合進AI編碼的開發工作流程之中
。
Salt Security執行長羅伊·埃利亞胡(Roey Eliyahu)對這個局勢下了個直接的總結:安全治理 完全跟不上 AI編碼助理改變軟體開發方式的步調 。傳統的靜態與動態分析工具(SAST/DAST)總是在開發的最後階段才發現問題,而那時候,每一次修補都是大規模的改寫,每一次改寫都代表進度延宕
。
這項研究找了16位經驗豐富的開源開發者,讓他們在自己長期維護的成熟程式庫上,進行246項真實世界的任務——這些程式庫平均擁有超過百萬行程式碼,並獲得上萬顆GitHub星星。參與者被隨機分配,一組能使用AI工具(主要是Cursor Pro搭配Claude 3.5/3.7 Sonnet),另一組則完全不能使用 。
這項研究最常被引用的結論,由於曝光度極高,已經快要變成一種背景雜音,但其數據依然相當驚人:能使用AI輔助的開發者,任務完成時間比完全沒用AI的開發者慢了19%。然而,在實驗開始前,這些受測者原本預測AI能讓他們快24%;任務完成後,他們則主觀估計AI大概讓自己快了20%。客觀碼表測出的結果與他們的感受之間,足足有超過39個百分點的落差 。
METR的這項發現,並不等於宣告AI工具一無是處——情境非常關鍵。在協助新人上手、產生重複性樣板程式碼(Boilerplate),或是開發者較不熟悉的程式碼區塊等場景中,確實能觀察到生產力提升。但是,對於在複雜、高度仰賴對既有程式庫理解度的任務上工作的資深工程師,證據顯示當前的AI工具可能帶來了一種他們自己並未察覺到的摩擦力 。
Salt選在研究報告發布的同一時間,推出一款直面報告所指「治理鴻溝」問題的新產品。2026年6月1日,該公司正式發表了 Salt Code,這是其AI代理安全平台(Agentic Security Platform)中的一項全新組件 。
Salt Code的策略,是直接在安全漂移開始之前就阻止它發生。與其等到AI生成程式碼之後才進行掃描,它選擇在開發者使用AI編碼助理的當下,直接將組織的內部安全與合規規則,強制注入到程式碼產生的那一刻。這款產品能相容於當前企業陸續標準化的各大AI編碼工具:Claude Code、Cursor、GitHub Copilot、Windsurf、Codex以及Gemini CLI 。
它的目標,是讓產出「符合政策的程式碼」內建為AI助理的預設行為,而不是一個需要仰賴下游掃描與大翻修才能達成的目標。對安全團隊而言,它提供了一個可貫穿程式碼產出、開發管線檢查及運行時監控的單一政策層——這是一個從「抓Bug」轉向「預防Bug」的巨大思維轉變 。
Salt Code這類工具能否以AI普及的速度,成功填補這道治理鴻溝,仍是個懸而未決的問題。但未來的走向是清晰的。如果預測成真——AI將在未來18個月內寫出超過一半的企業程式碼——那麼,安全政策就必須從「審查階段」的守門員,進化為「預設強制執行」的出廠設定。否則,正如Salt報告所警告的那樣,人類將面臨的是,一場規模難以想像的「產業級安全漂移」。
Comments
0 comments