在2021，供应商平均花费52天来修复从零项目报告的安全漏洞。这是一个显著的加速，比三年前平均80天的速度要快。
除了目前的平均水平远低于90天的最后期限外，我们还看到错过最后期限（或额外的14天宽限期）的供应商数量有所下降。在2021，只有一个bug超过了它的修复期限，虽然14%的bug需要宽限期。
供应商/产品向用户发送修复程序所需时间的差异反映了他们的产品设计、开发实践、更新周期以及安全报告的一般流程。我们希望这种比较能够展示最佳实践，并鼓励供应商尝试新政策。
这种数据聚合和分析对于Project Zero来说相对较新，但我们希望在未来做得更多。我们鼓励所有供应商考虑在其时间上发布聚合数据来修复外部报告漏洞的补丁和时间，以及更多的数据共享和透明性。
近十年来，谷歌的“零号项目”一直致力于让不良行为者更难发现和利用安全漏洞，从而显著提高了每个人的互联网安全性。在这段时间里，我们与业内人士合作，改变了组织优先排序的方式，以及修复安全漏洞和更新人们软件的方法。
为了帮助我们了解生态系统正在发生的变化，我们回顾了Project Zero报告的一组漏洞，一系列供应商如何应对这些漏洞，然后试图确定这些数据的趋势，例如整个行业如何更快地修补漏洞。
对于这个帖子，我们查看2019年1月和2021年12月之间报告的固定错误（2019是我们对我们的披露政策做出改变的一年，并且开始记录我们报告的bug的更详细的度量）。我们'；在Project Zero Bug Tracker和各种开源项目存储库中（在下面用于跟踪开源浏览器Bug时间线的数据中）都可以公开获取ll be Reference。
我们的数据有很多警告，最大的警告是我们'；我会看一小部分样本，所以数量上的差异可能有统计学意义，也可能没有统计学意义。此外，项目零和#39的方向；s的研究几乎完全受单个研究人员的选择影响，因此我们研究目标的变化可能会像供应商行为的变化一样改变指标。这篇文章的目的是尽可能客观地展示数据，并在最后进行额外的主观分析。
在2019到2021年间，Project Neo在我们标准的90天截止期限内向供应商报告了376个问题。其中351（93.4%）个错误已被修复，14（3.7%）个错误已被供应商s标记为WontFix。11（2.9%）个其他错误尚未修复，但在撰写本文时，有8个错误已过了修复的截止日期；其余3人仍在最后期限内。大多数漏洞集中在几个供应商周围，其中96个漏洞（26%）报告给微软，85个（23%）报告给苹果，60个（16%）报告给谷歌。
一旦供应商在我们的标准截止日期内收到错误报告，他们有90天的时间来修复它，并向公众发布一个补丁版本。如果供应商确认计划在总共104天的窗口期结束前发布修复程序，则供应商也可以请求14天的宽限期。
在本节中，我们'；我们将看看供应商多久能达到这些截止日期。下表列出了自2019年1月起90天截止日期内向供应商报告的所有缺陷，以及针对窗口中缺陷报告最多的供应商已修复的所有缺陷。
*为确保完整性，包括在"；其他"；bucket是Apache、ASWF、Avast、AWS、c-ares、Canonical、F5、Facebook、git、Github、glibc、gnupg、gnutls、gstreamer、haproxy、Hashicorp、InsidesCure、Intel、Kubernetes、libseccomp、libx264、Logmein、Node。js、opencontainers、QT、高通、RedHat、Reliance、SCTPLabs、Signal、systemd、腾讯、Tor、udisks、usrsctp、Vandyke、VietTel、webrtc和Zoom。
总的来说，数据显示，这里几乎所有的大供应商平均都在90天内进货。宽限期内的大部分补丁来自苹果和微软（34个补丁中有22个）。
在此期间，供应商超过了截止日期和宽限期的时间约为5%。在这一部分中，甲骨文的错误率最高，但无可否认，样本量相对较小，只有大约7个错误。排名第二的是微软，它已经超过了80个截止日期中的4个。
所有供应商修复漏洞的平均天数为61天。放大这一数据，我们可以按年份进行细分：
*为确保完整性，包括在"；其他"；bucket是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、高通、RedHat、Reliance、三星、SCTPLabs、Signal、systemd、腾讯、Tor、udisks、usrsctp、Vandyke、VietTel、webrtc和Zoom。
从中，我们可以看到几件事：首先，修复的总时间一直在减少，但最显著的是2019年至2020年。微软、苹果和Linux在整个期间都减少了修复的时间，而谷歌在2021之前又加速了2020。也许最令人印象深刻的是，其他没有出现在图表上的人都将他们的时间缩短了一半以上，尽管它'；这可能代表着研究目标的改变，而不是任何特定供应商实践的改变。
只超过了一个截止日期，而其他两年平均每年超过9个
宽限期使用了9次（尤其是微软使用了一半），而其他年份的平均值略低，为12.5次
由于上表中的产品涵盖一系列类型（桌面操作系统、移动操作系统、浏览器），我们还可以关注一个特定的，希望更多的苹果对苹果的比较：移动电话操作系统。
首先要注意的是，在这段时间里，iOS从Project Zero收到的bug报告似乎比任何一款Android系统都要多得多，但这并不是研究目标选择的不平衡，而是反映了苹果如何发布软件。"的安全更新；应用程序"；例如iMessage、Facetime和Safari/WebKit都是作为操作系统更新的一部分提供的，所以我们将这些都包括在操作系统的分析中。另一方面，Android上独立应用的安全更新是通过Google Play Store进行的，因此本分析不包括这些更新。
尽管如此，这三家供应商的平均修复时间都非常相似。根据我们现有的数据，它是'；很难确定在漏洞生命周期的每个部分（如分类、补丁编写、测试等）花费了多少时间。然而，开源产品确实提供了一个了解时间花在哪里的窗口。
对于大多数软件来说，我们不是'；我无法深入了解时间线的细节。具体来说：在供应商收到安全问题报告后，"；是时候解决了"；在错误报告和修复之间花费了多少时间，在修复和发布带有修复的构建之间花费了多少时间？我们拥有的一个窗口是开放源代码软件，并且特定于Project Zero所做的漏洞研究类型，即开放源代码浏览器。
我们也可以查看相同的数据，但每个错误都以柱状图的形式展开。特别是，从一个补丁公开发布到该补丁发送给用户的时间的柱状图显示了一个清晰的故事（在上表中，这对应于从公共补丁到发布的平均天数列：
Chrome是目前三款浏览器中速度最快的一款，从错误报告到在稳定频道发布修复程序需要30天的时间。这里的补丁时间非常快，从bug报告到补丁公开发布之间平均只有5天的时间。该补丁向公众发布的时间占整个时间窗口的大部分，尽管总体而言，我们仍然可以看到直方图左侧的铬（蓝色）条。（重要提示：尽管Project Zero位于同一家公司内，但它在Chrome上遵循的政策和程序与外部安全研究人员会遵循的政策和程序相同。有关更多信息，请参阅我们的漏洞披露常见问题解答。）
Firefox在这项分析中排名第二，但需要分析的数据点相对较少。Firefox平均在38天内发布一个补丁。其中不到一半的时间是修复程序公开发布的时间，尽管它'；值得注意的是，Firefox故意推迟提交安全补丁，以减少补丁发布前的曝光量。一旦补丁被公开，它发布固定版本的速度平均比Chrome快几天——绝大多数补丁在公开补丁发布10-15天后发布。
WebKit是该分析中的异常值，发布补丁的最长天数为73天。他们公开的修复时间是在Chrome和Firefox之间，但不幸的是，这使得机会主义攻击者在找到修复补丁之前花了很长的时间来寻找补丁并利用它。这可以从第二个柱状图的苹果（红色）条中看出，它们大多位于图表的右侧，除了一条超过30天标记之外，其他所有的条都显示了这一点。
总体而言，我们从数据中看到了一些有希望的趋势。供应商正在修复他们收到的几乎所有漏洞，他们通常在90天的截止日期加上14天的宽限期内完成。在过去三年中，供应商在很大程度上加快了补丁的速度，有效地将总平均修复时间减少到了52天左右。在2021，只有一个超过90天的截止日期。我们怀疑这一趋势可能是因为负责任的披露政策已成为行业事实上的标准，供应商更有能力对不同截止日期的报告做出快速反应。我们还怀疑，随着行业透明度的提高，供应商已经相互学习了最佳实践。
一个重要的警告：我们知道，与其他错误报告相比，来自Project Zero的报告可能是异常值，因为它们可能会收到更快的行动，因为存在公开披露的有形风险（如果不满足截止日期条件，团队将予以披露），并且Project Zero是可靠错误报告的可靠来源。我们鼓励供应商发布指标，即使它们是高水平的，以便更好地全面了解整个行业的安全问题得到解决的速度，并继续鼓励其他安全研究人员分享他们的经验。
对于谷歌，尤其是Chrome，我们怀疑安全漏洞的快速周转时间部分是因为它们的快速发布周期，以及它们额外的安全更新稳定版本。我们'；再次受到Chrome和#39的鼓励；s最近从6周的发布周期改为4周的发布周期。在Android方面，我们看到Android的像素变种与三星变体以及iOS旗鼓相当。即便如此，我们鼓励Android团队寻找其他方法来加快安全更新的应用，并进一步推动该行业的发展。
对于苹果，我们'；我们对补丁登陆的加速，以及最近没有使用宽限期，也没有错过最后期限感到满意。特别是对于WebKit，我们希望看到从下载补丁到将其发送给用户所需的时间减少，尤其是因为WebKit安全性影响iOS中使用的所有浏览器，因为WebKit是iOS平台上唯一允许的浏览器引擎。
对于微软来说，我们怀疑是时候修复和微软'；微软对宽限期的依赖是微软每月节奏的结果'；s"；补丁星期二"；更新，这会使开发团队更难满足披露期限。我们希望微软可以考虑为安全问题实施更频繁的补丁节奏，或者找到进一步简化内部进程以更快地登陆和传输代码的方法。
这篇文章代表了一些我们'；我们已经完成了我们自己的公开数据，我们希望继续这项工作。现在我们'；在过去几年中，我们已经建立了一个基线，我们计划继续发布年度更新，以更好地了解趋势的进展情况。
为此，我们'；I’我希望对我们供应商的流程和时间表有更多的了解。我们鼓励所有供应商考虑在其时间上发布聚合数据以修复和修补外部报告漏洞的时间。通过提高透明度、信息共享和整个行业的合作，我们相信我们可以相互学习#39；这是我们的最佳实践，更好地理解存在的困难，并希望让互联网成为所有人的安全之地。