作者：Ryan Schoen，Project Zero

内容摘要

• 2021年，厂商修复Project Zero报告的安全漏洞平均耗时52天。相比三年前约80天的平均修复时间，这是一个显著的加速。
• 除了平均修复时间远低于90天截止期限外，我们还观察到厂商错过截止期限（或额外的14天宽限期）的情况有所减少。2021年，只有一个漏洞超过了修复截止期限，尽管有14%的漏洞使用了宽限期。
• 厂商/产品向用户发布修复补丁所需时间的差异反映了其产品设计、开发实践、更新节奏以及对安全报告的总体处理流程。我们希望这种比较能够展示最佳实践，并鼓励厂商尝试新的策略。
• 这种数据汇总和分析对Project Zero来说相对较新，但我们希望未来能更多地开展此类工作。我们鼓励所有厂商考虑发布关于外部报告漏洞的修复时间和补丁发布时间的汇总数据，并总体上增加数据共享和透明度。

概述

近十年来，Google的Project Zero一直致力于增加恶意行为者发现和利用安全漏洞的难度，从而显著提升互联网的整体安全性。在此期间，我们与业界同仁合作，改变了组织优先处理安全漏洞修复和软件更新的方式。

为了帮助我们观察到的生态系统变化提供背景，我们回顾了Project Zero报告的一系列漏洞、各类厂商如何响应这些漏洞，并试图从这些数据中识别趋势，例如整个行业如何更快地修补漏洞。

在本文中，我们关注的是2019年1月至2021年12月期间报告的已修复漏洞（2019年是我们修改披露政策并开始记录所报告漏洞更详细指标的一年）。我们将引用的数据可在Project Zero Bug Tracker以及各种开源项目仓库中公开获取（用于追踪开源浏览器漏洞时间线的数据即来源于此）。

我们的数据存在一些注意事项，最主要的是我们将查看少量样本，因此数字上的差异可能具有统计显著性，也可能没有。此外，Project Zero的研究方向几乎完全由个别研究人员的个人选择决定，因此我们研究目标的变化对指标的影响可能与厂商行为变化的影响一样大。本文旨在尽可能客观地呈现数据，并在最后附上一些主观分析。

数据概览！

2019年至2021年间，Project Zero根据标准的90天截止期限向厂商报告了376个问题。其中351个（93.4%）漏洞已被修复，14个（3.7%）被厂商标记为"不予修复"。另有11个（2.9%）漏洞尚未修复，尽管截至本文撰写时，其中8个已超过修复截止期限；其余3个仍在修复期限内。大多数漏洞集中在少数几家厂商，其中向微软报告了96个漏洞（26%），向苹果报告了85个（23%），向谷歌报告了60个（16%）。

截止期限遵守情况

一旦厂商在我们的标准截止期限内收到漏洞报告，他们有90天的时间来修复漏洞并向公众发布修补版本。如果厂商确认计划在总共104天（90天+14天宽限期）的窗口期内发布修复，他们也可以请求14天的宽限期。

在本节中，我们将查看厂商能够满足这些截止期限的频率。下表包含了自2019年1月以来在90天截止期限内向厂商报告并已修复的所有漏洞，按报告数量最多的厂商排列。

2019-2021年截止期限遵守情况及修复时间（按漏洞报告数量）

厂商	总漏洞数	第90天前修复	宽限期内修复	超出截止期限及宽限期	平均修复天数
Apple	84	73 (87%)	7 (8%)	4 (5%)	69
Microsoft	80	61 (76%)	15 (19%)	4 (5%)	83
Google	56	53 (95%)	2 (4%)	1 (2%)	44
Linux	25	24 (96%)	0 (0%)	1 (4%)	25
Adobe	19	15 (79%)	4 (21%)	0 (0%)	65
Mozilla	10	9 (90%)	1 (10%)	0 (0%)	46
Samsung	10	8 (80%)	2 (20%)	0 (0%)	72
Oracle	7	3 (43%)	0 (0%)	4 (57%)	109
Others*	55	48 (87%)	3 (5%)	4 (7%)	44
总计	346	294 (84%)	34 (10%)	18 (5%)	61

• 为求完整，"其他"类别中包含的厂商有：Apache、ASWF、Avast、AWS、c-ares、Canonical、F5、Facebook、git、Github、glibc、gnupg、gnutls、gstreamer、haproxy、Hashicorp、insidesecure、Intel、Kubernetes、libseccomp、libx264、Logmein、Node.js、opencontainers、QT、Qualcomm、RedHat、Reliance、SCTPLabs、Signal、systemd、Tencent、Tor、udisks、usrsctp、Vandyke、VietTel、webrtc和Zoom。

总体而言，数据显示，这里几乎所有大型厂商的平均修复时间都在90天以内。宽限期内的修复大部分来自苹果和微软（34个中的22个）。

在此期间，厂商超出截止期限和宽限期的情况约占5%。在这个切片中，Oracle的超期率最高，但必须承认其样本量相对较小，只有大约7个漏洞。其次是微软，在其80个截止期限中有4个超期。

所有厂商修复漏洞的平均天数为61天。聚焦于这个统计数据，我们可以按年份细分：

2019-2021年漏洞修复时间（按漏洞报告数量）

厂商	2019年漏洞数（平均修复天数）	2020年漏洞数（平均修复天数）	2021年漏洞数（平均修复天数）
Apple	61 (71)	13 (63)	11 (64)
Microsoft	46 (85)	18 (87)	16 (76)
Google	26 (49)	13 (22)	17 (53)
Linux	12 (32)	8 (22)	5 (15)
Others*	54 (63)	35 (54)	14 (29)
总计	199 (67)	87 (54)	63 (52)

• 为求完整，"其他"类别中包含的厂商有：Adobe、Apache、ASWF、Avast、AWS、c-ares、Canonical、F5、Facebook、git、Github、glibc、gnupg、gnutls、gstreamer、haproxy、Hashicorp、insidesecure、Intel、Kubernetes、libseccomp、libx264、Logmein、Mozilla、Node.js、opencontainers、Oracle、QT、Qualcomm、RedHat、Reliance、Samsung、SCTPLabs、Signal、systemd、Tencent、Tor、udisks、usrsctp、Vandyke、VietTel、webrtc和Zoom。

由此，我们可以看到几点：首先，总体修复时间持续下降，但最显著的是在2019年至2020年之间。微软、苹果和Linux在此期间总体上缩短了修复时间，而谷歌在2020年加速后，2021年又有所放缓。也许最令人印象深刻的是，图表中未列出的其他厂商集体将修复时间缩短了一半以上，尽管这可能反映了研究目标的变化，而非任何特定厂商实践的改变。

最后，仅关注2021年，我们看到：

• 只有1个截止期限被超出，而其他两年平均每年有9个
• 宽限期使用了9次（值得注意的是其中一半由微软使用），略低于其他年份平均12.5次

手机操作系统

由于上表中的产品涵盖多种类型（桌面操作系统、移动操作系统、浏览器），我们也可以专注于一个特定的、希望更具可比性的领域：手机操作系统。

厂商	总漏洞数	平均修复时间
iOS	76	70
Android (Samsung)	10	72
Android (Pixel)	6	72

首先需要注意的是，在此期间，iOS从Project Zero收到的漏洞报告数量明显多于任何版本的Android，但这并非研究目标选择的不平衡，而更多地反映了苹果发布软件的方式。iMessage、Facetime和Safari/WebKit等"应用"的安全更新都是作为操作系统更新的一部分发布的，因此我们将它们纳入操作系统的分析中。另一方面，Android上独立应用的安全更新是通过Google Play商店进行的，因此未包含在此次分析中。

尽管如此，这三家厂商的平均修复时间都极为相似。根据我们现有的数据，很难确定漏洞生命周期（例如分类、补丁编写、测试等）的每个部分花费了多少时间。然而，开源产品确实为我们了解时间花费在何处提供了一个窗口。

浏览器

对于大多数软件，我们无法深入探究时间线的具体细节。具体来说：在厂商收到安全问题报告后，"修复时间"中有多少是花费在漏洞报告和修复代码提交之间，又有多少时间花费在修复代码提交和发布包含修复的构建版本之间？我们确实有一个窗口可以观察开源软件，特别是Project Zero进行漏洞研究的那类开源软件：开源浏览器。

开源浏览器修复时间分析（按漏洞数量）

浏览器	漏洞数	从漏洞报告到公开补丁的平均天数	从公开补丁到发布版本的平均天数	从漏洞报告到发布版本的平均天数
Chrome	40	5.3	24.6	29.9
WebKit	27	11.6	61.1	72.7
Firefox	8	16.6	21.1	37.8
总计	75	8.8	37.3	46.1

我们也可以查看相同的数据，但将每个漏洞在直方图中展开。特别是，从修复代码公开提交到该修复发布给用户的时间量直方图清晰地讲述了一个故事（在上表中，这对应于"从公开补丁到发布版本的平均天数"列）：

表格和图表共同告诉我们以下几点：

Chrome目前是这三款浏览器中最快的，从漏洞报告到在稳定渠道发布修复平均需要30天。其补丁提交速度非常快，从漏洞报告到补丁公开提交平均只需5天。该补丁向公众发布的时间占据了整个时间窗口的大部分，但总体而言，我们仍然看到直方图中Chrome（蓝色）的柱状图偏向左侧。（重要说明：尽管同属一家公司，Project Zero对Chrome遵循与外部安全研究人员相同的政策和程序。更多信息请参阅我们的漏洞披露FAQ。）

Firefox在此次分析中排名第二，尽管可供分析的数据点相对较少。Firefox平均在38天内发布修复。其中不到一半的时间用于修复代码公开提交，但需要注意的是，Firefox有意延迟提交安全补丁，以减少修复发布前的暴露时间。一旦补丁公开，其发布修复版本的平均速度比Chrome快几天——绝大多数修复在其公开补丁后的10-15天内发布。

WebKit是此次分析中的异常值，发布补丁所需天数最长，为73天。其修复代码公开提交的时间介于Chrome和Firefox之间，但不幸的是，这给机会主义攻击者留下了很长的时间来寻找补丁并在修复提供给用户之前利用它。这可以从第二个直方图中苹果（红色）的柱状图大部分位于图表右侧看出，除了一个例外，其他所有都超过了30天标记。

分析、希望与展望

总体而言，我们从数据中看到了一些有希望的趋势。厂商几乎修复了他们收到的所有漏洞，并且通常在90天截止期限内完成，必要时加上14天宽限期。在过去三年中，厂商大多加快了补丁速度，有效地将总体平均修复时间缩短至约52天。2021年，只有一个90天截止期限被超出。我们怀疑这种趋势可能是由于负责任的披露政策已成为行业事实上的标准，并且厂商更有能力对不同截止期限的报告做出快速反应。我们还怀疑厂商之间相互学习了最佳实践，因为行业的透明度在不断提高。

一个重要注意事项：我们知道，与其他漏洞报告相比，Project Zero的报告可能是特例，因为它们可能会得到更快的处理，因为存在公开披露的实际风险（如果未满足截止期限条件，团队将进行披露），并且Project Zero是可靠漏洞报告的可信来源。我们鼓励厂商发布指标，即使是高级别的指标，以便更好地了解整个行业安全问题的修复速度，并继续鼓励其他安全研究人员分享他们的经验。

对于谷歌，特别是Chrome，我们怀疑安全漏洞的快速周转时间部分归功于其快速的发布周期，以及他们为安全更新提供的额外稳定版本。我们对Chrome最近从6周发布周期切换到4周发布周期感到鼓舞。在Android方面，我们看到Pixel版本的Android发布修复的速度与三星版本以及iOS大致相当。即便如此，我们鼓励Android团队寻找其他方法来加快安全更新的应用，并推动该行业领域进一步发展。

对于苹果，我们对补丁提交速度的加快、最近较少使用宽限期以及没有错过截止期限感到满意。特别是对于WebKit，我们希望看到从提交补丁到向用户发布之间的时间能够减少，尤其是因为WebKit的安全性影响到iOS上使用的所有浏览器，因为WebKit是iOS平台上唯一允许的浏览器引擎。

对于微软，我们怀疑修复时间长以及微软对宽限期的依赖是其每月"补丁星期二"更新节奏的结果，这可能使开发团队更难满足披露截止期限。我们希望微软可以考虑为安全问题实施更频繁的补丁节奏，或者寻找方法进一步简化其内部流程，以更快地提交和发布代码。

展望未来

本文代表了我们对自己公开数据所做的一些数字分析，我们希望未来能继续这项工作。既然我们已经建立了过去几年的基线，我们计划继续发布年度更新，以更好地了解趋势的进展。

为此，我们希望对厂商的流程和时间线有更深入的了解。我们鼓励所有厂商考虑发布关于外部报告漏洞的修复时间和补丁发布时间的汇总数据。通过更多的透明度、信息共享和行业协作，我们相信我们可以相互学习最佳实践，更好地理解现有的困难，并有望为所有人创造一个更安全的互联网环境。