修完洞，還得問改壞了什麼
Trail of Bits 在 2026 年 10 月 21 日開源兩套外掛：patching-bugs（重現回報的 bug、開發修復並測試）與 regression-hunt（檢查變更是否破壞原本正確且受支援的行為）。工程師負責導引與審核結果；維護者可提供自己的安全假設與修補要求，讓 agent 依專案規則做事。
這兩套工具來自他們與 OpenAI 合作的 Patch the Planet：已為多個廣泛使用的開源專案共同撰寫數百個安全修補。動機之一是先前在 Scapy 等專案的經驗，以及對已合併修補與工程師數千次 Codex session 的分析。
先盤點：130 多個 PR 裡有 21 個回歸
他們回顧 Trail of Bits 工程師撰寫、維護者已合併上游的每一個修補，確認在 130 多個已合併 PR 中有 21 個回歸：16 個功能、1 個效能、4 個建置／測試；沒有破壞既有安全防護。
文中定義的「回歸」是：變更引入新缺陷，破壞先前正確且受支援、真實使用者或攻擊者可觸及的路徑。單次掃描在 58 個候選中找出這 21 個（約 36% 精確率），但不同 agent 跑法又會冒出更多要人工篩的候選。因此他們決定把「怎麼寫修補」與「怎麼查回歸」都標準化。
regression-hunt：約少 25% 誤報
regression-hunt 的流程是：沿 diff 追到真實介面列出候選、在線上部署重現、用全新上下文的 agent 重播 PoC，再裁定是否真的算回歸。它對「什麼不算回歸」也很嚴：誤報、修不完整、潛在舊 bug 等，都要有足夠證據才會上報。
用上述 21 個已確認回歸當評測集，對照基線（Codex agent 被提示「review the PR for regressions」），官方初步結果是：regression-hunt 的誤報約少 25%，95% 信賴區間為 14% 至 38%。代價是部分已知回歸被標成 borderline（有嫌疑但證據不夠）。這些數字是 Trail of Bits 自報的初步評估。
設計原則還包括：步驟模組化、嚴格輸入輸出 schema（主張、修訂、檢查、原始證據、未決問題），以及每個主張都要有對線上部署的 live PoC，否則結果視為不確定。
patching-bugs 與你可放進 repo 的兩份檔
patching-bugs 整理自數千次 Codex session 的實務，強調：
- 三臂證明：同一重現腳本要對「原版失敗、修補後通過、完整還原後再失敗」各跑一次，證明是修補本身生效。
- 依不變量修：修被違反的安全不變量，而不只修單一觸發路徑。
- 強制跑 regression-hunt：修補走同一套回歸管線。
外掛最吃專案知識。官方建議在 repo 放：
| 檔案 | 用途 |
|---|---|
THREAT_MODEL.md |
資產、信任邊界、存取控制、何謂漏洞／回歸、需要什麼證據 |
PATCHING_GUIDELINES.md（或 AGENTS.md） |
建置測試方式、修補大小與位置、如何呈現變更、回歸測試要證明什麼 |
本文建議：維護開源或內部服務的人，可先寫這兩份檔，再在下一個安全修補 PR 試 regression-hunt；把官方 25% 誤報數字當成廠商初步數據，用自己的 PR 集再驗證一次。
