Google Project Zero 宣布调整漏洞披露政策，2026 版因 AI 加速攻击而收紧修复时限

自2021年以来，Project Zero一直遵循“90 + 30”漏洞披露政策，允许厂商最多用90天修复漏洞，外加30天的补丁推送“浸泡期”。我们的目标是推动更快的修补，并给厂商时间将补丁交付给用户。AI辅助的漏洞发现与利用的出现改变了威胁格局，使得我们披露政策所鼓励的漏洞修复时间线明显不足。

LLM加快了攻击者发现和利用漏洞的速度，同时也增加了多方（包括恶意方）发现同一漏洞的风险。今天报告的漏洞对用户构成的即时风险远高于去年报告的漏洞。在这种新环境下，厂商必须更快地修复漏洞。

LLM还缩短了攻击者根据补丁逆向工程并利用漏洞所需的时间，以至于“零补丁到利用时间”已成为对攻击者行为的一个合理（尽管并不完美）的模型。在攻击者几乎可以立即从补丁中确定漏洞细节的世界里，补丁浸泡期已不再有意义，反而会通过制造虚假的保密感将用户置于风险之中。“补丁差距”是指安全漏洞的修复程序发布到用户安装相关更新之间的时间。同样关键的是，厂商必须缩短补丁差距，无论是通过减少补丁推送时间，还是在修复进行期间采用其他策略保护用户。

LLM还增加了Project Zero报告的漏洞数量。我们曾经一年在目标中发现几个漏洞，现在每周就能发现几个。我们政策中需要与厂商协商或达成一致的部分，包括确定漏洞是否已修复以及宽限期是否适用，正迅速变得难以管理。

今天，我们宣布一项新的漏洞披露政策，其制定基于以下目标： 漏洞将在报告给厂商X天后披露。 从今天起，我们的政策是“Full 90”，即漏洞在报告给厂商90天后披露。 2027年2月2日，我们将转向“Full 60”政策，漏洞在60天后披露。 2028年1月3日，我们将转向“Full 30”政策，漏洞在30天后披露。 我们还将从披露政策中移除大多数“特殊情况”，包括宽限期和变体政策。新政策的唯一例外是： 在制定这项新政策的过程中，Project Zero向我们所报告漏洞最多的厂商征求了反馈。一个首要的担忧是，立即改变政策可能会伤害用户，因为在厂商改进其修复流程和技术的过程中，未修复的漏洞会暴露给攻击者。尽管延迟披露的好处正在下降，因为攻击者在禁令期内发现漏洞的概率增加了，但我们仍然认为短期内仍有好处。

此外，厂商还提到了两个更微妙的担忧。其一是，过于激进的披露政策会鼓励厂商优先修复根据新政策报告的漏洞，即使这些漏洞不如其他已报告的漏洞严重。其二是，立即执行一些厂商无力满足的政策，可能导致厂商接受他们无法在截止日期内修复漏洞，从而放弃尝试。

我们决定采用一项政策，鼓励厂商按照一个有挑战性但现实的时间表改进修复时间，希望这能促使厂商广泛改进其修复流程和基础设施，最终使他们能够快速修复所有报告的漏洞。

虽然我们的分析并不总是完美，但Project Zero只在我们追踪器中报告具有严重性和已证明安全影响的漏洞。话虽如此，我们认为严重性并不是做出披露决定的有效指标，尤其是在当前环境下。漏洞的严重性不影响其被攻击者发现的概率，只影响其对用户的影响。

当厂商确定严重性并以此确定漏洞修复优先级时，他们是在决定愿意让用户暴露于哪些风险之中，在很多情况下接受低严重性漏洞的风险是合理的，例如不可利用的空指针崩溃或轻微信息泄露。但这并不改变这些漏洞对攻击者的可用性，我们希望我们的政策能反映这一现实。

同样重要的是要承认，Project Zero在报告的漏洞的可复现性、可读性、可达性和所报告的安全影响方面对自己要求很高。该政策假设漏洞报告具有这样的质量，厂商对低质量漏洞报告区别对待是合理的。

我们鼓励所有厂商考虑如何应对严重漏洞即将被披露的情况，包括非补丁策略，因为不能保证防御者会首先发现漏洞。话虽如此，Project Zero偶尔会在极少数情况下对我们的政策给予例外，包括Spectre和Meltdown，未来也将继续这样做。

（原文较长，此处译出前 6000 字，完整内容请点「打开原文」。）