Google Project Zero 漏洞披露政策变革与业界争议

谷歌Project Zero团队调整漏洞披露政策,保留90+30天期限但新增一周内公开有限细节,引发对厂商压力与不必要恐慌的讨论,涉及微软零日攻击、AI逆向工程补丁等安全技术议题。

Google Project Zero 更改其披露政策

谷歌的漏洞发现团队再次推动负责任披露的边界:

谷歌的 Project Zero 团队将保留其现有的 90+30 政策,即给予厂商 90 天时间进行漏洞修复,若在截止日期前修复,则允许额外的 30 天用于补丁部署。

然而,自 7 月 29 日起,Project Zero 还将在向厂商披露后的一周内发布有关任何发现的有限细节。这些信息将包括:

  • 收到报告的厂商或开源项目
  • 受影响的产品
  • 报告提交日期以及 90 天披露截止日期

对此,我心情复杂。一方面,我喜欢它给厂商施加了更快修补漏洞的压力。另一方面,如果没有提供漏洞严重程度的指示,很容易引起不必要的恐慌。

问题在于,谷歌并非中立的漏洞猎手。就其发现、发布并降低竞争对手产品信心的程度而言,谷歌作为一家公司是受益的。

标签:披露、谷歌、补丁、漏洞

发布于:2025 年 8 月 8 日上午 7:01 • 7 条评论

评论

ResearcherZero • 2025 年 8 月 8 日上午 8:48

@Bruce
谷歌在披露其他公司的事件后,通常等待几个月才披露自己的事件。或许他们应该以身作则,首先报告自己的漏洞,并向他人提供漏洞预警。
‘https://cloud.google.com/blog/topics/threat-intelligence/voice-phishing-data-extortion

ResearcherZero • 2025 年 8 月 8 日上午 9:21

哦,还要以真正“开放”的方式开源他们的产品。这将停止向世界填充电子垃圾,因为报废设备实际上可以被修补。如果每家公司都足够友善地开放其专有固件,允许适当审查并修补所有那些长期未修补的漏洞,这是每家公司都可以做的事情。
所有挖掘的消费者数据属于消费者,而不是公司。假装你在乎。

Derek Jones • 2025 年 8 月 8 日上午 10:32

数据清楚地显示,发现的漏洞存活时间最短的是那些遵循“私有-修补-公开”序列的漏洞(至少在 2000 年代初):https://shape-of-code.com/2016/10/05/does-public-disclosure-of-vulnerabilities-improve-vendor-response/

Clive Robinson • 2025 年 8 月 8 日上午 10:34

@ Bruce, ALL,
关于
“我心情复杂。一方面,我喜欢它给厂商施加了更快修补漏洞的压力。另一方面,如果没有提供漏洞严重程度的指示,很容易引起不必要的恐慌。”
我也有复杂的感觉。
然而,改变现状几乎没有选择。
正如这里大多数人所知,微软在补丁发布后仅 24 小时就遭到零日攻击。
我们仍然不知道是:

  1. 补被迅速逆向工程。
  2. 来自微软厂商提前通知计划的泄漏。
  3. 来自在“黑客马拉松”舞台上观察活动。
    简单的事实是,微软只完成了三个“本地”补丁中的一个,并且他们的云服务已修补。
    虽然“逆向工程补丁”是已知的攻击者活动……但不仅在一天内为修补的漏洞完成,还在代码库中找到相关漏洞似乎几乎不可能……
    但真的是这样吗?
    答案如果你想一想是“不”,因为通过模式匹配和一点随机输入可以找到相关漏洞。
    正如我之前提到的,这几乎是当前 AI LLMs 的理想工作。
    困难的部分将是找到并优化一个新的 ML 转换器。
    我完全预计这将是一个“热门研究”主题,AI 入职提供数百万美元的报价。
    这就是问题所在,当前的 AI 系统非常适合进行补丁的“逆向工程”以找到漏洞的实际实例。由于大量的“代码重用”和“技术债务”,几乎肯定会有同一类漏洞或其他相近类的其他实例。
    因此,90 天可能不再是我们能够承受的奢侈……

Ian McKellar • 2025 年 8 月 8 日下午 4:07

问题在于,谷歌并非中立的漏洞猎手。就其发现、发布并降低竞争对手产品信心的程度而言,谷歌作为一家公司是受益的。
受此新政策影响的漏洞中,有一半是在谷歌产品中。将谷歌与其他厂商保持相同标准对于 Project Zero 的可信度至关重要。

mw • 2025 年 8 月 11 日凌晨 1:41

每个人都在谈论漏洞和修补。没有人谈论安全软件和质量保证。尤其是微软和其他公司发布臃肿软件。每 1,000 行代码中就有一定数量的错误。代码越多,错误越多,每个漏洞实际上都是一个错误,必须立即修复。减少代码大小并移除不必要的部分将使软件更安全,甚至减少零日漏洞的数量。

Jaime • 2025 年 8 月 11 日中午 12:48

没有人谈论安全软件和质量保证。
当然有。例如,OWASP 已经成功说服世界各地的开发人员减少注入错误。然而,我们仍然是一个行业,忽视安全并幸运地没有被公开泄露尴尬的公司,相对于在安全上投入资源的公司具有竞争优势。
修补相对容易强制和测量。因此,每个安全框架都测量它,每个关心的在线服务客户都施加压力使其发生。

订阅此条目的评论

留下评论 取消回复
博客审核政策
登录名
电子邮件
URL:
记住个人信息?

填写空白:此博客的名称是 Schneier on ___________(必填):

评论:

允许的 HTML
<a href="URL"> • <em> <cite> <i> • <strong> <b> • <sub> <sup> • <ul> <ol> <li> • <blockquote> <pre>
通过 https://michelf.ca/projects/php-markdown/extra/ 的 Markdown Extra 语法

comments powered by Disqus
使用 Hugo 构建
主题 StackJimmy 设计