在 2026 年 5 月，GitHub Advisory Database 發布了 1,560 份已審核的諮詢，比我們一般的每月產出多出 五倍以上，創下歷史新高。

即便如此，仍不足以應付。

過去幾個月，漏洞生態系發生了根本性的轉變。私有漏洞報告、儲存庫諮詢以及 CVE 請求同時增加，將整個系統推向新的運作規模。

本篇文章延續 持續進行的 GitHub 社群討論，追蹤漏洞報告本質的演變，以及 PVR 與 Advisory Database 的路線圖發展。該討論串中一再出現的主題是平台變更對諮詢策展及資料品質的下游影響。這與 GitHub 更廣泛的轉變一致，即強調漏洞報告中的品質與共同責任，進而直接影響諮詢資料必須如何策展與維護。

TL;DR

新諮詢的審核時間變長，因為漏洞數量與複雜度已大幅增加。諮詢品質並未改變：已審核的諮詢仍由人工驗證，現有警示仍正常運作。如果您想要協助，請專注於三件事：提交完整的漏洞資料、與維護者及研究人員密切協調，以及僅在有明確發布意圖時才請求 CVE。

創紀錄的產出與前所未有的輸入

5 月並非單一的尖峰。從 3 月到 5 月，我們每月持續處理超過 6,000 項諮詢決策。這包括更新現有諮詢、發布新諮詢以及審核流入的諮詢，超越以往任何三個月的最高峰值。

與此同時，每個來源的流入量都加速：

  • 平台上的私有漏洞報告從 1 月的每週約 550 件，增加到 5 月大部分時間的每週超過 3,000 件。
  • 儲存庫諮詢從每週約 650 件，增加到每週超過 5,000 件。
  • GitHub CNA CVE 請求在 5 月達到近 4,000 件，幾乎是去年的 10 倍。
  • CVE 計畫已在 2026 年發布 30,000 多件 CVE。
  • 已有超過 170 萬個儲存庫啟用私有漏洞報告。
Line graph showing a sharp increase in PVR submissions, CNA requests, and Repo GHSAs published, starting around January 2026. The lines go back to May 2025 and is relatively flat with a slight increase until January 2026.

這不是局部性的激增，而是反映整個漏洞揭露生態系的結構性變化。

影響

自 4 月中旬以來，由於此激增，我們無法持續達到內部的發布目標。處理時間先延長到約一週，接著有相當比例需要數週。更長的發布時間可能增加暴露窗口。我們非常重視這點，而及時性是這個資料庫所提供的核心價值之一。

仍在正常運作的部分

我們的資料管道與發布基礎設施在此期間持續運作。匯入作業正常執行、資料完整性維持、已發布的諮詢準確無誤。今日達到已審核狀態的諮詢，仍符合與以往相同的品質標準。

CVE 指派品質維持良好。我們的指派率在整個激增期間維持在 91–94% 之間，與歷史常態一致或更佳，顯示我們收到的請求並未出現明顯退化。

問題在於處理量。驗證、豐富化並發布諮詢資料的系統仍在運作；只是現在的運作量與複雜度已超出原本設計的範圍。

工作並非均質

並非每個安全諮詢都需要相同程度的努力。有些諮詢格式良好：諮詢詳細資訊清楚標明受影響的套件及其所屬生態系、版本範圍已記錄、修正也已標記。策展人可以在幾分鐘內驗證並發布。

但越來越多的流入諮詢需要更多調查：

  • 套件消歧義。 諮詢細節寫著「foo」，但這是指 npm 上的 foo、PyPI 上的 python-foo，還是 Maven 上不相關的 foo？當上游資料未指定生態系時，我們的策展人必須找出答案。
  • 版本範圍重建。 許多安全諮詢送來時沒有受影響的版本範圍，或是範圍與實際發布歷史不符。策展人會追蹤 commit、變更日誌與標籤，以判斷實際受影響的範圍。
  • 多生態系諮詢。 有些專案會將套件發佈到多個登錄檔，例如同一個函式庫同時有 .NET 實作（NuGet）與 JavaScript 實作（npm），此時共享邏輯中的漏洞會影響兩者。這需要跨多個資料來源進行獨立驗證。
  • 上游資料衝突。 當 CVE 記錄、維護者的諮詢與 commit 歷史對受影響範圍的說法不一致時，必須有人找出真相。

過去較簡單的諮詢占大多數，較困難的案例尚可吸收。當數量激增時，佇列中同時堆積兩種，而複雜的案例耗時不成比例，造成複合效應。如今，混合比例變得更加重要。這不只是工作量增加，而是複雜度大幅提高。

「已審核」實際上意味著什麼

一篇已審核的諮詢不只是重新發布的記錄，而是驗證的結果。

策展人會：

  • 將漏洞對應到正確的生態系套件
  • 根據發布歷史驗證受影響與已修正的版本
  • 確認上游資料的準確性
  • 檢查是否有重複與一致性
  • 驗證分類與評分

這正是下游工具能夠依賴這些資料而無需額外驗證的原因。

若跳過驗證而加快發布速度，將會在規模上增加假陽性，這可能比延遲帶來更多風險。

更廣泛的生態系轉變

此趨勢不只發生在 GitHub。

已回報與已發布的漏洞數量持續快速成長，生態系中的各組織都在因應這項變化。

系統正如設計般運作。比以往更多漏洞被回報、揭露與追蹤。這對下游（包括諮詢策展）造成壓力。

我們現在正在做的事

  • 改善社群貢獻品質與處理量。 社群貢獻是我們改善 Advisory Database 的重要部分，每份貢獻都會依據與其他諮詢相同的驗證標準進行審核。我們已強化分類與優先順序，讓高品質的提交能更早被辨識、審核更一致，並更快通過佇列。這有助於我們應對當前數量，同時強化維護高品質、可信資料集的主要目標。
  • 擴展策展後方的系統。 我們已增加後端策展系統的部分容量，以處理更高的持續處理量，並持續現代化支援分析與佇列管理的資料基礎設施。
  • 建置 AI 輔助研究工具。 我們已開發並部署工具，在諮詢審核的研究階段為策展人提供 AI 輔助。策展人仍做出所有決策，但常規研究可更快完成，以獲得更高品質的諮詢。
  • 在最有幫助的地方擴展自動化。 我們已改善從上游 CVE 資訊擷取更多資料的自動化，以及處理社群貢獻與已審核諮詢互動的方式。這些工作可在不降低品質標準的前提下減少每項決策所需的時間。
  • 投資文件與培訓。 我們已大幅擴展營運文件。這讓我們能更快讓新團隊成員上手，並提升團隊間的一致性。

我們接下來要建置的內容

為了支援這個新規模，我們正在投資：

  • 減少最常見案例的每件諮詢處理時間。 相當比例的流入諮詢需要遵循可預測模式的研究，例如識別正確的套件、確認版本範圍以及檢查是否有修正。我們正在投資能加速這些模式的工具，讓策展人能將時間花在真正需要人工判斷的模糊案例上。
  • 讓基於風險的審核優先順序更聰明。 我們正在探索額外的風險訊號用於優先排序，例如套件使用量、活躍利用證據以及生態系影響，以確保最重要的諮詢優先送達使用者。
  • 改善與上游資料來源的回饋迴路。 策展時間有相當比例花在修正不完整或不準確的上游資料。我們正在投資與來源的更緊密整合，特別是透過增加儲存庫 GitHub Security Advisory 與 Private Vulnerability Reporting 的資料驗證，讓資料品質問題能在更接近來源處解決，而非在我們的審核佇列中。
  • 持續保持透明。 我們將在進展時分享更新。如果情況改善，我們會告訴您。如果遇到新挑戰，我們也會分享。

這對您意味著什麼

  • Dependabot 使用者： 現有警示不受影響。新諮詢可能需要較長時間觸發，嚴重問題會被優先處理。
  • API 與 feed 消費者： 已審核資料仍準確；未審核的諮詢可見但尚未驗證。
  • 維護者： 儲存庫諮詢持續流入全球資料庫；優先順序根據多項因素決定，包括專案影響力與嚴重性。

您可以如何協助

在漏洞報告中包含完整資料。 提供受影響版本範圍、根本原因與清楚的重現步驟，能直接影響諮詢審核的速度與準確性。當這些資料完整時，策展可能只需幾分鐘。當資料不完整時，策展人必須從原始碼、發布歷史與衝突的上游訊號中重建缺失的細節。在這個規模下，這些缺口會快速累積。高品質的上游資料是改善整個生態系速度與準確性的最有效方法之一。

包含正確的諮詢細節。 我們的 最佳實務指南涵蓋生態系分類、套件名稱與版本範圍格式，但一些額外的細節能直接影響諮詢審核與發布到 GitHub Advisory Database 的速度與準確性。

  • 使用登錄檔中顯示的套件名稱。 諮詢中的套件名稱必須與登錄檔相符，而非儲存庫或專案名稱。下游系統依賴登錄檔識別碼將諮詢對應到受影響的相依性。如果名稱不正確或遺漏，警示就無法可靠產生，受影響的使用者可能永遠不會收到通知。使用登錄檔名稱可確保諮詢能被正確連結、索引與分發。
  • 列出所有受影響的套件。 有些漏洞會影響專案中的多個套件。每個受影響的套件都應單獨列出，並附上各自的生態系、套件名稱與版本範圍。諮詢是以套件層級被使用，因此遺漏套件就等於遺漏依賴它的使用者。包含所有已知的受影響套件可改善涵蓋範圍，確保警示能送達所有受影響的使用者。
  • 提供完整的 CVSS 向量字串。 GitHub Advisory Database 支援 CVSS 3.1 與 4.0。嚴重性標籤如「高」只是快速摘要，但完整的 CVSS 向量字串包含更豐富的屬性，例如攻擊複雜度、所需權限與使用者互動，能更詳細描述漏洞。這些結構化資訊允許驗證嚴重性、讓解讀一致，並供下游工具用於優先排序與自動化。若缺少它，評分會較不精確，也較難在不同諮詢間比較。如果您要包含分數，請使用官方計算機並包含完整向量。
  • 包含相關的 CWE 分類。 CWE 識別漏洞背後的根本弱點，例如跨站腳本、SQL 注入或不受信任資料的反序列化。與敘述性描述不同，CWE 為下游工具與安全團隊提供標準化方式來理解所處理的問題類型。這很重要，因為 CWE 資料可用於分類、過濾、優先排序與比較大型資料集中的漏洞。它幫助組織將相關問題分組、套用政策或報告規則，並了解影響其軟體的漏洞模式。CWE 越具體，諮詢對下游消費者就越有用。

更多指引請參閱 撰寫清楚、完整安全諮詢的最佳實務。

請求 CVE 時要有明確意圖。 請求 CVE ID 表示漏洞將被公開揭露與追蹤。若在沒有發布計畫的情況下提出請求，可能會分散本應用於正朝向發布的諮詢的時間與注意力。將 CVE 請求與明確的發布意圖對齊，有助於確保努力集中在最具即時影響力的地方，並讓系統對每個人保持回應性。

與維護者及其他研究人員密切協調。 高品質的諮詢資料依賴共享脈絡。對齊受影響套件、版本範圍與修正，有助於減少來源之間的歧義與衝突資訊。在這個規模下，協調上的小缺口可能會在下游造成大不一致。

透過向 Advisory Database 提交 pull request 來改善諮詢品質。 每次對版本範圍、套件對應或修正的更正，都能提升開發者所依賴的準確性。

認識這個生態系轉變的規模並參與其中。 漏洞報告的增加反映了真正的進步。比以往更多問題被發現、修正與揭露。在這個規模下維持品質，取決於研究人員、維護者以及資料消費者與生產者共同朝同一目標努力。

更大的圖像

兩年前，該資料庫每月發布約 270 份諮詢。

在 2026 年 5 月，它發布了超過 1,500 份，同時在系統中處理數千項額外決策。

這反映出更廣泛的轉變：

  • 更多儲存庫啟用負責任揭露。
  • 更多研究人員回報漏洞。
  • 更多維護者發布修正與諮詢。
  • 漏洞生態系正朝向更高的透明度擴展。

這種成長對我們的系統造成壓力，但也代表有意義的進展。

每份諮詢都提升可見度。每個警示都降低風險。

我們正在擴展以因應這個現實，並將持續分享進展。