VICBench 追溯100個漏洞的首次引入提交，現有自動方法最高僅40.1% F1

安全工具通常知道哪個提交修補漏洞，卻不一定能找出漏洞最初何時進入程式庫。8 月12日提交的 [VICBench](https://arxiv.org/abs/2608.12246) 公開100個已驗證的 vulnerability-inducing commits（VIC），對應100個CVE、88個開源專案、Python、Java及C++三種語言與48類CWE；資料已存放於 [Zenodo](https://zenodo.org/records/18944736)。

這個問題不只是考古。首次引入提交決定哪些版本實際受影響，也讓偵測器能在漏洞尚未被後續重構改寫前接受測試。VICBench 的修補提交平均改動38.6行，真正的漏洞引入提交平均涉及252.5行，遠超只追蹤少量刪除行的傳統資料集。論文示例中，一段接受未簽章身分權杖的程式在2018年跨檔案搬移；只依賴 `git blame` 的方法停在重構點，漏掉2016年的真正起源，因而少算約兩年受影響版本。

標註流程由一名具九年程式經驗的作者與VIC‑Agent獨立追溯。兩者在71個案例找到完全相同的提交，Cohen’s κ為0.707；其餘29例再由第二名人工審查，最終資料另抽11例交由具16年經驗的資安工程師確認。VIC‑Agent會結合CVE語意、`git blame`、`git log -S`與提交驗證，辨別新增漏洞、搬移及純重構。

基線結果顯示，V‑SZZ在40個Java／C++案例只有33.3% F1，LLM4SZZ在全部100例為40.1%。VIC‑Agent雖達89.3%，但它參與了資料建構，不能視為獨立測試成績。資料也只有8個C++案例，不含JavaScript、Go或Rust，且假設每個CVE有一個主要引入提交。工程團隊可用它重測AI程式審查與版本範圍推斷，但下一步仍需盲測、更多語言及多提交因果標註，並與 [NVD](https://nvd.nist.gov/) 的版本資料交叉核對。