“黑色十月”：AI挖出史上3%严重漏洞？

最近 Reddit 上有一个帖子引发了不少讨论，标题相当抓人眼球：「有记录以来所有严重软件安全漏洞的 3%，都是在过去一个月里发现的」，发帖人将其称为「黑色十月」（Black October）。这个说法听起来像末日预言，但也可能指向一个更值得认真对待的趋势：AI 正在以远超人类的速度挖掘出长期潜伏的漏洞。

“3%”这个数字是怎么来的？

原帖并没有给出详细的数据来源或统计口径，更多是一个耸动的断言。要理解它是否可信，需要先拆解几个关键问题：

• “有记录以来”指什么？ 是 CVE 数据库、NVD，还是某个厂商的内部漏洞库？不同数据库的收录标准差异巨大。
• “严重”如何定义？ 是按 CVSS 评分 ≥9.0，还是按厂商自定的 critical 等级？口径不同，分母可能差出一个数量级。
• “过去一个月”的统计窗口 是否包含了集中披露的批量漏洞？安全社区偶尔会出现厂商集中修复、集中公告的情况，容易造成短期峰值。

在没有明确方法论的前提下，「3%」更适合被理解为一个信号而非精确统计——它反映的是漏洞发现速度正在发生结构性变化，而不是一个可以直接引用的行业数据。

CVE 与 NVD 的关系值得先厘清：CVE（Common Vulnerabilities and Exposures）是一套漏洞编号体系，由 MITRE 维护，每条记录只包含唯一标识和简短描述；NVD（National Vulnerability Database）则由 NIST 运营，在 CVE 基础上补充 CVSS 评分、受影响产品配置（CPE）和参考链接等结构化信息。两者收录节奏并不同步，一个 CVE 从分配编号到进入 NVD 完成评分，常有几周甚至数月的延迟。因此任何以「过去一个月」为窗口的统计，如果混用两个库的收录时间，结果会出现明显偏差。

CVSS 评分的含义也常被误读。CVSS（Common Vulnerability Scoring System）当前主流版本为 3.1，基础分 0–10，其中 9.0–10.0 定义为 Critical。但 CVSS 衡量的是漏洞本身的技术严重性，并不反映某个具体组织是否真的暴露、是否已被利用。同样一个 9.8 分的漏洞，在无网络暴露的内网系统上风险远低于面向公网的边缘设备。这也是文章后文强调「基于实际暴露面排序」的原因。

为什么漏洞发现速度会突然加快？

抛开具体数字，近期漏洞披露节奏加快有几个可以观察到的推动因素。

AI 辅助代码审计的普及

大模型被越来越多地用于代码审查和模糊测试（fuzzing）。相比人工审计，AI 可以 7×24 小时扫描海量代码库，并且不会因为疲劳而漏掉边界条件。一些安全团队开始用 LLM 对历史代码做批量复查，过去几年没人细看的遗留模块被重新翻了出来。

模糊测试（fuzzing） 是理解这一节的关键背景。其基本思路是向程序持续输入大量随机或半随机构造的数据，监控程序是否崩溃、断言失败或出现异常行为，从而定位潜在的内存越界、空指针、解析错误等问题。传统 fuzzing 依赖覆盖率反馈（如 AFL 使用的边覆盖插桩）来引导变异方向，效率高但需要较长时间运行和较好的种子语料。

大模型的介入改变了其中两个环节：一是种子生成，LLM 可以根据函数签名和代码语义直接构造出格式合法、能深入解析逻辑的输入，减少随机变异在格式校验处被拦下的浪费；二是崩溃归因，面对大量 crash 样本，模型可以快速聚类并判断哪些源于同一根因、哪些具备安全影响，把人工 triage 的工作量压下来。需要注意的是，fuzzing 擅长发现「程序做不到什么」（崩溃类缺陷），而对权限校验缺失、越权访问这类逻辑漏洞基本无能为力，这正对应了文中提到的 AI 与人类判断的互补关系。

自动化工具的门槛下降

漏洞挖掘不再只是少数顶尖研究员的专利。自动化扫描工具、开源 fuzzing 框架和 AI 辅助的 PoC 生成，让更多开发者能参与到漏洞发现中。发现能力的“民主化”直接推高了披露数量。

厂商响应流程的成熟

越来越多的厂商建立了漏洞赏金计划和快速响应通道，漏洞从发现到公开的周期被压缩。过去可能被压在内部几个月的 issue，现在更快进入公共视野。

漏洞赏金计划（bug bounty） 与 CVD（协同漏洞披露） 是这一节背后的制度基础。赏金计划由厂商设立，按漏洞 severity 向外部研究者支付奖金，HackerOne、Bugcrowd 等平台承担了撮合与托管角色。CVD 则指研究者发现漏洞后先私下报告厂商，双方约定一个修复与公开的时间窗口（常见为 90 天，即 Google Project Zero 推行的披露政策），到期后无论是否修复都对外公开。

这套机制的副作用正是文章所说的「集中披露」：当多个厂商采用相近的 90 天窗口，且恰好都在同一时段到期，公共渠道就会出现漏洞公告的短期峰值，容易被误读为「漏洞突然变多了」。此外，CNA（CVE Numbering Authority）制度让越来越多的厂商可以自行分配 CVE 编号，收录门槛下降也使总量数字抬升。评估任何「漏洞激增」的说法时，这些流程性因素都需要先被剥离出去。

这对开发者和企业意味着什么？

如果漏洞发现速度真的进入了新的量级，传统的安全管理节奏会承受压力。

第一，补丁窗口在缩短。 当漏洞披露更密集，攻击者利用 AI 分析补丁、逆向出 exploit 的速度也在提升。企业需要把「发现—评估—修复」的闭环做得更快，而不是等到季度安全审计。

第二，遗留代码的风险被重新定价。 那些多年无人维护的模块，过去因为「没人看所以没人打」的侥幸正在失效。AI 扫描不会放过它们。

第三，安全团队需要新的分流机制。 漏洞数量上升不等于每个都值得立即处理。基于实际暴露面和利用条件的优先级排序，会比单纯看 CVSS 分数更重要。

补丁窗口在业界常以「补丁发布到在野利用出现的时间差」来衡量，这一指标近年持续收窄，部分高危漏洞在补丁发布后数天内就出现公开 PoC。攻击者借助 AI 做补丁 diff 分析（对比修复前后的代码差异反推漏洞点）已成常规手法，这使得「先观察再打补丁」的策略风险显著上升。

与之对应的是 SBOM（软件物料清单） 的推广。SBOM 以标准化格式（如 SPDX、CycloneDX）列出软件包含的全部组件及版本，使企业能在新漏洞公布时快速判断自身是否受影响，而不必逐个仓库人工排查。在漏洞披露密度上升的环境下，SBOM 加上依赖自动更新，构成了「发现—评估—修复」闭环能否提速的基础设施前提，也直接回应了文章对遗留代码风险重新定价的判断。

需要保持的怀疑

回到「黑色十月」这个说法本身，它更像是一个社区梗而非严谨结论。原帖没有提供可复现的统计方法，3% 这个比例也无法独立验证。把它当作一个提醒是合理的：漏洞发现的供给侧正在变化；但把它当作既定事实去引用，则有夸大的风险。

真正值得关注的不是某个具体百分比，而是发现能力提升之后，修复能力能否跟上。如果发现速度提升了一个数量级，而修复流程还是老样子，那才是真正需要担心的事。

常见问题

这个「3%」的数据可信吗？

目前没有公开的方法论支撑，建议将其视为社区讨论中的夸张表述，而非行业统计。

AI 真的能发现人类漏掉的漏洞吗？

在模式匹配和批量扫描上，AI 有明显优势；但在需要业务上下文理解的逻辑漏洞上，仍依赖人类判断。两者是互补关系。

普通开发者应该做什么？

保持依赖库更新、关注所用框架的安全公告，并对自己维护的代码做定期的自动化扫描，是当前最实际的动作。