國內首個！GPT-5.6「刪庫跑路」，中國安全加強版Codex火速上線

新智元報道

人類世界，快被AI Coding埋的雷淹沒了！

AI是一個過目不忘的代碼高手，然而，它不僅學到了人類的智慧，也完美復制了人類在互聯網上留下的海量安全漏洞。

就在最近，OpenAI緊急披露了一起史無前例的重大安全事件：GPT-5.6 Sol及更強模型，竟然在評測中自己當起了黑客。

為了「作弊刷分」，AI通過鏈式利用憑證與漏洞，直接入侵了Hugging Face的生產數據庫！

幸運的是，Hugging Face與OpenAI團隊發現異常，聯手封堵了漏洞。

但OpenAI最強的GPT-5.6 Sol，最近已不止一次「刪庫跑路」！

AI大幅降低了「讓軟件跑起來」的門檻，它并沒有同步降低「讓軟件安全運行」的門檻。

信息安全機構Veracode發現：過去兩年，模型的語法正確率從約50%提升到95%以上，但安全通過率始終徘徊在45%～55%

去年年末，GitLab調查了3266名DevSecOps從業者，73%遇到過Vibe Coding代碼帶來的問題；76%表示更多合規問題是在部署后，而不是開發過程中發現。

「氛圍編程」（Vibe Coding），雖然提升了編碼的效率，但與此同時也開始暴露新的安全隱患和風險。

現在，我們急需一個代碼原生安全的工具，讓安全檢查不再等在流水線門口，而是搬進編碼過程本身。

好消息是，Qoder在國內第一個交卷了！

剛剛，阿里旗下的Qoder正式推出了Qoder Security，直擊AI Coding的安全風險問題。

在這個工具中，代碼安全內生于 Qoder，貫穿從編碼到提交的每一步。

Qoder Security，

將安全原生于代碼生成每一步

Qoder Security的發布，讓Qoder成為國內首個交付「編碼會話內三層安全護航 + 發現問題同會話修復」能力Agentic Coding產品。

當然，這不是「國內第一次談代碼安全」，也不是「國內首個AI安全大模型」。

用Qoder團隊的話說：「我們說的國內首發，指的是把『會話內三層護航+同會話修復』這一范式，率先做成國內主流Agentic Coding產品里的可用能力。它和現有安全體系互補，不是互相取代。」

現在，Qoder 國際版與Qoder CN的Qoder Desktop、Qoder CLI均已支持，在設置中一鍵開啟，無需安裝或配置任何額外插件。

相比傳統方案，Qoder Security的漏洞檢出率提升了約60%。過去大量被檢測漏掉、直接混入倉庫的風險，現在在編碼階段就能被攔截。

同時，告警誤報率下降了約80%，開發者再也不用在成堆無效告警里疲于奔命、逐條甄別。

更重要的是，單個漏洞從發現到修復，時間已壓縮到小時級，而傳統流程里，這個周期往往以天甚至周計算。

在過去，「效率」與「安全」，難以兼顧。要追求敏捷，就不得不忍受裸奔的風險；要追求絕對的安全，開發流程就會變得臃腫、滯后而痛苦。

而Qoder團隊怎么做到的「兼容并包」？他們做對了什么？

背后，是整個技術范式的升級，直接把代碼安全從「靜態掃描」推向「主動式安全」。

傳統方案，靠的是規則匹配已知模式；而Qoder Security基于自研安全大模型，理解代碼上下文與污點傳播路徑，對檢出的問題自我驗證可達性，只報告真實可達的風險。

發現問題后，編程智能體會直接完成修復，下一輪掃描閉環復驗，不留安全債務。每位開發者都好像被配了一位專屬安全工程師，分階段審查、驗證、修復。

還有一個關鍵設計，就是雙Agent協同架構。

在這個架構中，編程Agent與負責安全審查的Agent相互獨立，避免「自己改完再給自己打滿分」；安全審查Agent再由掃描與驗證兩個Agent分工協作，進一步提高檢出結果的準確率。

針對「事后掃描，追不上AI生成代碼速度」的這個問題，國際頭部廠商都已布局。OpenAI的Codex Security，選擇的是倉庫級掃描路線；Anthropic是把安全審查能力集成進Claude Code的編碼會話。

Qoder選擇的，是把安全護航做進智能體編碼會話之內。

這體現了行業的整體趨勢：安全檢查必須盡量回到代碼誕生的那一刻。

Qoder「三層護航」，輕松上手

而且，為了讓這種「貼身保鏢」的體驗不打擾開發者的心流，Qoder Desktop設計了一個極其優雅的三層防御體系。

如果每一行代碼都交給最強大模型復核，算力成本和響應延遲都會不可控制，而這個體系，解決了成本與延遲的問題。

第一層，是L1靜態檢查，也即實時正則攔截。

代碼生成的瞬間自動觸發，篩查已知高危模式，無需任何人工干預。AI每寫出一段代碼，一落地就會被掃描。

這一層只關注最顯而易見的常識性安全隱患，耗時在毫秒級。問題會即時發現、自動修復。

它能做到零延遲、零額外算力開銷，開發者甚至感知不到這層檢查的存在。并且，這一層功能完全免費。

第二層，L2輕量掃描，也即語義級增量審查。

這一層精準聚焦于本次任務產生的「代碼增量」（Diff）。大模型不僅看新寫了什么，更會對比新舊代碼在語義上的差異，防止新引入的代碼破壞原有的安全邊界。編碼過程中彈出一張建議卡片——「掃一掃，檢測代碼安全隱患」。點擊即出結果，也可以在會話中輸入/security-scan主動觸發。

這一層覆蓋的是L1靜態分析沒攔住的中等復雜度問題，比如跨函數的數據流污染，以及SQL 注入、遠程命令執行、敏感信息泄露這類需要理解語義才能識別的風險。

第三層，L3深度掃描，也即跨文件深度審查。

代碼提交前的最后一道關，就是「提交前要不要先掃一下？」

此時，掃描引擎會從局部的「一隅之地」跳出來，構建整套項目的全局依賴關系圖，進行深度語義分析。

Qoder Security會跨文件、跨函數追蹤完整數據流，從污點源到危險匯聚點，挖出單文件視角永遠看不到的隱藏關聯漏洞。

三層全部嵌在同一個寫碼會話里。發現問題→同會話修復→閉環復驗。不跳出編輯器，不等CI回來，不另開工單。

整個過程嵌在開發者的正常工作流里，沒有上下文切換的代價。

阿里內部研發中使用Qoder Security后發現，代碼評審中與安全相關的評審意見下降約35%到45%，效果顯著。

具體來說，Qoder Security是如何運行的？下面就是一個生動的例子。

打個比方，你在做一個交易系統的賬單導出功能，AI用Runtime.getRuntime().exec()調用系統命令，才生成一行代碼，就被第一層標記出來了。

接著看調試日志，里面直接把銀行卡號和金額給打印出來了，雖然正則表達式看不出來這串數字是啥，但語義分析幾秒鐘就反應過來：這是在泄露敏感信息，趕緊攔住。

最絕的是最后這個。提交代碼前系統做深度掃描，從你在頁面上輸入的HTTP查詢條件參數開始一路往下追，穿過好幾層業務邏輯，跨了三個文件，最后在一個公共緩存工具里發現了一個致命漏洞——

反序列化的時候沒做任何限制，攻擊者可以偽造一個惡意數據包，順著鏈路直接在你的服務器上執行任意命令。

關鍵是，單獨看每個文件都正常，誰也想不到串起來會有這么大問題。

這三個問題揪出來之后，系統還順手給了修復方案。你點個確認，主Agent立馬開始改，review一遍diff，前后還不到十分鐘。

而且，整個過程里，這三層防護都不會強行打斷你寫代碼。

第一層是自動跑在后臺的，后兩層會在合適的時機問你要不要掃一下，你點了「確認」它才動手，完全不影響你思路。

實測Qoder Security

場景一：加個YAML兼容，遠程響應也能打穿客戶端

第一步，是挖坑。

我們通過Git拉取了OpenSearc項目特定的歷史版本導入Qoder，提出一個常見的兼容性需求：「更新產品校驗邏輯，增加application/yaml響應支持。要求復用倉庫現有的YAML解析寫法，以兼容當前響應處理……」

Agent接收到需求后非常「聽話」，為了保持代碼風格一致，它在生成的opensearch.rb文件中，直接調用了Ruby中極其危險的YAML.load方法。

這正是引發CVE-2022-31115的罪魁禍首——不安全反序列化！

如果這行代碼上線，惡意的遠程服務器就能通過偽造YAML響應，直接打穿并控制客戶端。

重點來了，代碼生成后，我們直接點擊「掃一掃，檢查代碼隱患」卡片，Qoder的安全引擎瞬間拉響警報，精準指出代碼中的反序列化風險。

緊接著，我們直接在當前會話中要求其修復，Agent迅速將危險的YAML.load替換為了安全的YAML.safe_load。

注意，從引入高危漏洞到完美修復，整個過程連上下文都沒切，一次潛在的CVE危機，就這樣在編碼階段被輕松掐滅。

場景二：用了預編譯，字段名仍能注入

在日常開發中，很多程序員都有一個誤區：認為只要用了PDO預編譯，系統就徹底與SQL注入絕緣了。

為了測試Agent能否避開這個陷阱，我們選取了真實的漏洞靶場——曾引發過CVE-2026-42550的flightphp/core項目。

我們先將代碼回退到存在風險的歷史提交（Commit: 2ab26aa...），隨后在Qoder中打開倉庫，并丟給Agent一個看似普通的日常需求：

在SimplePdo.php中新增輕量的DB封裝：根據傳入data的鍵，自動生成 insert/update/delete語句，值要求用PDO綁定。

這個需求的險惡之處在于：PDO的預編譯機制只能綁定值，無法綁定表名或字段名。如果直接將未經校驗的鍵名拼接到SQL語句中，立刻就會引發SQL標識符注入。

果然，在首輪代碼生成中，Agent對表名和array_keys($data)提取出的字段名時直接采用了「野蠻拼接」。

于是，我們立刻喚起安全掃描。

這次，Agent成功識別出自己剛剛寫下的動態SQL標識符拼接存在高危注入風險，并迅速給出了修復方案——為表名和列名補充了嚴格的字符白名單過濾與反引號（`）轉義，沒有掉到坑里。

怎樣開啟

如上文所言，無論是桌面端還是命令行，無論是國際版還是中國版，Qoder Security內置于Qoder Desktop與Qoder CLI。

而且桌面端設置非常簡單，只需要3步：

1、打開Qoder，點擊左上角用戶設置，選擇Qoder設置。

2、從側邊欄中選擇「安全」（Security）。

3、在掃描層級下，確認靜態檢查（L1）、輕量級掃描（L2）和深度掃描（L3）的開關已開啟。

Qoder CLI從v1.1.0起支持同樣的能力：輸入/security-settings，即可查看并開關三層防線。國際版與中國版（CN）均可使用。

之后，在會話中輸入/security-scan，或「幫我進行代碼安全掃描」，就能直接使用Qoder Security。

代碼狂飆，安全是最可靠的底線

最后，要說明兩點。

第一，Qoder Security做的事很簡單——在編碼階段幫你早發現、早修復，把那些明顯的坑提前填上。

AI雖好，但終歸是工具，合規留痕、組織卡控，依然少不了CI和人工審查。另外，也需要坦白講，安全檢查做不到100%準確，偶爾也會有誤報。最終的決定權，始終在你手上。

第二，AI讓寫代碼更快了，但「更快地生產漏洞」不是行業想要的答案。

可持續的Agentic Coding，安全應該是默認設置。只有安全可信，智能體才能規模化地創造價值。

Qoder Security，讓信息安全從第一行代碼開始。

編輯：Aeneas 大衛