90 天披露政策已失效

90 天披露政策已失效 2026-05-09 :: [更新 :: 2026-05-09] Himanshu Anand :: 14 分钟阅读（2846 字） # security # llm #披露 # 漏洞管理 # linux # blog 目录 TLDR ⌗ 90 天负责任的披露窗口是为错误发现者很少且漏洞利用开发缓慢的世界而建立的。那个世界已经消失了。法学硕士已将这两个时间表压缩到接近于零。我亲眼目睹了这一点，其他人也都在关注。这篇文章用真实的故事阐述了旧模式为何被打破，并向业界提出要求：将每个关键安全问题视为 P0 并立即修补。不是明天。不是下一个冲刺。现在。我从事安全工作已经有一段时间了，过去 12 个月的感觉有所不同。不是以“人工智能将接管世界”的方式。以一种更无聊、更实用的方式。我们使用的工具、攻击者使用的工具以及研究人员用来查找错误的工具都以大致相同的速度变得更加智能。这悄然扼杀了安全行业十多年来一直赖以运行的一些基本假设。让我用故事来解释我的意思。旧世界（安息吧）⌗ 假设现在是 2019 年。您发现了一个严重的错误。你写一份报告。您将其发送给供应商。供应商需要几天的时间来分类，几周的时间来修复，可能需要一个月的时间来推出。如果您遵循 Google 零项目风格的披露，则需要在公开之前给他们 90 天的时间。在这 90 天里，你假设： 你可能是唯一发现这个 bug 的人 即使其他人发现了它，他们也会花自己的时间 供应商在编写补丁方面有一个轻松的开始 补丁发布后，攻击者需要几天或几周的时间才能将其逆向工程为有效的漏洞 现在这些假设中的每一个都是错误的。故事 1：10 个人，1 个 bug，6 周 ⌗ 4 月底，我向一家公司报告了一个非常严重的 bug。我对细节保持模糊，因为问题仍然没有得到修补，但它的形状是这样的：攻击者可以从网站购买任何东西，将他们自己制作的响应发送回服务器，并且由于响应上没有签名验证，服务器很乐意接受它。以 0 美元购买 5000 美元的商品。将您的购买标记为已完成，无需付款。关键，容易被利用，对公司来说是非常糟糕的一天。凉爽的。我写下来，寄出去，我自我感觉良好大约 10 分钟。然后分诊小组回来说：“是的，我们知道，第一次报道是在三月份。你是十一号记者。”十一名该死的人在大约六周内发现了同样的严重错误。 BlueWater CTF 的一位朋友几个月前就指出了这种模式，即法学硕士协助的猎人几乎同时通过完全不相关的记者使用完全不相关的工作流程来发现相同的错误。而且不仅仅是我注意到这一点。在分类方面工作的 @d0rsky 发布了这样的内容：“一旦发现新的漏洞 - 特别是通过一些 LLM 提示/技能/自动化，我们会在几天内开始收到一波重复的报告。相同的根本原因，略有不同的措辞。[...]更让我担心的是，如果研究人员能够如此迅速地复制这些发现，那么在问题得到解决之前，是什么阻止黑帽做同样的事情？感觉‘第一次发现’和‘大众意识’之间的窗口正在变得危险。短。”确切地。分诊团队也看到了这一点。这不是研究人员的偏执。这是一种模式。起初我想，好吧，相同的工具，相同的提示，很有意义。但后来我做了令人不舒服的数学计算。如果有 10 个人报告了该错误，有多少人发现了该错误但没有报告？帮助了 10 名诚实的研究人员的法学硕士也可供其他人使用。它不会在门口检查你的意图。在这 10 名记者中，只有 1 名获得了 CVE 荣誉。只有 1 人获得赏金。那其他9个呢？有多少人感到沮丧？有多少人决定出售而不是等待？而那些根本没有报告过此事的人——他们并没有坐在 90 天的时钟上。他们没有坐在任何时钟上。 90 天的窗口并不能保护用户。它为每个已经遇到该错误的人提供了 90 天的先机。故事 2：从修补到利用仅 30 分钟 ⌗ 最近，React 修补了一系列安全问题（ CVE-2026-23870 、 CVE-2026-44575 、 CVE-2026-44579 、 CVE-2026-44574 、 CVE-2026-44578 ），并就此撰写了一篇公共博客文章。标准做法。展示您的工作，解释修复方法，向社区通报。我出于好奇读了这篇文章。然后我想，让我看看将这个补丁变成一个有效的漏洞有多么困难。只是在我自己的机器上针对本地测试应用程序进行的实验。 30分钟。从阅读补丁到获得有效的利用（DOS，因为它只是 DoS）。人工智能完成了大部分繁重的工作：理解差异、识别易受攻击的代码路径、编写 PoC。已发布的问题是拒绝服务，但底层原语可能会