RuleForge 論文閱讀分析：當 CVE 數量早就超過人工寫規則的速度，真正該自動化的不是摘要，而是 detection engineering 本身

論文基本資訊

• 論文標題：RuleForge: Automated Generation and Validation for Web Vulnerability Detection at Scale
• 作者：Ayush Garg、Sophia Hager、Jacob Montiel、Aditya Tiwari、Michael Gentile、Zach Reavis、David Magnotti、Wayne Fullen
• 年份：2026
• 來源：arXiv:2604.01977
• 論文連結：https://arxiv.org/abs/2604.01977
• DOI：10.48550/arXiv.2604.01977
• 主題：Detection Engineering、CVE、Web Security、LLM、Rule Generation、Threat Detection

如果最近一整串 sectools.tw 的主線，已經很密集地寫了 prompt injection、MCP、memory poisoning、runtime policy 與 agent control plane，那這篇 RuleForge 值得補進來的原因很直接：它把焦點拉回另一個其實更常卡住 production 團隊的問題——漏洞每天爆量新增，但能把漏洞描述翻成實際可部署偵測規則的人手，根本跟不上。

這篇 paper 講的不是「模型幫你摘要 CVE」這種表層自動化，而是更接近安全營運真正有價值的那一層：能不能把 CVE 與 exploit 特徵，自動轉成可上線的 HTTP detection rules，而且不是只生成，還會對自己生成的東西做驗證、回饋與修正。

我會把它的核心價值濃縮成一句話：真正缺的不是再多一個會讀公告的模型，而是把 rule generation、quality control、false-positive 壓制與 feedback loop 做成一條可持續跑的 detection pipeline。

這篇論文想解決什麼？

作者先點出一個很現實的背景：光是 2025 年，NVD 就新增了超過 48,000 個 CVE。這個數字背後最殘酷的地方，不是漏洞很多而已，而是：

• 威脅情報可以讀
• PoC 可以看
• 弱點可以理解
• 但真正能進 WAF / proxy / detection stack 的規則，還是得有人寫、有人驗、有人修

而這裡真正耗人的，不只是規則語法本身，而是整個 detection engineering 流程：

• 從 CVE 描述抓 exploitation signal
• 把 signal 轉成 HTTP request pattern
• 確認規則夠敏感，不會漏真正攻擊
• 確認規則也夠精確，不會把正常流量打成惡意

很多自動化論文只處理前兩步，RuleForge 比較值得看的地方，是它把後兩步也當成一級公民。這很重要，因為在 production 裡，會生規則不算本事，生了之後不把 SOC 打爆才算。

RuleForge 在做什麼？

作者把 RuleForge 定位成一個面向 CVE-related web threat detection 的自動化系統，輸入主要來自 Nuclei templates。這個設計其實很聰明。

因為相較於直接從鬆散自然語言公告開始做，Nuclei template 已經提供一層相對結構化的漏洞知識，包括：

• 漏洞目標與受影響元件
• HTTP method、path、payload 等 exploitation 線索
• matcher / extractor 類型條件
• 漏洞利用時常見的 request 特徵

換句話說，RuleForge 不是從零開始幻想規則，而是先站在一個比較像樣的結構化漏洞描述之上，再往 detection rule 推進。這讓它和很多「直接叫 LLM 寫規則」的做法差很多，因為後者很容易生成看起來合理、其實抓不到點的 pattern。

最值得記住的設計：不是單次生成，而是 5×5 generation + validation loop

RuleForge 最有味道的地方，不是它用了 LLM，而是它承認 一次生成通常不夠可靠，所以直接把流程設計成一條多候選、可迭代修正的閉環。

論文提到它採用 5×5 generation strategy：

• 先平行生成 5 個 candidate rules
• 每個 candidate 最多再做 5 次 refinement

這個設計背後其實很實務。因為 detection rule 不是那種只有一個標準答案的東西：同一個漏洞，可能有些規則抓 payload 字串、有些抓 URI pattern、有些抓 header / body 的組合，有些則靠多條件拼接把誤報降下來。平行多候選代表它不是在賭單次 prompt，而是在探索一小片候選空間；refinement 則代表系統會根據驗證結果修正，而不是把第一次輸出當聖旨。

真正關鍵的是 validation，不是 generation

我覺得整篇 paper 最值得留意的，不是 rule generation 本身，而是作者怎麼看驗證這件事。

RuleForge 引入了一個 LLM-as-a-judge confidence validation 機制，專門從兩個維度評估 candidate rules：

• sensitivity：避免 false negative，真的惡意請求要抓得到
• specificity：避免 false positive，正常請求不要亂打

這個切法很對。因為安全規則最怕的從來不是語法錯，而是：

• 規則寫太窄，攻擊直接漏掉
• 規則寫太寬，正常流量全被炸出告警

如果沒有明確把這兩條拉開，所謂的「自動生成」很容易只是在自動製造更多後續清理工作。RuleForge 至少有意識地把這件事放到 validation center，而不是只秀生成成功率。

關鍵結果怎麼看？

論文裡最值得記的幾個結果是：

• validation 模組在 production 上達到 AUROC 0.75
• 相較只靠 synthetic-test validation，false positives 降低 67%
• 整體規則品質會透過 continuous feedback loop 持續改善

這裡 0.75 AUROC 不是那種會讓人驚呼「超神」的數字，但它放在這個問題上其實夠務實。因為作者不是在做離線分類 benchmark，而是在處理一個很髒的工程問題：如何在規則真正進 production 前，對它的可用性建立比較可信的信心排序。

而我認為更重要的是那個 67% false-positive reduction。因為 detection engineering 的真正價值，不在於再多吐幾條 rule，而在於你有沒有讓 SOC 比較願意相信、比較敢上線、比較不用花額外人力替你擦屁股。

這篇論文真正點中的，是 detection engineering 的 bottleneck

很多人把資安 AI 想成兩條路：不是讓模型去找洞，就是讓模型去當 SOC analyst。但 RuleForge 比較有意思，因為它碰的是介於兩者之間、而且往往更缺人的層：

把已知漏洞知識 operationalize 成真正可部署的偵測規則。

這層工作不 glamorous，卻直接決定了：

• 新漏洞出來後，你多久能開始看見 exploitation 嘗試
• 你的防線是只停在看報告，還是真的開始有 detection coverage
• 規則品質是把威脅擋下來，還是把 analyst 一起拖垮

這也是為什麼我覺得 RuleForge 比很多只會說「LLM 可以協助安全」的 paper 更值得發。它不是只展示模型很聰明，而是在處理一個真實世界裡每天都在發生、又很難單靠人力 scale 的問題。

論文也沒有把事情講得太美

這篇另一個我比較喜歡的地方，是它沒有假裝「只要有 LLM 就能自動寫好規則」。從論文設計本身就看得出來，作者其實很清楚幾個現實：

• 模型會過度自信，所以需要額外 validation 與 confidence ranking
• 領域知識很重要，prompt 設計與品質審查都不能完全脫離專家
• human-in-the-loop 仍然必要，特別是在高風險規則上線前

這個態度我滿認同。資安裡真正有用的 AI，大多不是把人踢掉，而是把人的注意力從「全部都手工做」改成「只審最該審的地方」。如果一個系統可以先幫你產生候選、壓掉一大批明顯不好的規則，再把相對可信的那批送到人面前，那它就已經有很大的 operational value。

還有一個值得注意的延伸：從 structured source 走向 unstructured source

論文也提到 RuleForge 有往 unstructured data sources 延伸的能力，並展示一個 agentic workflow for multi-event-type detection 的 proof-of-concept。這點很關鍵。

因為今天很多漏洞知識最早不是以漂亮的 template 出現，而是散落在：

• 安全公告
• 研究文章
• PoC repo
• exploit write-up
• 威脅研究團隊的技術說明

如果 RuleForge 只吃結構化模板，它的價值會比較像內部效率工具；但如果它能逐步往 unstructured → structured → validated rule 這條鏈走，價值就會擴大成更完整的 threat-to-detection operationalization pipeline。這也是我覺得它很適合 sectools.tw 的原因：它其實連到了 CTI、漏洞情報、web 攻擊偵測與 detection engineering 這幾條線，而不只是單點 rule generation。

我怎麼看這篇論文？

如果把它和最近那些 agentic security 論文放在一起看，RuleForge 剛好補上另一塊缺角。最近大家很常談的是：怎麼防 agent 被帶偏；這篇則是在談：怎麼讓 AI 幫你把安全知識更快落到防線上，而且不把雜訊一起放大。

它沒有 prompt injection 論文那種戲劇張力，但我認為它更接近企業會真的掏預算導入的類型。因為它處理的是一條清楚、可量化、可接 production 的流程：

• 輸入：CVE / Nuclei template
• 輸出：可部署 detection rule
• 中間：多候選生成、validation、refinement、human review

這種 paper 的價值，常常不在於 headline 多誇張，而在於它把安全團隊每天都在做、但一直做不快的事情，真正抽成一條可被工程化的 pipeline。

限制與保留

• 聚焦的是 web vulnerability detection，不代表所有漏洞類型都能直接套用同一套 rule generation 思路。
• 輸入高度依賴 Nuclei 這種結構化來源，來源品質與 coverage 會直接影響下游規則品質。
• LLM-as-a-judge 並不是完美 validator，AUROC 0.75 已經說明它有幫助，但還遠不到可完全放手。
• production 誤報成本仍需場景化評估，不同環境、不同正常流量分布下，規則效果可能差很多。

一句話總結

RuleForge 真正值得看的，不是它又讓 LLM 自動生出幾條規則，而是它把「從漏洞知識到可部署偵測」這條最缺人、最容易失真、也最需要 quality control 的 detection engineering 流程，做成了一條會生成、會驗證、會修正的閉環。

---

本文由 AI 產生、整理與撰寫；內容僅供研究與技術分析參考，若需引用或用於正式決策，請務必回到原始論文與作者資料進一步確認。