Schneier 的 AI 漏洞發現聲稱令軟件修復承壓

Bruce Schneier 11 月 2 日的文章摘要聚焦一項令人震驚的聲稱：歷來有記錄的嚴重軟件漏洞中，3% 是在一個月內發現。其 AI Vulnerability Finding 文章所提供的摘錄亦預測，每年將額外發現約 100,000 個漏洞。這些數字尚未在此獲得驗證，但已有紀錄的發現，已令負責修復軟件的團隊承受壓力。

核心衝突在於發現速度與修復能力之間。發現安全漏洞，意味著有機會保護用戶；同時亦會帶來工作：必須有人驗證報告、評估暴露風險、審核修正方案，並推出更新。自動化發現並不會自動加快其後的每一項決策。

Anthropic、Google 與 Mozilla 提供了有用的參考點，儘管它們的數字衡量的是不同事物。它們的刊物支持一個較狹義但影響深遠的結論：自動化安全研究正帶來真實發現，但統計方法與後續結果仍須仔細檢視。對開發者及企業買家而言，問題在於更快的發現速度，是否真的轉化為更少的暴露風險。

AI 漏洞發現聲稱實際證明了甚麼

這項標題統計數字是一條研究線索，而非獨立確立的全球嚴重軟件漏洞衡量結果。

與 Schneier 的漏洞發現文章相關的所提供摘錄，將這些數字表述為一則評論。本次檢視無法取得原始頁面。因此，該摘錄未能說明由誰計算該百分比、計入哪些紀錄，或如何界定報告期。

這項區別限制了可從該聲稱中負責任地推導出的結論。一個引人注目的百分比，可能準確描述某個特定資料庫，卻不代表歷來發現的每一個安全漏洞。當讀者默默以更廣泛的母體取代原始分母時，它亦可能造成誤導。

發現、披露及資料庫發布是不同事件。研究人員可能在供應商確認前私下識別漏洞；公開文件可能在較後時間才出現，並與軟件更新同期發布。因此，某月的發布高峰並不能證明所有相關漏洞均於該月發現。

「所有有記錄的歷史」一語，亦帶來另一項未解的界線問題。一項可供審計的計算，需要具名資料庫、帶日期的快照，以及一致的納入規則；亦需要說明重複紀錄、被拒絕的提交，以及發布後嚴重程度有所改變的漏洞如何處理。

年度預測引入了另一項假設：近期速度將會持續。即使原始月度計數最終證明準確，這項假設仍值得檢視。集中的研究活動、發布積壓或協調發布，都可能造成暫時性激增，卻未必能證明存在穩定的年度比率。

這亦存在分類問題。摘錄開首談及嚴重漏洞，之後卻較廣泛地提到 bugs 及歷史漏洞總數。若不核實底層計算，這些分類不能互換使用。軟件缺陷、已確認安全漏洞及嚴重漏洞，描述的是不同母體。

這些限制均不代表更廣泛的發展不重要；它們界定了可信程度應止於何處。可站得住腳的敘事，是關於已有文件記載的發現活動及其營運後果，而非一項未獲支持、聲稱精確量度歷史轉捩點的說法。

對於透過社交帖文接觸 AI Vulnerability Finding 的讀者而言，這項區別保護了其中有用的洞見。安全團隊有理由立即檢視自身能力，但毋須先接受一個未經驗證的百分比，才調查其發現及修復流程是否正變得失衡。

Anthropic 的已報告結果顯示規模，但有重要界限

Anthropic 公布的數字支持大規模發現的說法，但未能驗證該評論中的歷史百分比或每月推算。

在 10 月 6 日公布的網絡驗證計劃中，Anthropic 表示，合作夥伴在 4 月至 7 月期間已驗證至少 129,000 個軟件漏洞。該公司另行表示，在 4 月至 10 月期間，其開源掃描發現了 5,500 個已驗證問題。

該公司表示，逾 33,000 個已驗證漏洞被評為嚴重或高嚴重程度。這些是公司自行報告的結果，並非經獨立重現的人口普查。其期間及分類亦與所提供評論中「一個月內發現嚴重漏洞」的聲稱不同。

Anthropic 披露了重大限制。其影響報告基於 33 個合作夥伴提供的部分資料，而不同機構採用不同的分類處理方法；不足一半提供了已修補數目。因此，該公司形容所報告的修補率明顯不完整。

這些界限相當重要，因為不同衡量方法回答的是不同問題。發現數量衡量已報告的發現產出；確認數量增加了驗證步驟；已修補數量描述較後的結果，而部署證據則處理受影響用戶是否真正獲得保護。

因此，競爭層面的含意應維持狹義。Anthropic 報告的是參與機構使用其模型所得的結果；Google 的威脅研究人員則檢視更廣泛的披露及遭利用模式。這些刊物提供互補觀點，但兩者均未提供受控比較，以證明哪一間供應商帶來更佳安全成果。

對買家而言，這意味著發現總數應成為討論起點，而非結論。產生更多發現的供應商，或許能揭示被忽略的問題；它亦可能要求客戶投入更多審核時間，尤其當報告缺乏清晰的重現證據或受影響版本資料時。

一項有用的評估，應區分新的、已接受的漏洞與先前已知問題及重複報告；亦應將建議修正與經審核修正分開。這些區分令比較更困難，卻將技術產出連結到客戶必須完成的工作。

壓力尤其落在擁有重要軟件、但沒有龐大專責安全團隊的機構身上。發現能力可以購買或借用；即使原始分析自動送達，接受報告及改動產品的問責仍必須有所歸屬。

這是從已報告規模得出的分析含意，而非針對全行業人手配置結果的衡量。若流入的已驗證報告增加，而審核能力維持不變，未解決的待辦隊列便會增長。確切速度取決於各機構的軟件、工具，以及作出安全變更的能力。

這正是 Anthropic 公告最有用的後續問題所在：有多少已接受的發現最終進入仍受支援的版本？它們有多長時間未獲解決？若沒有可比較的答案，大量發現數字更清楚展示的是活動量，而非暴露風險已減少。

軟件維護者在發現後承接修復工作

維護易受攻擊軟件的機構，承擔將報告轉化為保護措施的營運負擔。

NIST 在 4 月 15 日公布的漏洞資料庫變更，反映圍繞安全工作的資訊基礎設施正承受壓力。該機構表示，漏洞提交量在 2020 至 2025 年間增加 263%；即使處理產出提高，仍無法趕上速度。

NIST 改變了其在 National Vulnerability Database（公開漏洞資訊儲存庫）中充實條目的方式。充實工作會加入嚴重程度評分及受影響產品等細節。按修訂後的方法，指定分類將獲優先處理，其他條目則仍會列出，但不會即時獲得充實資訊。

該機構優先處理已知遭利用的漏洞、聯邦政府內使用的軟件，以及已界定的關鍵軟件；亦承認有關準則未能涵蓋每一項可能帶來重大後果的問題。這項變更記錄了一項能力限制，卻未能證明 AI 導致底層提交量增長。

更廣泛的含意是，日益增加的發現流不只需要更多資料庫列項。維護者及客戶需要可靠背景資料，以決定甚麼值得關注。缺乏或延遲的背景資料，可能將判讀工作轉移至原本已負責評估自身系統的團隊。

對軟件維護者而言，收到可信報告會帶來多項責任，不能簡化為閱讀其結論。必須理解受影響行為；建議修正必須配合周邊設計；受支援版本及相依組件或需各自作出決定。

企業用戶面對另一層判讀工作。易受攻擊的組件，可能存在於其購買而非直接維護的產品之中。他們需要知道哪些已安裝版本受影響、易受攻擊行為是否可被觸及，以及供應商支援何種處置行動。

這些是說明性的營運相依關係，並非顯示每一間機構正經歷相同積壓的發現。其重要性源於發現與補救之間的區別；補救是修正或降低漏洞風險的過程。只有當有人能就報告作出知情決定時，報告才有價值。

誘因失衡值得關注。發現平台可即時展示發現成果，而維護者因細心審核及平穩無事的更新所獲得的可見認可較少。買家應明白，報告量與維護質素代表安全工作的不同貢獻。

當決策跨越團隊時，共享文件便相當有用。一個可搜尋的知識庫可協助連結技術紀錄、責任歸屬決策及佐證資料。它有助協調；驗證及發布批准仍需要適當的工程流程。

實際壓力既是組織層面，也是技術層面。更快的發現速度，要求更清晰界定報告、修正及部署決策的責任歸屬。當這些責任仍然模糊，更大量的正當發現流可能會在改善產品前，先暴露回應流程中的弱點。

Mozilla 說明為何發現結果需要完整修復流程

Mozilla 的說明提供了一個具體例子，展示由 AI 協助的發現如何連結至已推出的軟件變更。

Mozilla 的Firefox 強化流程報告，描述了將模型整合至測試基礎設施及其安全漏洞生命週期。團隊表示，要達到有用的規模，需要可重現測試、重複項目偵測、分類處理、追蹤及發布工作。該團隊表示，已在 Firefox 150 修復 271 項 Mythos Preview 發現。

同一帳戶亦解釋了為何資料庫總數需要謹慎看待：Mozilla 會將多個內部回報的錯誤歸入共用的漏洞識別碼。因此，其回報的錯誤數量並不直接等同於公開識別碼的數量。在沒有說明兩者關係的情況下計算任一群體，都可能誤導讀者。

Mozilla 亦區分嚴重錯誤與實際遭入侵。其分層瀏覽器設計意味著，攻擊者可能需要多個漏洞才能跨越保護邊界。高嚴重性分類表示問題值得處理；並不代表完整攻擊已經建成。

這些已回報的細節，比單獨的發現數字構成了更有用的案例研究。它們顯示維護者如何討論自動化發現與發布之間會發生甚麼事，也揭示模型的輸出在使用者獲得修正前，必須進入的制度性知識體系。

分析上的啟示是，模型能力與組織能力會相乘。若沒有人能重現或評估問題，即使系統發現真實漏洞，所提供的保護亦有限。成熟的應對流程，能更有效運用以工程師可用形式送達的證據。

這種關係亦令採購比較變得複雜。在精心準備的專案環境中評估的模型，受惠於建置工具、測試基礎設施，以及理解程式碼的維護者。客戶不能假設，將同一模型指向陌生應用程式便會得到同等結果。

設想一份涉及廣泛重用函式庫的假設性報告。初步證據或可證明測試環境中出現當機。維護者仍須了解成因、確認受影響版本，並判斷建議的修正是否處理了根本問題。

回歸測試，即防止已知缺陷再次引入的檢查，有助維持修正成效。發布通訊須準確描述受影響行為。下游使用者其後需要適合採用該函式庫產品的更新途徑。

這個假設例子旨在說明工作流程，並非斷言另有真實世界事件。它顯示為何同一發現可為研究人員、函式庫維護者、產品供應商及企業營運者帶來工作。各方各自掌控通往保護路徑的不同部分。

這裡存在潛在的正向循環。更好的證據可減少解讀報告所花的時間，讓更多注意力投向實際修正。經審核的修補與實用測試，繼而可改善後續自動化分析可用的環境。該循環會否實現，取決於實施方式及量度結果。

反向情況亦有可能發生。包裝欠佳的發現，可能消耗原本用於處理更強報告的注意力。關鍵分別不單是人類研究與自動化研究，而是能幫助維護者採取行動的證據，與將未解決調查工作轉嫁給接收者的輸出之別。

嚴重性標籤無法彌補驗證落差

關鍵級標籤、公開識別碼與已觀察到的利用，描述的是安全問題的不同維度。

通用漏洞評分系統（Common Vulnerability Scoring System，CVSS）是一套透過既定技術特徵描述漏洞嚴重性的框架。FIRST 的嚴重性評分規格將關鍵級評分界定為 9.0 至 10.0。單憑該分類，無法證明攻擊者正在某個特定組織中利用漏洞。

同樣地，CVE（Common Vulnerabilities and Exposures）識別碼會為已公開披露的漏洞提供共用參照。它並非技術範圍完全一致的通用單位。數量部分取決於問題如何獲分配及呈現。

因此，要嚴謹評估原有百分比，必須在不同時間採用一致規則。分子與分母必須使用相容的群體及嚴重性定義。否則，計算可能混合不可比的紀錄，卻看似精確。

同樣重要的是時間問題。若分子計算近期發布的紀錄，量度的是發布活動。若稱之為發現活動，則需要更多證據說明相關問題是在何時被發現。回報延誤可將兩者分隔。

Google 在 9 月 30 日對披露與利用的分析提供了更廣泛的背景。其研究人員報告指，2026 年 1 月有 5,045 宗披露，8 月則有 10,740 宗。他們亦警告，分配政策及供應商發布週期令原始總數難以解讀。

研究人員另行追蹤利用情況，並使用自身風險評級，而非 CVSS 類別。這個方法論差異很重要：其分析中的風險類別不應被默默重新標示為關鍵級嚴重性評分。措辭相近，並不令不同分類系統可以互換。

這些發現支持對因果主張保持謹慎。披露數量增加可與 AI 使用增加同時出現，卻不能證明 AI 解釋了全部增長。回報行為、覆蓋範圍及發布慣例的變化亦需審視。

已觀察到的利用亦有其限制。監測資料集未有出現的漏洞，不一定安全或未受觸及。相反，大量披露並不能證明成功入侵也同等大幅增加。可見度及抽樣方式會影響研究人員能觀察到的情況。

因此，最有力的懷疑立場是在要求嚴謹量度的同時，承認真實技術進展。它不要求否定每一份公司報告，而是追問證據是否支持所提出的具體結論，尤其當結論延伸至歷史總數或未來年度產出時。

就 AI Vulnerability Finding 而言，未解決的問題並非自動化系統能否識別真實漏洞。所引用的專案帳戶已支持這項較狹窄的主張。不確定之處在於可比群體間的規模、增長的責任歸屬，以及發現轉化為持久保護的比率。

這個區別應塑造公共討論。將每個漏洞視為即時災難，可能令優先次序安排失效。把不確定的整體統計數字當作忽視已有記錄發現的理由，則造成相反錯誤。證據應決定主張的範圍及回應的迫切程度。

關注已確認修正、發布時間與獨立重現

下一批有用證據，將把發現產出連結至獲接納的發現、已交付的修正及可重複的結果。

未來數月，首先應留意 Anthropic 及參與組織提供更完整的報告。有用的發展會是配對數據，顯示哪些發現獲接納、已修正，以及納入受支援版本。可比報告會令既有的發現主張更容易評估。

更有力的說明會交代如何處理重複報告及相關缺陷，並把私下維護的軟件與可檢視文件的公開專案分開。它亦應清楚列明報告期，避免比較重疊或規模不同的時間窗口。

若資料顯示發現增長伴隨已完成修復，便會加強自動化發現提升防禦能力的論點。若已確認的發現持續累積，卻沒有相應發布證據，則會加強發現速度超越應對能力的憂慮。單憑不完整報告，結果仍屬不確定。

第二，留意獲接納報告與可用更新之間的時間。修補程式，即旨在修正缺陷的軟件變更，只是中間里程碑。受支援版本會讓使用者取得該修正，而部署則決定受影響環境是否實際獲得更新。

這些間隔很重要，因為整體處理量可有所改善，但個別問題仍可能等待過久。團隊或可整體關閉更多報告，卻同時保留愈來愈長的疑難個案隊列。只報告已完成的修正，會掩蓋那些未解決項目。

較短而可持續的修復週期證據，會加強自動化發現可改善營運安全的論點。未解決隊列上升，或早期修正反覆需要更正，則會構成挑戰。兩種結果都值得與頭條發現總數一併關注。

第三，留意在維護資源不同的專案間進行獨立重現。經廣泛測試的瀏覽器所得結果具參考價值，但不足以證明每個應用程式或函式庫都有相同結果。更廣泛的證據需要有記錄的環境、獲接納的發現，以及清楚交代所需工作的說明。

若維護者發表自身評估，而非只認可供應商總數，重現會尤其有用。就發現的有效性及修正達成一致，比產生看似令人信服輸出的示範提供更多資訊。分歧可揭示整體統計數字所掩蓋的限制。

這些訊號提供一種評估進展的方法，毋須依賴最終誰會獲益最多的預測。攻擊者與防禦者可使用相關能力，但其目標及營運限制不同。結果取決於存取權、實施方式，以及保護性變更抵達受影響系統的速度。

原有評論捕捉了 AI Vulnerability Finding 帶來的意外感，但意外只是審視的起點。要求查看百分比背後的資料集。詢問適用哪些嚴重性規則，以及日期描述的是發現還是發布。然後追蹤發現經過確認、修正及發布的過程。若你正在評估安全工具，請要求你的團隊可重現的證據，以及維護者認可的結果。若你依賴軟件供應商，請詢問他們如何傳達受影響版本及已完成修正。在重複年度預測前，先閱讀相關專案帳戶。實用的問題很具體：當發現加速時，負責你所用軟件的組織能否把那些證據轉化為保護？