漏洞回報量大幅攀升 （★ 70 分）
Linux 核心安全郵件名單近兩年收到的漏洞回報暴增，從兩年前每週約 2 到 3 件、去年每週約 10 件，拉高到今年以來每天 5 到 10 件。作者 Willy Tarreau 表示，和早先充滿 AI 粗糙內容的時期不同，現在多數回報都是真的，甚至準確到必須增補維護者協助處理；過去少見的重複通報也開始天天出現，代表不同研究者正用不同工具找到同一個缺陷。這種變化雖然讓人疲憊，卻也表示許多問題確實能被修掉，而不是白白消耗審查人力。
作者認為，既然研究者能迅速找到這些弱點，攻擊者同樣可能掌握，所以及早修補比掩蓋更實際。他推測，目前可能是在清除長年累積的漏洞存量，若漏洞被找出的速度高過新漏洞被寫進去，整體軟體品質有機會在經歷一段混亂後回升。由此帶來的第一個改變，是安全修補流程不再適合仰賴保密期；安全問題應被視為一般錯誤的一部分，重點是持續更新，而不是只盯著 CVE (Common Vulnerabilities and Exposures，通用漏洞編號) 編號。那些過去發布後缺乏長期維護的軟體，也會因為任何程式都更容易成為目標，而被迫正視維護責任。
在同頁後續回應中，他補充，像 Syzbot (Linux 核心的自動化模糊測試系統，以大量異常輸入找錯) 這類通報，多半會被導向公開郵件名單；只有少數可能造成立即升權（取得更高系統權限）或常見部署無法迴避的重大問題，才值得短暫保密。以 Linux 核心幾乎每週發版的節奏來看，直接合併修補並盡快發布，通常比等到揭露當天再同步釋出修補更有效，也能讓各子系統一起分攤處理壓力。他並舉 OpenSSL 與 HAProxy 為例，指出保密期若用得太廣，往往既混亂又容易引發回歸問題（修補後引進的新錯誤），最後反而得修兩次。
在 Hacker News 上，較受重視的回應多半把焦點放在 AI 輔助找洞究竟是清理舊帳，還是製造新麻煩。樂觀者認為，如果同樣的工具能前移到程式碼合併前的審查、靜態分析（不實際執行程式、直接檢查程式碼）與模糊測試，也許不只可以加快清除積壓漏洞，還能在問題進入正式版本前先擋下來。也有人引用 Google，以及 Mozilla 與 Anthropic 的案例，主張約 70% 的安全弱點與記憶體安全有關，因此新專案若改用 Rust 這類較重視記憶體安全的語言，長期可明顯減少漏洞；但也有人反駁，把 Rust 實務開發一概說成到處都得寫 unsafe (Rust 中可繞過部分安全保證的區塊) 並不符合現況。另一些人則提醒，LLM (大型語言模型) 既可能加快找洞，也可能加快寫出新錯誤，短期內未必能減輕維護者負擔。
對於文中「軟體品質可能回到 2000 年前水準」的說法，討論區意見明顯分歧。一派同意，因為當年修補必須靠磁片、光碟或較慢的下載管道，測試與品管門檻更高，使用者可見的錯誤較不被容忍；也有老工程師回憶，過去確實得更理解 Win32、CPU 與例外處理成本，不能像今天一樣先上線再修。另一派則認為，若從安全角度看，2000 年前並沒有比較好，只是那時系統較封閉、攻擊面（可被利用的入口總量）較小，網際網路普及後從緩衝區溢位到 SQL Slammer 之類蠕蟲都暴露出當年的脆弱。也有人質疑這類樂觀判斷近似替 AI 造勢、缺乏完整統計；反方則指出發言者本身長期維護 Linux 與 HAProxy，不宜簡化成宣傳。整體而言，討論者普遍接受漏洞回報確實變多且更有價值，但對這波變化會把軟體帶向更高品質，還是讓維護者與防禦方進一步超載，仍維持審慎甚至懷疑的態度。
👥 31 則討論、評論 💬
https://news.ycombinator.com/item?id=47611921