Copy Fail 补丁被看穿后，漏洞披露的时间差没了

Copy Fail 这件事的反常点，不是又多了一个漏洞，而是旧办法失灵得太快。

Hyunwoo Kim 在 Copy Fail 公布当天发现原修复不够，提交了补丁，也把安全影响发给 Linux 安全工程师的闭门列表。代码公开修，安全含义暂时控住。结果外部人员从公开变更里看出了安全含义，并发布出来。embargo 也就事实上结束了。

公开补丁被读成了安全公告

这不是大规模利用事件。至少从现有材料看，不能写成“AI 自动攻破 Linux”。

更准确的说法是：一次补丁流程被提前读懂了。

Linux 社区长期有一种很工程化的做法：bug 就是 bug。很多问题先按普通修复合入，不急着给它贴安全标签。这样做有现实理由。内核提交太多，很多 bug 又可能被转成攻击面，如果每个修复都高调标红，只会把维护流程拖慢，也会放大噪音。

Copy Fail 的尴尬在这里：补丁可以公开，含义却很难继续半公开。

过去，公开 diff 像一堆工作痕迹。只有少数人愿意花时间逐行看、推断影响、判断能不能利用。现在 AI 让这件事便宜了。模型不需要替安全研究员下最终结论，它只要能做初筛，就足够改变局面。

公开 diff 的信噪比变了。

对攻击者和研究者来说，海量提交不再只是噪音，而是可以被机器预筛的线索池。对维护者来说，“我只是提交了一个普通修复”这句话，保护力正在下降。

两套漏洞文化都被压缩

安全圈原来大致有两种默契。它们不是什么正邪对立，只是面对不同工程现实的折中。

协调披露的好处是有秩序。厂商、维护者、下游可以排期修复，避免裸奔。

它的问题也很硬：长 embargo 的前提，是别人短期内看不见同一个洞。

Copy Fail 相关案例里，Kim 报告后约 9 小时，Kuan-Ting Chen 也独立报告了相关 ESP 漏洞。9 小时不是 90 天。这不能证明所有漏洞都会被这么快撞上，但足够提醒行业：很多窗口只是看起来还关着。

Linux 式快速修补也不是胡来。它的价值是少废话、快合入、少制造围观。

可它同样吃时间差。只要公开补丁还能在海量提交里“隐身”，这套办法就能运转。一旦 AI 把公开 diff 扫成了半自动情报源，隐身就变成了运气。

“兵贵神速”在这里不是鸡汤，是约束条件。漏洞披露以前像信使传令，现在更像雷达扫场。你以为消息还在帐内，外面已经看见火光。

受影响的人该改什么

最先要改动作的，是安全研究员和开源维护者。

安全研究员不能再默认“公开补丁没人看懂”。如果一个修复有安全含义，提交说明、补丁节奏、通知对象都要重新算。不是说每个补丁都要藏起来，而是要承认：公开之后，被解读的速度会比从前快。

开源维护者也不能只靠闭门列表控信息。闭门通报仍然有价值，但它更像短暂协调工具，不是保险柜。更现实的动作是：

• 对疑似安全修复提前做下游通知准备；
• 缩短 embargo，把重点放在快速合入和快速发布；
• 对公开 diff 做一次“外部会怎么看”的安全复核；
• 把 AI 辅助 triage 用在防守侧，而不是只担心它被攻击侧使用。

企业安全团队和发行版维护者的压力也会变大。

以前可以等公告、等 CVE、等上游安全说明。现在只等正式标签，可能已经慢半拍。更稳的做法，是把上游关键项目的补丁流纳入监控：哪些提交像内存安全修复，哪些像权限边界修复，哪些补丁描述刻意很轻。AI 可以帮忙筛，但不能代替人拍板。

这里有个限制必须讲清：AI 辅助看补丁，不等于自动判定漏洞可利用。误报会很多，模型也会瞎猜。把一次快速试验当模型强弱评测，也不严肃。

但流程不需要 AI 完美才会被改变。只要它把“发现可疑补丁”的成本降下来，攻防速度就已经变了。

接下来真正该看的，不是谁又做了一个漂亮 demo，而是三件事：

我更赞成非常短的 embargo。短到什么程度，要看项目影响面、补丁可部署性、下游链路速度。不能一刀切。

但把 90 天当成安全行业的礼仪传统，已经越来越不现实。

长 embargo 最大的问题，是制造虚假的从容：知道的人少，所以好像风险低。可现实可能相反。知道的人少，意味着能修的人少，能验证的人少，能提醒下游的人也少。

Copy Fail 留下的提醒很朴素：代码一旦公开，含义也迟早公开。过去是迟一点，现在是快很多。

真正崩掉的不是某个流程，而是旧时代那个默认假设：没人会那么快看懂。