摘要

  • 10 月 30 日的 EEF 官方 CVE 索引中，2026 年记录有 370 条，2025 年有 9 条。公开记录数量约增至 41 倍；这不是修复数量，也不是 AI 发现数量。
  • Alistair Woodman 在 RIPE 93 预计 2026 年 CVE 将超过 500 条。他谈到发现之后更费人的一步：让软件包维护者核实问题、修补代码并验证结果。

数字在往上走，修复用了多久，公开数据没有计时。

Erlang Ecosystem Foundation 的机器可读 CVE 索引，在 10 月 30 日 08:59 UTC 时列出 370 条发布日期为 2026 年的记录；2025 年的记录有 9 条。公开记录数约为上一年的 41 倍。索引没有逐条说明受影响的软件包是否已发布经验证的修复，也没有给出维护者完成修补用了多长时间。

三天前，Woodman 在 RIPE 93 安全工作组给出年度预估。他说，EEF 覆盖超过 20,000 个 Elixir、Erlang 和 Gleam 软件包；基金会估计有约 100,000 名常用用户，并已知至少 5,000 家企业用户。上一年大约记录了 10 个 CVE；他预计 2026 年将超过 500 个。他把这称为负荷增长 50 倍，并说这些漏洞原本就存在，只是 AI 辅助分析让它们更容易浮出水面。

EEF 是 CVE 编号机构，由其安全工作组为范围内的项目分配编号并协调披露。Woodman 描述的团队有 5 名负责人，其中两人承担大部分 CVE 处理和 AI 研究。工具可以很快找出线索；维护者还得判断问题是否成立、修改代码、发布版本，再确认修改确实解决了问题。

这里就是计数器与安全结果分道的地方。Woodman 说，EEF 正尝试按项目把报告打包处理。这样就不必每出现一条新线索便打断维护者，而可以留出一段时间集中处理一批问题。这是在回应人手约束：发现工作可以并行，修复仍离不开熟悉项目代码的人。

EEF 公布的政策承诺在两个工作日内确认收到报告，并在确认后两个工作日内评估其有效性和影响。对于范围内 Hex 软件包的非公开漏洞，如果维护者 14 天不回应，CNA 表示会继续发布 CVE；协调披露最长可持续三个月。这些规则为接收和披露设了时间点，却没有测量发现漏洞到发布修复版本之间的时间。

EEF 的公开索引记录 CVE 编号、标题、详情以及发布日期或更新时间。它没有逐条公开维护者响应、修复版本和验证用时。补上这组修复记录，才能看出披露量增长时，实际暴露是否也在同步缩小。

Woodman 是 EEF 董事会成员，并呼吁依赖该生态的软件公司为安全工作提供资金。账面关系并不复杂：成千上万的组织可以使用开放软件包，少数安全团队和维护者却承担了很大一部分披露与修复工作。公开 CVE 是一个有用的提醒；下一个有用的数字，是那个真正包含修复的版本。

来源：RIPE 93 场次；官方文字稿；EEF 的 CNA 介绍、覆盖范围、安全政策及 CVE 索引；EEF 董事会名单。