Phoenix 論文閱讀分析：很多漏洞 AI 真正缺的，不是再多一點 code pattern，而是先把它到底該遵守什麼安全契約講清楚
論文基本資訊
- 論文標題：Security Is Relative: Training-Free Vulnerability Detection via Multi-Agent Behavioral Contract Synthesis
- 年份：2026
- 來源：arXiv:2604.19012
- 論文連結：https://arxiv.org/abs/2604.19012
- DOI：10.48550/arXiv.2604.19012
- 主題：AppSec、Vulnerability Detection、Multi-Agent Security、Behavioral Contracts、Gherkin、Secure Code Analysis
很多人看 LLM 做漏洞偵測時，第一個直覺還是：模型再大一點、資料再多一點、RAG 再厚一點，應該就會慢慢追上真正的 AppSec 分析能力。
但這篇 Phoenix 講得很不客氣：問題可能根本不是模型「知道得不夠多」，而是整個任務定義就錯了。
這篇最值得記住的主張，是漏洞不是 code syntax 的絕對屬性，而是相對於某個行為契約（behavioral contract）才成立的安全判斷。
我很喜歡這個 framing。因為它直接打在很多 LLM vuln detection paper 最常出問題的地方：它們一直想做的是全域分類器，問模型「這段 code 看起來像不像漏洞」；但真實世界常常更像是在問：這段 code 有沒有違反這個專案、這個 patch、這個執行邏輯本來應該遵守的安全要求？
這篇真正打到的痛點是什麼？
作者先回顧了一個現在很尷尬的現象：很多早期 benchmark 上看起來表現不錯的模型，一到更嚴格的資料切分就會直接崩掉。
論文點名 PrimeVul 的結果：以前在 legacy datasets 上 F1 > 0.68 的方法，到了嚴格去重與時間切分後，最低可以掉到 0.031。連在 Big-Vul 上看起來很能打的 7B 級模型，到 PrimeVul 上也可能直接接近亂猜。
作者把根因叫做 semantic ambiguity problem。這件事很關鍵，因為它不是在說模型不會看 code，而是在說：
- 同樣的 pattern，在不同專案脈絡下可能一個安全、一個危險
- 同樣的函式形狀，可能只因為 sanitizer、middleware、runtime contract 不同，安全性就完全相反
- 很多漏洞是否成立，根本不只看函式本體，而要看更外圍的行為承諾
論文甚至挖出 PrimeVul 裡的 Double Standard Problem：同一專案中，>99% 相似 的 code 可以在不同 CVE 脈絡下被貼上相反標籤。這其實是在提醒大家：你如果硬把 vulnerability detection 當成全域二元分類，模型天生就會被題目本身誤導。
Phoenix 怎麼改寫這個問題？
Phoenix 的想法不是再堆一層 debate agent，也不是單純做更厚的 retrieval，而是把整題重寫成三段式流程：
- Semantic Slicer：先把真正跟漏洞相關的最小上下文切出來
- Requirement Reverse Engineer：從 vulnerable / fixed pair 反推出一份 Gherkin behavioral specification
- Contract Judge：最後不是問「這段像不像漏洞」，而是問「它有沒有滿足這份契約」
這裡最聰明的地方，就是把開放式判斷轉成封閉式驗證。
也就是說，Phoenix 真正做的不是讓模型更會猜漏洞，而是先明文化「這段 code 應該做到什麼」，再讓模型去判斷它有沒有做到。
作者用的是 BDD / Gherkin 那套 Given / When / Then 結構。我覺得這招厲害，因為它不是單純把 prompt 寫得比較花，而是用一種結構化中介表示，把原本模糊的安全意圖釘成明確的驗證條件。
最值得記住的數字
這篇最有說服力的，不只是概念，而是它真的把結果拉開了：
- 在 PrimeVul Paired Test Set 上，Phoenix 最佳組合做到 F1 = 0.825
- Pair-Correct = 64.4%（275/427）
- 對照 RASM-Vul：F1 = 0.668、P-C = 21.4%
- 對照 VulTrial：F1 = 0.563、P-C = 18.6%
- 而 Phoenix 用的是 14B + 9B 級開源模型組合，不是 671B 級大模型
- 論文直接寫到這個 backbone 相比 DeepSeek-V3 最多小 48×
這組結果真正有意思的地方，不是只贏 leaderboard，而是它在證明一件事：
把問題問對，比把模型再堆大，可能更重要。
Gherkin 到底有多重要？
作者做了三層 ablation，我覺得這是全篇最漂亮的部分之一。
在沒有 behavioral contract 的情況下，Agent 3 直接看原始資訊做判斷，表現並不穩；但只要把 Gherkin specification 放進來，四種不同 judge model 的 F1 都明顯上升：
- Qwen3.5-9B：從 0.448 → 0.800，提升 +0.351
- Qwen2.5-Coder-14B：從 0.534 → 0.797，提升 +0.263
- Qwen2.5-Coder-7B：從 0.558 → 0.760，提升 +0.203
- Gemma-3-12B：從 0.643 → 0.736，提升 +0.092
這段結果很重要，因為它把「也許只是 prompt engineering」這種質疑壓回去。這裡看到的不是單一模型幸運吃到某種 wording，而是：
- 跨模型都漲
- 而且 RAW → Blind 的提升有限
- 真正把分數拉開的，是 Blind → Feature 這段，也就是 behavioral contract 本身
換句話說，Phoenix 的增益不是因為 agent 比較多，而是因為它真的把安全判斷變成一個比較可驗證的問題。
它甚至連「小模型也能打」這件事都講得很完整
作者還有一個很漂亮的觀察：沒有 contract 時比較弱的模型，反而最吃這種結構化支架。
例如 Qwen3.5-9B 的 RAW baseline 最低，但加上 Gherkin 後漲幅最大。這很像在說：很多所謂「模型不夠聰明」的問題，其實有一部分是因為它被迫同時做太多事——理解 code、找出關鍵安全條件、再自己決定哪一個條件才是真正該驗的。
Phoenix 把這些步驟拆開後，小模型也能在比較窄、比較清楚的上下文裡做出像樣的判斷。這點對實務很重要，因為它意味著：
- 不一定要把 vuln detection 綁死在超大閉源模型上
- 更小、更便宜、可自控的模型，只要流程設計對，也有機會打到很高的 precision / recall 水準
我很喜歡它對 false positive 的解讀
這篇另一個很值得看的是 error analysis。作者不是只說「我們有 FP / FN」，而是去看這些錯到底在講什麼。
他們發現 Phoenix 最佳配置有 97 個 false positives，但其中 18%（17/97） 其實指出了 developer patch 之後仍然存在的真安全疑慮。
論文舉的一個例子很有代表性：某個 QEMU case 裡，所謂的 fixed code 旁邊甚至有開發者自己留下的 TODO，直接承認還沒補齊那個 buffer 檢查。也就是說，Phoenix 並不是單純亂報，而是它依照 behavioral contract 做了比原 patch 更嚴格的審查。
這個結果很有意思，因為它暗示 Phoenix 有時候不是在「錯判」，而是在暴露 benchmark 標籤本身對安全的定義不夠嚴格。
這對 AppSec 很有價值。因為在真實世界裡，很多 patch 其實只是修掉這次 CVE 的最短路徑，並不代表整個安全契約真的被滿足。
但它也不是魔法
這篇沒有把自己吹成已解決漏洞偵測，這點我反而買單。
作者明講 false negative 主要來自四類問題：
- specification 不完整
- 只看到表面邊界檢查，沒看出邏輯其實是空的
- 部分條件符合就被模型錯當成整體符合
- 架構層級 blind spots
他們甚至指出，在 73% 的 FN 裡，Agent 3 會很有自信地說 vulnerable code 其實滿足 spec。這種錯誤很像很多 LLM code analysis 常見的問題：它會檢查「有沒有某種安全樣子」，但不一定真的理解那個安全條件在語義上是不是成立。
所以 Phoenix 很強，但還不是 autonomous AppSec 的終點。比較合理的定位是：它把任務 formulation 往正確方向推了一大步。
這篇為什麼對 AppSec 團隊特別有啟發？
因為它提醒我們，很多安全分析失敗，不一定是工具沒看到 pattern，而是根本沒有把「該驗什麼」表達成清楚的 contract。
這件事對幾條實務線都很有啟發：
- AI code review：不要只問模型「有沒有漏洞」，要問它「違反了哪個行為契約」
- secure SDLC：如果團隊能把 security requirements 更結構化，後面的自動化分析品質會一起提升
- benchmark 設計：真正該量的，不只是分類正確率，還包括模型能不能抓住 patch 背後的 security intent
- agentic AppSec：multi-agent 的價值不在於大家吵一輪，而在於有沒有一個足夠硬的中介表示把判斷標準鎖住
如果你最近在看一堆 agentic vulnerability detection paper，Phoenix 很值得放進來對照。因為它沒有停在「多代理比較會辯論」，而是往前再走一步，問：如果辯論的題目本身就含糊，那再會辯也只是把模糊放大。
我怎麼看這篇？
如果要濃縮成一句話，我會這樣講：
很多漏洞 AI 真正卡住的，不是它不夠會看 code，而是它沒有被給到一份足夠清楚、足夠可驗證的安全契約。
我覺得這篇最有價值的，不只是又多了一個 F1 0.8+ 的系統，而是它把 vulnerability detection 從「大模型安全直覺測驗」拉回成一個更工程化的 contract verification 問題。這個方向比單純再換更大 backbone 更值得追。
總結
Security Is Relative: Training-Free Vulnerability Detection via Multi-Agent Behavioral Contract Synthesis 這篇論文真正重要的地方，不只是提出 Phoenix 這個三段式 agent pipeline，而是把漏洞偵測的核心難題重新定義成 context-specific behavioral contract verification。
在 PrimeVul Paired 上，Phoenix 用 14B + 9B 的開源模型組合做到 F1 = 0.825、Pair-Correct = 64.4%，明顯超過 RASM-Vul 與 VulTrial；更關鍵的是，ablation 顯示真正把結果拉開的不是 agent 數量本身，而是那份把安全意圖寫清楚的 Gherkin behavioral specification。
真正值得帶走的結論是：在 AppSec 裡，很多判斷之所以一直不穩，不是因為模型不知道答案，而是因為我們連題目都還沒定義得夠精確；先把安全契約寫清楚，才有資格談自動化驗證。
免責聲明
本文由 AI 產生、整理與撰寫。 內容主要依據公開論文、arXiv 頁面與可取得之研究資料進行彙整、解讀與摘要。儘管已盡力確保內容之完整性與可讀性，仍可能因模型理解限制、資料來源差異或語意轉譯過程而存在疏漏、不精確或更新延遲之處。本文內容僅供研究交流與知識分享參考，實際技術細節、實驗設定與最終結論，仍應以原始論文、官方文件及作者公開資料為準。