碰撞评分，恐慌补丁

# 按碰撞次数评分，靠恐慌打补丁 来源：https://blog.himanshuanand.com/2026/05/score-by-collisions-patch-by-panic/ ## TLDR;⌗ (https://blog.himanshuanand.com/2026/05/score-by-collisions-patch-by-panic/#tldr) 按碰撞次数评定严重等级。研究人员提交的不只是报告，还有补丁。企业为这样一个世界重新设计架构：漏洞利用代码比补丁更早落地。没有魔法，没有厂商推销。只有操作手册。 --- 前一篇文章 (https://blog.himanshuanand.com/2026/05/the-90-day-disclosure-policy-is-dead/)的热度超出了我的预期。NYT 的 Hard Fork (https://www.nytimes.com/2026/05/15/podcasts/ai-safety-is-so-back-mythos-mayhem-with-nikesh-arora-hot-mess-express.html) 引用了它。Lobsters (https://lobste.rs/s/qxkdgl/90_day_disclosure_policy_is_dead) 上的讨论提出了尖锐的问题。有些人说得很有道理：“模型坏了”是抱怨，不是提议。 所以，这是我的提议。 ## 新的严重性模型⌗ (https://blog.himanshuanand.com/2026/05/score-by-collisions-patch-by-panic/#a-new-severity-model) 当前的模型把每份报告都当作孤立事件处理：一个报告者，一个漏洞，一条时间线。旧的操作手册基于这个假设运行。但这个假设已经不再成立。以下是 2026 年严重性应有的样子： **单报告者 + 无漏洞利用。**标准严重性。标准窗口期。一切照常。 **两个或更多报告者发现了同一个漏洞。**严重性升一档。如果互不相关的研究人员都发现了同一个缺陷，那么不太友善的一方很可能也已经发现了。缩短窗口期。 **附带了可工作的漏洞利用代码。**严重。补丁窗口从几周缩短到几天。 **可工作的漏洞利用代码 + 公开的 PoC。**P0。立即停止所有工作，打补丁。 碰撞次数就是信号。利用好它。 上周 Linus 在 LKML (https://lkml.org/lkml/2026/5/17/896) 上说出了那个大家都知道但不敢明说的事实： > 所以我说清楚一点：如果你用 AI 工具发现了漏洞，别人很可能也发现了。 如果你还需要证据，Searchlight Cyber 对 cPanel 的分析 (https://slcyber.io/research-center/new-age-of-collisions-reading-arbitrary-files-pre-auth-as-root-in-cpanel-cve-2026-29205/) 比我解释得更好。强大的团队，多年的目标经验，真正的先发优势，定制的逆向工具把 cPanel 的 Perl 二进制文件反编译回源代码。即便如此，他们还是被某个威胁行为者抢先了两个月。整整两个月。 如果一个达到这个水平的团队都能落后，那么数学对所有参与者来说都已经变了。 panik kalm panik ## 独立研究者的问题⌗ (https://blog.himanshuanand.com/2026/05/score-by-collisions-patch-by-panic/#the-independent-researcher-problem) 这是我的提议无法干净解决的问题。 如果你是一个独立研究者，你没有遥测数据、没有客户日志、没有威胁情报源。你发现了一个漏洞，提交了报告，然后坐等。你根本不知道在你等待期间，这个漏洞是否已经在野外被利用。我没有完美的解决方案，我能提供的最好建议是：做最坏的打算——假设你不是唯一发现它的人。提交报告，并强烈要求缩短窗口期。如果厂商拖延，那就是厂商的问题了。 Linus 的另一些话也值得全文引用： > 如果你真的想增加价值，去读文档，顺便也做一个补丁，在 AI 所做的基础上增加一些真正的价值。不要做那种“随机发送一份报告，没有真正理解”的人。 我也曾是那种“过客式”的人。你发现了一个漏洞，知道了影响，就想打包走人，继续下一件事。但是，附带了补丁的报告总是能更快被修复，而且这能建立信任，下次你走进那个收件箱时对方会更重视你。 如果项目是开源的，读代码，找到修复方法，发个 PR。即使补丁写错了，也能给维护者一个起点。空白页面什么都给不了。 ## 给那些感到无力的漏洞猎人⌗ (https://blog.himanshuanand.com/2026/05/score-by-collisions-patch-by-panic/#for-the-bug-hunters-who-feel-cooked) 我理解你——重复报告到处都是，赏金池越来越小，模型出货速度比你周末项目的进展还快。 看看今年的 Pwn2Own 吧。Orange Tsai 放出了一条完整的攻击链。全是逻辑漏洞，没有内存损坏，没有 LLM 参与，也没有碰撞。 > 这是我的攻击链！一条仅用逻辑漏洞的完整攻击链！没有内存损坏，没有 AI，当然也没有碰撞。@orange_8361 (https://x.com/orange_8361/status/2054906050143240399) Orange Tsai P2O 推文 技能天花板仍然在那里。LLM 吃掉的是金字塔的最底层。那些需要三个月上下文、古怪直觉和对系统行为深刻理解的工作，依然非常人类。磨尖你的技能。 隧道尽头有光。目前还不太亮——也许是当前霍尔木兹海峡局势造成的。但它确实存在。 ## 给企业⌗ (https://blog.himanshuanand.com/2026/05/score-by-collisions-patch-by-panic/#for-the-corporates) 这部分会有点痛，因为答案是“多做工作”。我没有捷径。 你的代码是你的，但你的依赖不是。你的依赖的依赖肯定不是。你的技术栈所运行的世界，现在有了自动化的漏洞发现工具，而且每个季度都在变得更好。你的计划必须考虑到这一点。 ### 基础部分⌗ (https://blog.himanshuanand.com/2026/05/score-by-collisions-patch-by-panic/#the-basics) 如果你还没有做到这些，从这里开始。 **停止自动运行 `npm update`。**供应链是真风险，不是幻灯片上的风险。锁定版本，读变更日志。在接受之前先扫描差异。下一个被篡改的包已经在某个人的仓库里了。 **纵深防御。**一层控制一定会失效，永远是这样。下一层需要兜住它。如果你唯一的保护是“WAF 会挡住它”，那你只有一层控制。 **部署前验证。**每个环境都要做。与生产环境不一致的预发布环境就是安慰剂。真正击中生产的漏洞，恰恰是预发布环境里不存在的那一个。 **持续运行时验证。**别再像对待发布时刻事件一样对待安全。在生产环境中运行检查。实时的。一直运行。 **虚拟补丁和 WAF 规则。**当某个 CVE 曝光，而你在四小时内无法打补丁时，你需要一条规则来争取时间。提前构建这个能力。不要在事件发生时才发明它。 **零日应急手册。**在需要之前就写好。谁主持电话会议？谁写 WAF 规则？谁联系厂商？谁通知客户？谁切换功能开关？如果你在事件发生时还在决定这些，那前四个小时你已经输了。 ### 更难的部分⌗ (https://blog.himanshuanand.com/2026/05/score-by-collisions-patch-by-panic/#the-harder-stuff) 如果基础部分你已经做到了，接下来是这些。 #### 1. 默认锁定出站流量⌗ (https://blog.himanshuanand.com/2026/05/score-by-collisions-patch-by-panic/#1-egress-lockdown-by-default) 每个人都在痴迷于入站流量——阻止坏人进来。但当零日漏洞在第三方包里爆发时，攻击者已经进来了。 接下来他们做什么？连接 C2 服务器，拉取载荷，窃取数据。 所以让这一切变得不可能。 默认阻止所有出站互联网。把每个微服务都当作敌对实体。如果某个服务需要与支付网关通信，只允许那个确切的域名。别的都不行。如果漏洞利用触发了，但回连失败，那么漏洞利用就失败了。 #### 2. 临时架构（烧掉它）⌗ (https://blog.himanshuanand.com/2026/05/score-by-collisions-patch-by-panic/#2-ephemeral-architecture-burn-it-down) 攻击者喜欢持久化。一旦他们利用了一个零日漏洞，他们想要一个立足点、一个后门，以及环顾四周的时间。服务器存活得越久，泄露的信息就越多。 把服务器当作牲畜而不是宠物来对待。 牲畜，不是宠物 **积极回收。**容器和实例每 12 到 24 小时就从干净的镜像销毁并重建，没有例外（不要说“但我们的服务很特殊”）。 **不可变基础设施。**在运行的机器上不做任何持久化更改。如果攻击者在下午 3 点写入了后门，它在午夜时就会被蒸发——因为机器会从干净的镜像替换。攻击者必须每个周期都重新利用漏洞。大多数操作者会在你之前放弃。 #### 3. 沙箱运行时环境⌗ (https://blog.himanshuanand.com/2026/05/score-by-collisions-patch-by-panic/#3-sandbox-the-runtime) 如果攻击者利用了一个 Web 应用里的零日漏洞，他们就会继承运行该应用的用户权限。如果那个用户是 root，他们就控制了整台机器。所以不要以 root 身份运行。 **无根容器。**任何应用都不应该以 root 身份运行，句号。如果你的容器发行版里设置了 `USER root`，本周就把这个改掉，优先级高于此列表上所有其他项。 **系统调用过滤。**使用 seccomp 或 AppArmor。一个 Web 服务器没有理由调用 `/bin/sh` 或挂载新的文件系统。在内核层面就阻止它。当零日漏洞试图 spawn 一个 shell 时，内核直接拒绝。 #### 4. 架构级断路器⌗ (https://blog.himanshuanand.com/2026/05/score-by-collisions-patch-by-panic/#4-architectural-circuit-breakers) 在金融领域，当一只股票跌得太快时，交易会暂停。软件也是同样的道理。 **自动隔离。**如果一个端点突然以正常速度一百倍地读取数据库，就把流量从它那里导走。将该容器隔离到一个单独的 VLAN 中。页面值班人员。不要等到凌晨 2 点有人注意到仪表板上的指标。 **安全功能开关（不仅是产品功能开关）。**把每个高风险第三方集成都用开关包裹起来。厂商在晚上 9 点宣布泄露。你拨动开关。该功能停止运行。业务的其他部分继续运行。无需紧急部署，无需凌晨 3 点的电话，一个开关就够了。 ## 我回避的问题⌗ (https://blog.himanshuanand.com/2026/05/score-by-collisions-patch-by-panic/#the-questions-i-dodged) Lobsters 讨论帖里有人问了真正的问题。让我在这里试着回答。 **“LLM 会不会在漏洞发现上遇到天花板？”**也许吧。Fuzzer 就遇到了。AFL 连续几年吞噬了所有低垂的果实，然后简单的漏洞被榨干了，工作向上层堆栈转移。LLM 可能也会经历同样的过程。金字塔底部被抽干，顶部仍然很难。中间层是军备竞赛的地方，而能更聪明地扩展规模的一方会获胜。 **“LLM 扫描器每发现一个真实漏洞就返回 400 个误报。”**今天是这样，但每个月都会改善。调整提示词。在 LLM 看到代码之前，先用一个确定性的 SAST 工具砍掉噪声地板。工作不是“LLM 取代人类”，而是“LLM 筛选出人类今天早上真正应该看的十件事”。 **“变更管理存在是有理由的。快速打补丁会出问题。”**这也是事实。诚实的回答是：在下一个零日漏洞到来之前，先为快速安全部署铺好轨道。金丝雀发布、自动回滚、功能开关、蓝绿部署。如果你的流水线需要六个小时而且没有紧急停止开关，那是一个独立的问题——无论行业采用什么样的披露模型，这个开关在事件当天都会害死你。 **“闭源软件怎么办？比如 Cisco 固件的 diff？”**问题更严重而不是更好。前沿模型在反编译二进制分析方面已经很强。并排比较固件 diff 就变成了补丁分析练习。“通过模糊实现安全”的缓冲也在缩小。 **“形式化验证呢？”**对于新代码来说有希望。但慢、贵。对于内核、加密、认证层来说是值得的。但对于你下个 sprint 就要发布的微服务来说不现实。把它用在最重要的地方。 **“当事故事件数量扩大 10 倍或 100 倍时，世界会是什么样？”**我不知道。但能最快实现自动化的那一方会赢。现在，进攻方在这样做。防守方必须缩小差距。 ## 最后的想法⌗ (https://blog.himanshuanand.com/2026/05/score-by-collisions-patch-by-panic/#final-thoughts) 按碰撞次数评定严重性。研究人员不仅提交报告，还提交补丁。企业为一个补丁在漏洞利用之后才落地的世界重新设计架构——而不是之前。 这些都不是免费的，这些都不会在下周就交付。但旧的操作手册已经回不来了。我们越快接受这一点，就越快开始构建新的手册。 这也行 如果以上内容引起了你的共鸣，联系我 (https://x.com/anand_himanshu)。如果你不这么认为——尤其要联系我。写这些的全部意义在于，在攻击者找到漏洞之前，先让别人帮我找出漏洞。 感谢阅读。