Project Zero 调整漏洞披露政策，缩短至报告后 90 天公开
自 2021 年起，Project Zero 一直执行“90+30”漏洞披露政策：供应商拥有最长 90 天时间来修复漏洞，随后还有额外的 30 天“渗透期”用于补丁分发。我们的初衷是敦促供应商加快修补速度，并为他们向用户推送补丁留出足够时间。然而，AI 辅助的漏洞发现与利用手段彻底改变了威胁态势，使得该政策所推荐的修复周期已明显不足。
LLMs 大幅提升了攻击者寻找和利用漏洞的速度，同时也增加了多方（包括恶意行为者）同时发现同一缺陷的风险。如今上报的漏洞对用户造成的即时威胁，远高于去年上报的情况。在这种新环境下，供应商加快漏洞修复至关重要。
LLMs 还缩短了攻击者根据补丁逆向工程并开发利用代码的时间，以至于“零补丁到利用时间”已成为一种合理（虽不完美）的攻击行为模型。在攻击者几乎能立即从补丁中获取漏洞细节、且虚假的秘密感会将用户置于险境的世界里，补丁渗透期已失去意义。“补丁间隙”指安全漏洞修复发布与用户安装相应更新之间的时间差。供应商必须努力缩小补丁间隙，无论是通过缩短补丁分发时间，还是采取其他策略在修复过程中保护用户。
LLMs 还增加了 Project Zero 报告的漏洞数量。我们在原本每年仅发现几个漏洞的目标中，如今每周都能找到几个。政策中需要供应商协商或达成一致的部分（如确认缺陷是否已修复、是否适用宽限期等），正迅速变得难以管理。
今天，我们宣布一项新的漏洞披露政策，其制定目标如下：
- 鼓励更快地修复漏洞
- 鼓励供应商缩小“补丁间隙”
- 允许该政策被 Project Zero 和供应商自动化执行
我们的新政策：“完整 X”
漏洞将在报告给供应商后的第 X 天被披露。
从今天起，我们的政策是“Full 90”，即漏洞在报告给厂商 90 天后公开披露。
2027 年 2 月 2 日起，我们将转为“Full 60”政策，漏洞在报告 60 天后披露。
2028 年 1 月 3 日起，我们将转为“Full 30”政策，漏洞在报告 30 天后披露。
我们还将从披露政策中移除大多数“特殊情形”，包括宽限期政策和变体政策。新政策的唯一例外是：
- 正被在野利用的漏洞——ITW 漏洞将按照 Google 的应用安全漏洞披露政策处理
- 已被公开的漏洞——如果漏洞细节已被他人公开，Project Zero 可自行决定是否公开相关细节
- 厂商要求——如果我们报告漏洞的厂商提出要求，我们会公开漏洞细节
为什么要逐步缩短修复期限？
Project Zero 在制定这项新政策时，向被我们报告漏洞最多的厂商征求了意见。厂商们普遍担心，如果立即改变政策，在厂商改进修复流程和技术的同时，攻击者可能利用尚未修复的漏洞，从而损害用户利益。虽然由于攻击者在保密期内发现漏洞的可能性不断提高，延迟披露的好处正在减少，但我们认为短期内仍有其价值。
此外，厂商还提到了两个更隐性的顾虑。一是过于激进的披露政策会促使厂商优先修复新政策下报告的漏洞，即使它们的严重程度低于其他已报告漏洞。二是如果立即强制执行某些厂商目前无力达到的政策，可能导致厂商干脆接受无法在期限内修复漏洞、也不再尝试的局面。
我们制定了一项政策，旨在鼓励供应商改进修复速度。我们设定的时间表具有挑战性，但也切实可行。我们希望这一举措能推动供应商全面优化其修复流程与基础设施，最终使其有能力快速修复所有已报告的漏洞。
严重性等级如何考量？
虽然我们的分析并非总是完美无缺，但 Project Zero 仅会在追踪系统中上报具备实质性严重性且已证实安全影响的漏洞。不过，我们认为在当前的环境下，以严重性等级作为披露决策的依据并不有效。漏洞的严重性并不会影响攻击者发现它的概率，只影响其对用户的实际损害。
当供应商根据严重性等级来安排修复优先级时，他们实际上是在决定愿意让用户承担多大的风险。在许多情况下，接受低严重性漏洞的风险是合理的，例如无法利用的空指针崩溃或轻微的信息泄露。但这种情况并不会改变攻击者获取这些漏洞的难易程度，我们的政策旨在反映这一现实。
我们也必须承认，Project Zero 对所报告漏洞的可复现性、可读性、可达性及已报告的安全影响有着极高的标准。该政策假设漏洞报告符合这一质量标准，因此供应商区别对待低质量漏洞报告也是合理的。
硬件方面呢？
我们鼓励所有供应商考虑如何应对紧急披露的严重漏洞，包括非补丁类的策略，因为防御者并不一定总能最先发现漏洞。话虽如此，Project Zero 曾在极少数情况下（如 Spectre 和 Meltdown）为该政策设立例外，未来也会继续如此。
你们真的不检查漏洞是否已修复吗？
按照我们的政策判断一个漏洞是否算“已修复”，一直是个难题，也没有明确的标准，尤其是对于那些并非直接交付给用户、也不公开提供的代码。Project Zero 针对一份漏洞报告，往往需要与厂商反复沟通多次，才能就漏洞是否已修复达成一致。随着越来越多厂商尝试打补丁之外的修复方案（比如暂时禁用某些代码路径），这个问题只会变得更加复杂。
我们仍会继续跟踪漏洞的修复情况，并在未修复时与厂商沟通，但这不再作为政策中的决定性条件。这样一来，我们就可以向用户说明他们是如何受到保护的，而无需做出一个会对厂商产生实际影响的非此即彼的判断。