AI 幫人找漏洞，開源維護者快撐不住了
最近看到 curl 的作者 Daniel 寫了一篇文章，講 AI-assisted 安全回報讓他的工作量直接爆了。
先說結論：report 數量是 2024 年的 4-5 倍、2025 年的 2 倍。平均每天超過一份安全回報，而且品質比以前高很多，都是超詳細的分析報告。
他花了幾乎整天在處理 HackerOne 上的清單，核實漏洞、寫 patch、寫 advisory、跟研究者溝通。2026 年上半年還沒過完，已經確認了 12 個漏洞，預計全年 CVE 數量是以往的兩倍以上。
他老婆開口說他工時太長了。這是他做 curl 快三十年第一次聽到這句話。
我在想這背後發生了什麼。
AI 工具讓安全研究這件事門檻降低，以前要花幾天手動 trace code 的流程，現在大概幾小時就能跑一遍。這代表什麼？高品質的 report 數量會繼續增加，而且不只 curl，所有大型開源專案都會面對同樣的問題。
問題是，找漏洞的成本降了，修漏洞的成本沒變。
一份好的安全回報，維護者要做的事情沒有少：驗證、寫 patch、確認 regression、寫 advisory、協調 disclosure 時間線。這套流程是人工的，而且責任很重，因為 curl 裝在大概三百億台設備上。不能敷衍。
所以現在的狀況是：生產端（找漏洞的人）效率飛漲，消費端（修漏洞的人）還是原本的速度。
我自己的 side 觀察
我在公司的專案也開始感受到類似的壓力，雖然規模差很多。我們用 Dependabot + 一個小 workflow 定期掃 dependency，以前一個月可能跑出三四個 issue，最近突然多了一倍。原因之一就是有人開始用 AI 輔助做 supply chain 掃描，然後直接 open issue 到我們 repo。
報告品質確實比以前好，會附上 PoC 或具體的 call stack，但我消化這些報告的速度沒有因此變快。
我試過一個做法是讓 Claude 先做初步分類：「這個 CVE 在我們的 usage pattern 裡有沒有實際 exploitable path？」成功率大概 70%，可以過濾掉很多 false alarm，但還是有 30% 需要人工確認。至少把優先順序整理出來，讓我不用每個都從頭看。
但這只是我個人 workflow 的小優化。Daniel 面對的是每天一份、一分都不能放著不管的壓力，scale 完全不一樣。
流程設計的問題
我覺得這整件事暴露了開源安全流程的一個結構性問題：
整個生態系假設的前提是「安全研究者稀缺」。 Bug bounty、responsible disclosure、CVE 流程，都是設計給「偶爾有人回報」這個情境的。現在 AI 工具讓這個稀缺性消失了，但下游的處理機制沒有跟著調整。
一個可能的方向是做「report triage 的自動化」，但這需要有人去建，而建的人通常就是那個已經忙到快掛的維護者本人。這是個很諷刺的困境。
另一個方向是讓回報者承擔更多責任：要求 report 必須包含具體的 reproduction script、影響範圍評估、甚至初步的 patch suggestion。這會讓一些低品質的 report 消失，但也可能嚇跑真正有價值的研究者。
curl 的做法是 2026 年初直接關掉 bug bounty 計畫。理由是 bounty 吸引了太多 AI slop report，處理成本超過收益。但關掉之後，report 品質反而更高了——可能是因為剩下的人都是真的在做研究，不是在刷獎金。
這個結果蠻反直覺的，值得多想一下。
不知道其他人有沒有在維護開源專案或者公司內部 OSS，有在感受到這個趨勢嗎？我目前的解法很粗糙，想聽看看別人怎麼處理。
作者：阿哲 (A-Zhe)