Broken by Default 論文閱讀分析：很多 AI coding 真正危險的，不是它偶爾寫壞，而是它常把能跑和可被打爆一起交給你
論文基本資訊
- 論文標題：Broken by Default: A Formal Verification Study of Security Vulnerabilities in AI-Generated Code
- 作者：Dominik Blain、Maxime Noiseux
- 年份：2026
- 來源：arXiv:2604.05292v2
- 論文連結：https://arxiv.org/abs/2604.05292
- DOI：10.48550/arXiv.2604.05292
- 主題：AI Coding Security、Formal Verification、Secure Code Generation、Z3 SMT、AppSec Evaluation、CWE Benchmark
很多人現在已經不再問「AI 會不會寫程式」，而是直接把它丟進 production workflow。真正該問的其實是另一句更難聽、也更重要的話：它寫出來的 code，到底有多常是可以被真的打爆的？
這篇 Broken by Default 值得看，不是因為它又做了一個「模型寫 code 安不安全」排行榜，而是它刻意把問題從 pattern matching 拉到 formal exploitability。作者不是只看 suspicious API、危險字串或 lint rule，而是把 3,500 份由七個主流 LLM 產生的程式碼丟進 COBALT + Z3 SMT solver，要求系統產出數學上可滿足的 witness，直接證明某些漏洞條件真的成立。
換句話說，這篇在問的不是「這看起來像不安全」，而是：
這段 AI 產生的程式，能不能被形式化地證明存在可利用漏洞？
這篇論文真正補的缺口是什麼？
近兩年 AI coding 的安全討論很多，但常有一個根本問題：大家其實常在量「像不像漏洞」，不是「這個漏洞條件到底能不能被證成」。靜態規則、pattern-based benchmark、人工 spot check 當然有價值，但只要你想把這件事拉進工程決策，就會卡在 ground truth 不夠硬。
Broken by Default 的切入點很直接：
- 選 500 個 security-critical prompts
- 橫跨 5 個 CWE 類別，每類 100 題
- 讓 7 個 widely deployed LLM 各自產出完整程式
- 總計分析 3,500 份 code artifacts
- 再用 Z3 satisfiability witness 來證明漏洞條件
它真正想補的，不是再多一個分數，而是把 AI code security evaluation 從「主觀覺得危險」往前推到「可形式驗證、可複現、可拿來反駁產品錯覺」的層次。
資料集與任務設計很務實
作者不是用惡意 jailbreak prompt 故意陷害模型，而是選了更接近日常開發、但又明顯屬於安全敏感區域的 prompt。五類任務包括：
- MEM：buffer allocation、array indexing、dynamic memory management
- INT：整數溢位、型別轉換、signed/unsigned arithmetic
- AUTH：密碼雜湊、token generation、session handling
- CRYPTO：金鑰生成、亂數使用、cipher selection
- INP：SQL、path、shell command composition
這個設計的價值在於，它不是在測模型「會不會幫攻擊者寫 exploit」，而是在測另一件更貼近日常軟體開發的風險：
當一個正常工程師請模型幫忙生出看起來可用的功能碼時，模型有多常順手把漏洞一起包進去？
核心方法：不是找 pattern，而是找 witness
這篇最值得記住的技術點，是 COBALT analysis pipeline 的 framing。它把分析拆成三步：
- CWE pattern extraction：先用 regex / AST-level patterns 找候選漏洞點
- Z3 SMT encoding：把漏洞條件編碼成 SMT 問題
- witness extraction：若 Z3 回 SAT，就抽出具體可觸發的輸入見證
這樣做的意義非常大。因為一旦 Z3 給出 satisfiable witness，它就不再只是「你可能哪裡怪怪的」，而是：
這裡存在一組輸入，會把你剛剛那段 AI 產生的 code 真的推進漏洞條件裡。
作者還選了七個代表性案例做 runtime validation，其中六個能在 GCC AddressSanitizer 下實際 crash。這讓整篇 paper 的可信度高很多，因為它不是只停在 solver 世界裡自我感覺良好。
最該記住的數字
這篇最刺眼的結論其實很簡單，而且很難替模型找藉口：
- 全模型平均 55.8% 的輸出含有至少一個 COBALT 識別漏洞
- 其中 1,055 個 findings 被 Z3 形式化證明
- GPT-4o 漏洞率最高，達 62.4%，作者直接給 F
- Gemini 2.5 Flash 最好，但也仍有 48.4%，只到 D
- 沒有任何模型高於 D
這裡最狠的地方不是誰第一誰最後，而是整條曲線都很爛。沒有哪個模型能讓你放心說「這個可以先 trust by default」。
論文還指出，整數算術類任務平均漏洞率最高，達 87%；記憶體相關任務平均也有 67%。這很符合現場直覺：模型在這些地方最容易交出「功能看似合理、實際上邊界條件全炸掉」的程式。
三個輔助實驗比主表還更值得管理者看
1. 安全提示詞幫助有限
作者做了 secure prompt ablation。結果是：即使你明講要安全、要避免漏洞，平均漏洞率也只下降 4 個百分點。這代表很多團隊目前最愛的做法——在 system prompt 多塞幾句 secure coding instruction——其實更像心理安慰，而不是可靠控制。
2. 傳統工具大量漏報
作者把六套業界工具一起拿來比，結論是它們合起來只標出 7.6% 的 artifacts，對於 Z3 已證明的 findings，竟然漏掉 97.8%
這不是在說 SAST 沒用，而是在提醒一件很重要的事：很多 AI 生成漏洞的形狀，不一定正好長成現有規則庫最擅長抓的樣子。 如果團隊把「CI 跑綠」誤認成「AI 產生的 code 應該安全」，那個信心很可能是假的。
3. 模型知道自己寫得爛，但還是照樣寫
最有意思的一組結果，是 generation-review asymmetry。模型在 review mode 下，能辨認自己輸出的已證實漏洞，命中率達 78.7%；但在 generation mode，它們還是平均產出 55.8% 的漏洞率。
這透露出的不是單純「模型不懂安全」，而是：
很多安全失敗更像生成階段的預設偏好問題，而不是知識不存在。
也就是說，模型可能知道比較安全的寫法，也可能看得出自己哪裡有洞，但預設產生答案時，它仍然常把方便、常見、短平快的程式樣板放在前面。
這篇論文真正打到的是哪種錯覺？
我覺得這篇最有價值的地方，是它直接打掉一種近年很常見的工程錯覺：
只要模型看起來很會寫、回答很順、review 時也能講幾句安全大道理，就代表它產出的 code 大致可信。
Broken by Default 的答案剛好反過來。它告訴你：模型很可能同時具備「看起來很像會寫」與「預設常常照樣寫出可被形式證明有漏洞的東西」這兩種特性。
這也是為什麼我會覺得它跟近期很多「AI coding 很強 / 很危險」的敘事不同。它不是靠情緒嚇人，而是把 exploitability ground truth 釘下來，逼大家承認：問題不是感覺，而是比例已經高到不能再裝沒看見。
對實務最重要的幾個啟示
1. AI coding 不能被當成 secure-by-default 的 junior dev
如果平均超過半數輸出都有漏洞風險，那模型在安全敏感任務上就不能被視為「先寫、review 再說」的低風險助手。它比較像一個產能很高、但邊界感很差的實習生——你可以用，但不能先信。
2. Prompt hardening 不是主防線
安全提示詞只有 4 個百分點的改善，表示真正有價值的控制點仍然得放在：
- 更強的 post-generation verification
- task scoping
- language / framework guardrails
- high-risk code path 的人工 review
- formal methods 或至少更有語義的安全驗證
3. Review mode 與 generation mode 要拆開設計
既然模型「會看不代表會先做好」，那工程上更合理的方向可能不是單輪生成，而是把流程拆成：
- 一個專門生成
- 一個專門以不同目標函數做 adversarial review
- 必要時再接 formal / symbolic checker
4. AppSec 需要面對 AI-generated vulnerability 的新分布
如果傳統工具大量 miss 這些 findings，那團隊不能只期待把既有 SAST/DAST 套件接回 AI workflow 就算完成治理。AI 產生的 code 可能帶來一種功能看似完整、樣板看似正常、但在邊界條件與隱性約束上特別脆弱的新漏洞分布。
這篇也有侷限，但不影響主結論
當然，這篇不是終局答案。
- 它用的是特定 500 prompts，而不是所有開發場景
- 正式驗證聚焦的漏洞類型仍有限，不是所有安全問題都能這樣 SMT 化
- 模型版本與 API 行為會隨時間變動
- 七個模型雖主流，但不代表完整市場
但這些侷限不會推翻它最重要的訊號：在安全敏感 coding 任務裡，主流模型預設產生可被形式驗證漏洞的比例，高得離譜。
我怎麼看這篇？
如果要把這篇濃縮成一句話，我會這樣講：
很多 AI coding 真正危險的，不是它偶爾寫出怪 code，而是它把「能跑」和「可被打爆」一起包成一份看起來很像能 merge 的答案。
這篇很適合接在我們最近一路在寫的 AI coding / runtime security / AppSec evaluation 主線後面。因為它不是再講抽象風險，而是把「AI 生成程式碼的 exploitability」直接變成可以量、可以比、可以證的東西。
對 sectools.tw 的讀者來說，這篇最值得帶走的不是哪個模型比較丟臉，而是：如果你的團隊已經讓 AI 幫忙寫安全敏感程式，驗證流程就不能再停在 lint、單元測試和表面 review。 否則你得到的很可能不是開發加速，而是漏洞產線。
總結
Broken by Default 是一篇很有殺傷力的 AI coding 安全論文。它用 3,500 份 artifacts、500 個安全敏感 prompts、七個主流模型，以及 Z3 SMT witness 這種很硬的驗證方式，證明了一件不太舒服但很現實的事：目前主流 AI coding assistants 在安全敏感任務上，並沒有達到可以預設信任的水位。
如果你在做 AppSec、secure SDLC、AI coding governance、developer enablement 或 code review policy，這篇都值得讀。因為它提醒我們：真正該被治理的，不只是模型會不會寫，而是它在你最想偷快的那一刻，到底有多常幫你把漏洞也一起生出來。
免責聲明
本文由 AI 產生、整理與撰寫。 內容主要依據公開論文、arXiv 頁面與可取得之研究資料進行彙整、解讀與摘要。儘管已盡力確保內容之完整性與可讀性，仍可能因模型理解限制、資料來源差異或語意轉譯過程而存在疏漏、不精確或更新延遲之處。本文內容僅供研究交流與知識分享參考，實際技術細節、實驗設定與最終結論，仍應以原始論文、官方文件及作者公開資料為準。