跳转至

score by collisions, patch by panic

Ch04.466 score by collisions, patch by panic

📊 Level ⭐⭐ | 7.9KB | entities/blog-himanshuanand-com-score-by-collisions-patch-by-panic.md

score by collisions, patch by panic

摘要

本文是 blog.himanshuanand.com 为前作《90 天披露政策已死》写下的落地提案：用"碰撞计数"（collision count）驱动漏洞严重性分级，用"附补丁的报告"取代空报告，用"假设 exploit 先于补丁到达"的架构设计取代补丁竞速。作者援引 Linus Torvalds 在 LKML 的表态与 Searchlight Cyber 的 cPanel 0day 案例，论证 AI 辅助漏洞挖掘已把安全生态推向"多人同发现"的竞争格局。

核心要点

  • 严重性由碰撞计数驱动：同一漏洞被两个以上无关研究者报告即上调一级；附可用 exploit 为 Critical（补丁窗口从周级缩到天级）；exploit + 公开 PoC 为 P0，立即停产修复
  • Linus 的"AI 发现 = 他人也发现"论断：用 AI 工具找到的 bug，大概率已有人捷足先登，这是碰撞模型成立的前提
  • Searchlight Cyber cPanel 案例：拥有数年目标经验、定制化反编译工具链的顶级团队，仍被威胁行为者抢先两个月，说明"已有人在野利用"是默认假设而非悲观假设
  • 研究者应提交补丁而非仅提交报告：附补丁的报告修复更快，并为下一次走进该厂商收件箱积累信任资本
  • AI 吃掉金字塔底部：Pwn2Own 上 Orange Tsai 的纯逻辑漏洞利用链证明，需要数月上下文与系统直觉的高端研究仍属人类
  • 企业基础防御：停用 npm update 自动模式、纵深防御、镜像生产的验证部署、持续运行时校验、预构建虚拟补丁与零日剧本
  • 企业进阶防御：默认封锁出口流量、12-24 小时回收的临时架构、rootless 容器与 seccomp 过滤、以特性开关作为安全断路器

深度分析

碰撞计数：从定性判断到情报驱动的概率分级

文章的分级模型本质上是把严重性从"单点事件"改写为"竞争情报"：当两个无关研究者独立发现同一缺陷，意味着该缺陷被第三方（包括攻击者）掌握的概率显著上升，补丁窗口必须随之收缩。这与传统 CVD 模型的"唯一发现者"假设形成鲜明对比——后者把披露节奏交给厂商单方面决定。Linus 在 LKML 上的表态为碰撞模型提供了权威注脚；Searchlight Cyber 的 cPanel 案例则给出实证：一个能在预认证阶段以 root 权限读取任意文件（CVE-2026-29205）、拥有数年积累与定制化 Perl 反编译工具链的团队，依然比未知攻击者晚两个月。在这个量级的团队都会迟到的情况下，竞争状态已是常态而非例外。

独立研究者的结构性困境与信任资本

碰撞模型最棘手的问题是信息不对称：独立研究者没有遥测、没有客户日志、没有威胁情报源，无法判断自己报告的 bug 是否已在野被利用。作者给出的务实策略是"假设最坏"——默认你不是唯一发现者，尽快提交报告并施压缩短披露窗口，厂商拖延则把责任抛回厂商。与此同时，Linus 对 drive-by 报告的批评揭示了另一条生存策略：读文档、写补丁、在 AI 输出之上增加真实价值。附补丁的报告不仅修复更快，还能积累"信任资本"——下一次走进该厂商收件箱时，这封信会被优先对待。这实质上是把研究者的竞争力从"发现速度"转向"交付质量"。

企业侧：补丁竞速时代结束，架构免疫时代开始

文章坦承对企业的建议"没有捷径，只有做更多工作"。基础层解决已知风险的管理：停用 npm update 自动模式（锁定版本、读 changelog、审查 diff）、纵深防御（单一控制必然失效）、镜像生产环境的验证部署、把安全从发布时刻事件变为持续运行时校验，以及预构建虚拟补丁/WAF 规则与零日剧本——把谁主持会议、谁写 WAF 规则、谁联系厂商、谁告知客户、谁翻转特性开关在事件前写死，因为事件中的任何决策都在浪费最初的黄金四小时。进阶层则针对"exploit 已落地"的世界：默认封锁出站流量，让 C2 回连失败即利用失败；12-24 小时强制回收的临时架构让后门在午夜随干净镜像蒸发；rootless 容器与 seccomp/AppArmor 系统调用过滤把 web 服务的权限压制在内核层；以及借鉴金融熔断机制的架构断路器——异常流量自动隔离到独立 VLAN 并呼叫值班人员，特性开关让晚上 9 点的厂商公告变成一次翻转而非一次紧急部署。

AI 攻防的演进方向与边界

文章对"LLM 是否触顶"的回答是"可能，像 fuzzer 一样"——AFL 曾横扫简单 bug，资源耗尽后工作向栈上迁移，LLM 很可能重演这一曲线：金字塔底部被淹没，顶部依旧艰难，中间地带是军备竞赛的主战场。关于误报率，作者认为"今天真实，但每个月都在变好"，正确姿势是在 LLM 之前堆叠确定性 SAST 工具压低噪声底，让 LLM 扮演"从代码中筛出人类今天该看的十件事"的过滤器而非替代者。值得注意的是，作者承认闭源软件的问题更严重——前沿模型已擅长反编译二进制分析，固件 diff 正变成补丁分析练习，"通过隐匿实现安全"的缓冲也在收缩；形式化验证虽对内核、加密与认证层值得投入，但对下个 sprint 的微服务并不现实。最终判断是：在 10x/100x 漏洞数量的世界里，自动化最快的一方获胜，而目前占优的是攻击方。

实践启示

  1. 把碰撞信号接入分级流程：同一漏洞收到第二个独立来源的报告时，不等完整情报确认即自动提升响应优先级，将碰撞计数作为 CVSS 的补充输入而非替代
  2. 默认假设"已有人在野"：无论是否看到利用证据，都按最短窗口准备补丁与缓解；独立研究者应尽快提交报告并明确要求短披露窗口，厂商拖延即公开升级
  3. 提交补丁而非空报告：开源项目直接读代码、找修复、发 PR——即使错误的补丁也给了维护者一个起点，空白报告则什么都不是；同时积累与该厂商的信任资本
  4. 事件前写死零日剧本：明确谁主持、谁写 WAF 规则、谁联络厂商、谁沟通客户、谁翻转特性开关，避免在事件发生后的最初四小时内做任何决策
  5. 默认封锁出站流量并预埋特性开关：对每个高风险第三方集成包装 flag，出站仅允许名单化域名——exploit 触发但回连失败，利用即失败
  6. 以临时架构对抗持久化：容器 12-24 小时从干净镜像重建，配合 rootless 与 seccomp——攻击者下午 3 点写入的后门，午夜随盒子回收而蒸发，多数攻击者会在重复利用中放弃

相关实体

→ 原文存档