curl將中低風險漏洞移至GitHub公開審查
curl 專案將由 10 月 26 日起調整漏洞處理方式：經團隊評定為低或中等風險的問題，會在 GitHub Issues 公開提出及討論；高風險與重大漏洞則繼續透過 HackerOne 私下處理。這不代表所有未修補漏洞都會預早曝光，公開範圍只限中低風險案件。
iThome 報道指出，curl 同時提供命令列工具及供其他軟件使用的 libcurl 函式庫，因此改動不只影響直接使用 curl 的開發者，也涉及依賴 libcurl 傳送網絡資料的專案。對 Linux 發行版維護者及企業 IT 團隊而言，GitHub 上的公開討論可較早顯示修補進度、受影響情況及可能的相近缺陷；但他們亦要自行判斷公開中的問題是否已影響自身部署，不能把討論串當作已完成修補的通知。
AI 增加的，是篩選與驗證工作
iThome 指出，curl 過去數年接獲的漏洞通報中，逾九成可迅速判定未達高風險，但逐宗核實仍消耗維護者大量時間。近期不少報告由研究人員以 AI 模型測試 libcurl 的選項、協定與操作次序而來；部分異常只在極少見的組合下出現，另一些雖可重現，卻容易被使用相關操作的人察覺，實際被利用的機會較低。
這顯示 AI 輔助挖掘能擴大測試覆蓋面，卻也把「是否構成可利用漏洞、影響有多大」的判讀壓力轉移至開源維護團隊。curl 選擇讓社群參與確認問題、檢查修補，以及協助撰寫安全公告，實際上是以較公開的協作模式處理大量低優先級訊號。
公開審查的效益與界線
公開討論讓更多開發者檢視修補是否完整，亦可能及早找出相似問題。iThome 報道提到，curl 過往公布 CVE 與修補後，研究人員常會利用 AI 追查同類缺陷或修補遺漏；若這類審查提早在新版推出前進行，發行版及依賴 libcurl 的專案或可更早安排後續工作。
代價是公開尚未修補的問題，會延長潛在攻擊者研究及利用的時間。curl 因此保留 HackerOne 作為高風險與重大案件的私下處理渠道。若研究人員無法判斷嚴重性，仍可先經 HackerOne 提交；若 curl 最終定為低或中等風險，案件會被要求轉至 GitHub，原有通報則以資訊性案件結案並公開。
對使用 Linux、雲端服務或以 libcurl 建立網絡功能的團隊，接下來值得觀察的是：公開 Issues 能否縮短修補驗證時間，以及各發行版與下游專案會否把這些討論納入既有的漏洞追蹤流程。
延伸閱讀
AI 輔助說明： 本文由 AI 協助整理，並經兩輪獨立自動品質審核；資料及連結仍以原始來源為準。
參考來源
- iThome — AI漏洞通報湧入，curl改在GitHub公開處理中低風險漏洞 — original report
本文根據原文及公開資料整理；資料有出入時，以原文及官方資料為準。
