去年5月，GitHub安全咨询数据库单月发布1560条经过审核的安全公告，创下平台历史最高纪录。这个数字是往常月均产量的五倍多，但即便如此，平台依然跟不上漏洞报告的涌入速度，暴露出全球漏洞披露生态正在发生的深层变化。

GitHub方面表示，这一波增长并非临时性波动，而是持续趋势的体现。2026年3月至5月间，平台每月处理超过6000项公告决策，涵盖新发布、更新和入库审核。与此同时，来自所有渠道的漏洞数据都在急剧攀升——私有漏洞报告从1月的每周约550份飙升至5月的每周超3000份，仓库安全公告的周提交量也突破了5000份。

打开网易新闻 查看精彩图片

CVE编号申请量同样出现暴涨。仅在5月，通过GitHub的CNA机构提交的CVE申请就接近4000个，同比增幅接近十倍。放眼全球，2026年以来已发布的CVE数量超过3万个，漏洞发现与披露的规模正在以前所未有的速度扩张。

数据洪流直接冲击了公告审核时限。自4月中旬起，GitHub已无法稳定达成内部的发布时效目标。审核周期从几天拉长至数周，这意味着未修复漏洞的暴露窗口在被动延长。不过GitHub强调，所有审核公告仍经过人工核验，确保软件包映射、受影响版本和严重程度分级准确无误。CVE分配率稳定在91%至94%之间，说明提交质量并未出现明显下降。

瓶颈在于吞吐能力而非系统故障。GitHub的基础设施和数据管道仍在按设计正常运转，但涌入公告的复杂性和规模已超出系统原有设计容量。不同类型的公告审核成本差异显著——如果提交者提供了清晰的包名、版本范围和修复方案，一条公告几分钟就能审完。棘手的是那些“问题报告”：跨生态的包名歧义需要厘清、缺失的版本数据需要重建、上游来源矛盾信息需要人工甄别。

一个典型场景是，一个共享库中的漏洞可能同时影响npm和NuGet包，需要分别在两个生态中独立核验。还有的时候，CVE记录与仓库提交数据不一致，管理者只能逐一手动确认真实的受影响范围。这些都需要耗费专业人力去逐条追查，而目前的审核流程难以规模化加速。

面对压力，GitHub的应对思路是三线并进：优化分流系统、扩展后端处理能力、部署AI辅助研究工具。AI的定位是接管重复性任务，关键验证环节仍保留人工把关。公司还在推进生态数据预计算、升级通知识别机制，并在全流程中嵌入更丰富的元数据。据透露，多个国家级漏洞库和关键开源项目正在与GitHub推进数据互认和联邦管理，尝试从根本上扩大整个漏洞处理体系的吞吐上限。