最近看 LLM 寫程式的安全性研究，我最在意的不是模型分數，而是資料從哪裡來。受控 benchmark 能量到模型在指定題目下的傾向，卻很難回答一個更麻煩的問題：開發者把 AI 產生的 code merge 進 production repository 後，漏洞長什麼樣子？

這篇 arXiv 論文做的事情很樸素，卻很重要。它從 226 個 repository 中挖出帶有明確 AI 歸因訊號的 C/C++ commit，共 21,430 個不重複函式，1,540 個被標為有漏洞，涵蓋 17 類 CWE。標記不是只跑一個 scanner 就結案，而是結合 Semgrep、Flawfinder、pattern matching，再做人類驗證，標註者一致性 Cohen's kappa 是 0.79。嚴格來說，這還不是 ground truth，但至少比把合成程式當成真實開發流程更接近問題本身。

我認為這個資料集真正改變的，是研究問題的單位。以前我們常問「模型會不會生成不安全的函式」；現在可以進一步問「哪些脆弱性會穿過 prompt、review、測試與 merge，最後留在 repo 裡」。兩者差非常多。能被 commit 的 code 已經受過人類選擇，它可能修掉了明顯錯誤，也可能因為看起來合理而讓更隱晦的 buffer、memory management 或 input validation 問題存活。把這層 selection bias 納入，才比較能研究 AI 輔助開發的實際風險。

對工具設計來說，我不會把結果解讀成「AI 寫 C/C++ 很危險」這種沒資訊量的結論。更有用的方向是把安全檢查移到生成與採納之間：針對高風險 CWE 做 context-aware 的 static analysis，要求模型解釋資源生命週期與輸入邊界，並把 review 的注意力放在容易被可讀性掩蓋的路徑。模型擅長補全局部模式，安全缺陷卻常出現在跨函式、跨模組的假設沒有對齊。

當然，資料集也有邊界。AI 歸因只能抓到明確留下訊號的 commit，代表性未必完整；static analysis 會漏報，也會有需要人工判斷的誤報。因此它比較適合當作研究與工具評估的起點，而不是宣告真實漏洞率。可是這正是我想看到的轉向：少一點乾淨的玩具題，多一點真正進過版本控制系統、帶著人類決策痕跡的資料。安全研究若要跟上 AI coding，資料分布先得跟真實世界接上。