AI 安全與評測
LLM 漏洞驗證產物重跑後，30 個案例僅 10 個通過修補版本反證
一項預先註冊的重現性稽核發現，能執行並觸發崩潰的漏洞 PoC，不一定真的重現指定 CVE。受查的 30 個案例中有 20 個在修補版本仍觸發相同訊號，顯示代理安全基準需要比字串與退出碼更嚴格的判定器。
新研究把 LLM／代理產生的漏洞驗證產物拆成四個層級：公開可取得、可以執行、產生候選訊號，以及在語義上確認重現指定漏洞。研究者先從 2023 至 2026 年的 104 篇論文建立共識語料，其中只有 59 篇具有可公開存取的主要產物；再抽取 18 篇重跑完整工作流程。乾淨環境下僅 10 篇成功，安裝既有相依套件等環境修補後也只增至 11 篇。
更值得注意的是對一套含 102 個 CVE 案例的基準進行逐案稽核。58 個案例的執行腳本內部 CVE 編號與目錄宣稱的目標不同。對產生訊號的案例，研究者不只查看崩潰、狀態碼或成功標記，還加入三項檢查：訊號是否符合 CVE 的實際後置條件、良性輸入是否不會觸發，以及相同 PoC 在已修補版本上是否失效。
結果顯示，接受修補版本測試並能得出判定的 30 例中，只有 10 例訊號消失，另外 20 例仍照樣觸發；19 個加入匹配負對照的案例則有 7 個出現誤報。把條件合併成最嚴格的 E1 證據後，訊號案例中只有兩例獲得完整確認。論文以 CVE-2020-1967 說明問題：測試直接把空值交給 `SSL_check_chain`，因此連 NVD 所列已修補的 OpenSSL 1.1.1g 也會崩潰，並未重現真正涉及 TLS 1.3 擴充欄位的漏洞路徑。
對建立資安代理評測的人而言，工程重點是把「脆弱版觸發、修補版不觸發、良性輸入不觸發」寫成成對測試，並凍結映像、依賴與判定條件。現有數字仍屬探索性結果：案例級分析主要集中於單一基準，負對照及修補反證尚未覆蓋全部訊號案例，而且 Docker 資源與網路限制可能影響可執行率。後續能否在更多獨立基準重現相同誤報比例，才決定問題的普遍程度。