近九成安全主管對AI生成代碼嘅安全風險好有顧慮,但有38%企業仲係主要靠人手審查去捉蟲——工作量同監控能力完全唔成比例,遲早爆鑊。 METR嘅嚴格測試發現,資深開發者用咗AI編碼工具之後,完成任務嘅時間實際上慢咗19%,但佢哋就覺得自己快咗20%,生產力錯覺勁到嚇死人。

Create a landscape editorial hero image for this Studio Global article: What security risks, adoption rates, governance gaps, and developer perception issues surround AI-generated code, according to Salt Security. Article summary: Here are the key findings from Salt Security's June 2026 report **"AI Coding Assistants and the New Security Challenge"** [1][2].. Topic tags: general, academic, general web, user generated. Reference image context from search candidates: Reference image 1: visual subject "The rapid adoption of AI coding assistants is creating a new governance challenge for enterprise security teams, according to research released by Salt Security, which found that n" source context "Salt Security AI coding assistants" Reference image 2: visual subject "Salt Security launches Salt Code, the first agentic security solution to enforce security policies inside AI coding assistants
軟件工程界嘅AI採用速度快到離晒譜,搞到出現咗一個大家都唔想見到嘅裂口。一邊廂,開發團隊用極速擁抱編碼助手;另一邊廂,負責把關嗰套安全機制,仲係停留喺「每一行代碼都係由一個人用可預測嘅速度慢慢打出嚟」嘅思維模式。Salt Security喺2026年6月出咗份《AI編碼助手同全新安全挑戰》報告,將呢個差距量化得好赤裸,仲引入咗一個可能定義未來應用程式安全時代嘅術語:安全漂移(Security Drift)。
AI編碼助手已經唔係咩實驗性質嘅小眾工具。Salt嘅研究發現,有67%嘅受訪機構表示呢類工具已經喺佢哋嘅開發團隊度廣泛使用 。佢哋仲預測,去到2027年,AI輔助編寫嘅代碼將會超過企業代碼總量嘅一半——一旦過咗呢個門檻,就意味着機器生成嘅代碼會成為投入生產系統嘅主要來源
。
呢種增長喺企業科技嘅其他領域,通常會大肆慶祝。最大問題係,當呢批代碼殺到埋身,但安全防禦措施完全跟唔上嗰陣,就會出大事。有90%嘅安全主管向Salt表示,佢哋對AI生成代碼帶嚟嘅風險有實質嘅憂慮 。佢哋嘅擔心絕對唔係捕風捉影。Salt報告入面引用咗Veracode嘅最新測試數據,顯示AI生成代碼嘅安全合格率得大約55%——呢個數字喺兩年內幾乎冇變過,換句話講,喺冇明確安全指引嘅情況下,有接近一半嘅生成代碼都存在已知漏洞
。
喺Salt嘅受訪者入面,有29%認為唔安全嘅編碼模式係最大風險,另有15%就話最擔心嘅係生成代碼同公司內部安全政策唔夾 。兩種擔心都源於同一個根本原因:AI編碼助手嘅訓練素材係公開代碼,而唔係任何一間公司自己嘅安全政策、行業框架或者合規要求
。
報告入面提出咗「安全漂移」呢個概念,解釋點解速度同監控嘅脫節會變成實際嘅安全漏洞。個邏輯好簡單:公司將安全規則寫晒喺Wiki、PDF文件同埋老臣子嘅腦入面,但AI助手從來唔會去睇。於是個助手就生成咗一堆語法冇錯、功能正常,但靜靜雞違反晒內部政策嘅代碼。因為審查流程根本追唔上生產速度,結果冇人發現到問題 。
呢度帶出咗Salt報告入面其中一個最實用、同時亦都最得人驚嘅發現:有38%嘅機構,仍然主要依賴人手代碼審查去處理AI編碼助手嘅輸出。AI生成代碼嘅數量,早就超出咗人類評審員可以有意義咁檢查嘅能力範圍。Salt對2027年嘅預測就更加講明,呢個差距只會越拉越大 。目前只有好少數機構,有將自動化安全護欄整合到AI編碼嘅工作流程入面
。
Salt Security嘅行政總裁Roey Eliyahu好直接咁總結咗個情況:治理機制完全追唔上AI編碼助手改變軟件開發嘅步伐 。傳統嘅靜態同動態分析工具(SAST/DAST)往往去到開發流程好後期先搵到問題,嗰陣時每一個修正都等於要重寫,每一次重寫都代表住延遲
。
安全治理唔係唯一一個「認知同現實」嚴重脫節嘅範疇。Salt嘅報告特別引用咗一項外部研究,呢項研究已經成為開發者工具界嘅重要參考點:就係METR喺2025年7月發表嘅隨機對照測試 。
呢項研究安排咗16位資深開源開發者,喺佢哋自己嘅成熟代碼庫入面處理246個真實世界嘅任務——呢啲代碼庫平均超過一百萬行程式碼,喺GitHub有數以萬計嘅星星。參加者隨機分成兩批,一批可以用AI工具(主要係Cursor Pro配Claude 3.5/3.7 Sonnet),另一批就冇得用 。
研究結果嘅標題數字已經俾人引用到爛,但仍然非常震撼。用AI嘅開發者,完成任務嘅時間比冇用AI嘅慢咗19%。 喺測試開始之前,呢班開發者預測AI會令佢哋快24%。做完晒任務之後,佢哋估計呢啲工具令佢哋快咗大約20%——但客觀嘅量度數據就顯示佢哋係慢咗。覺得自己快咗同實際上係慢咗之間,個差距超過39個百分點 。
METR嘅發現並唔代表AI工具冇用——要睇情況。喺新人上手、例行嘅樣板代碼生成,或者開發者對個代碼庫冇咁熟嘅任務入面,確實見到生產力提升。但對於要處理複雜、極度依賴對代碼庫理解嘅任務嘅資深工程師嚟講,證據就話畀我哋知,呢啲工具可能會帶嚟一啲開發者自己都唔為意嘅阻力 。
Salt揀喺發布研究報告嘅同一時間,推出咗一個專為解決報告所講嘅治理缺口而設計嘅產品。2026年6月1號,佢哋推出咗Salt Code,呢個係佢哋更大型嘅「智能體安全平台」嘅一個新組件 。
Salt Code嘅做法係喺安全漂移出現之前就阻止佢。佢唔係事後先掃描AI生成嘅代碼,而係直接喺開發者用AI編碼助手生成代碼嗰一刻,就強制執行公司內部嘅安全同合規規則。呢個產品可以喺現時企業主流採用嘅工具上運作,包括:Claude Code、Cursor、GitHub Copilot、Windsurf、Codex同Gemini CLI 。
個目標係令到符合政策嘅代碼成為預設輸出,而唔係要靠下游嘅掃描同重寫先做到。對安全團隊嚟講,佢提供咗一個單一嘅政策層,可以貫穿代碼創建、流程檢查同執行期間監控——由「捉錯誤」轉變成「預防錯誤」 。
Salt Code或者類似嘅工具,係咪可以快到追得上AI採用嘅速度,去修補呢個治理缺口,而家仲係一個未知數。不過個大趨勢已經好清楚。如果個預測係啱嘅——AI喺十八個月內將會編寫超過一半嘅企業代碼——咁安全政策就一定要由「審查關卡」,進化到成為「預設配置」。Salt報告警告,如果唔係咁,就係一場工業規模級別嘅安全漂移。
Studio Global AI
Use this topic as a starting point for a fresh source-backed answer, then compare citations before you share it.
近九成安全主管對AI生成代碼嘅安全風險好有顧慮,但有38%企業仲係主要靠人手審查去捉蟲——工作量同監控能力完全唔成比例,遲早爆鑊。
近九成安全主管對AI生成代碼嘅安全風險好有顧慮,但有38%企業仲係主要靠人手審查去捉蟲——工作量同監控能力完全唔成比例,遲早爆鑊。 METR嘅嚴格測試發現,資深開發者用咗AI編碼工具之後,完成任務嘅時間實際上慢咗19%,但佢哋就覺得自己快咗20%,生產力錯覺勁到嚇死人。
Salt預測去到2027年,AI輔助編寫嘅代碼會超過企業代碼總量嘅一半,但同時警告治理機制完全追唔上採用速度,令唔安全嘅編碼習慣可以「飄」入正式環境都冇人知。