title: 当漏洞不再只发CVE：2026，软件安全正从“社区惯例”转向“谁必须在24小时内向监管报”
date: 2026-09-04 10:00:00
categories:

• 1

tags:

• 安全
• 开源
• 政策

过去十年，开源安全有一套很少被监管打断的语法：发现漏洞、协调披露、发 CVE、出补丁、用户自己升级。维护者写的是 as-is，厂商把组件装进产品，出事时双方都习惯把责任往供应链上游推。用户看到的则是又一条安全公告。真正决定一块联网设备会不会变成僵尸网络节点的，常常不是公告写得漂不漂亮，而是：谁有义务在知道“正在被利用”的那一天，把这件事交给监管，而不是只交给邮件列表。

2026 年 9 月，这套语法被掐到一个具体日期。欧盟委员会写得很硬：网络弹性法案（Cyber Resilience Act, CRA）2024 年 12 月 10 日生效；主体义务 2027 年 12 月 11 日才全面适用；报告义务从 2026 年 9 月 11 日起就要执行。制造商必须把“正在被积极利用的漏洞”和“影响产品安全的严重事件”报上去：得知后 24 小时内发早期预警，72 小时内交完整通知；针对被积极利用的漏洞，纠正措施可用后不超过 14 天交最终报告，严重事件则不超过一个月。

离今天只剩一周。真正该吵的不是“欧盟又多了一部法”，而是：漏洞第一次被当成必须按时交给监管的产品事故，而不只是社区里的技术条目。

真正要交的，不是又一份 SBOM 模板

把 CRA 理解成“再做一轮合规文档”，会看错题目。欧盟自己把动机写得很土：廉价物联网设备被拉进僵尸网络、手机买完没几年就停更、应用把用户数据漏出去。这些对单个消费者是麻烦，对产业和公共服务则是攻击入口。所以 CRA 盯的是带数字元件的产品全生命周期：设计、开发、维护、漏洞处理。符合要求的产品打 CE 标志，由市场监督当局执法。

9 月 11 日先落地的是报告通道，不是全部设计义务。欧盟网络安全局 ENISA 负责建单一报告平台（Single Reporting Platform, SRP）。制造商原则上只报一次：通知发给其主要经营地所在的计算机安全事件响应小组（CSIRT），除非有特别例外，信息会同时给到 ENISA；收到通知的 CSIRT 再分享给产品已经投放市场的其他成员国 CSIRT。委员会 2025 年 12 月 11 日还通过授权法案，规定在有正当网络安全理由时，CSIRT 可以推迟向其他 CSIRT 扩散。

ENISA 的口径是：SRP 应在 9 月 11 日报告义务生效当天可用，功能和安全测试仍在进行。法律把钟表拨到同一天，平台却还在测。对真正要报的人来说，流程、账号、字段、延迟扩散的例外，都会决定 24 小时预警是不是一张空表。

委员会 2026 年 7 月 27 日发布了实施指南。官方强调它不具约束力，但专门解释了远程数据处理、自由开源软件是否落入范围、何谓“实质性修改”、支持周期怎么算、报告和风险评估怎么做，并给中小企业准备了几十个实例。主体义务还在 2027 年，报告义务已经在敲门。指南是在替中小厂商把路画出来，也是在告诉大厂：别再假装自己还在等最终标准。

开源被单独拆出来，是因为旧模型扛不住这部法

CRA 起草时最吵的一段，是会不会把周末修漏洞的维护者直接写成“制造商”。GitHub 开发者政策负责人 Felix Reda 在 2024 年 12 月的说明里把这条线写得很直：开源能长到今天，靠的就是 as-is、可复用、社区不提供担保；项目又经常缺人缺钱。若把个人贡献者按消费品厂商来管，结果不是更安全，是仓库关门。

最终文本走了分层。欧盟官方对开源的口径可以压成四句：只有在商业活动过程中投放市场的自由开源软件才落入 CRA；制造商自己没有把该开源产品货币化，通常不视为商业活动；向并非自己负责的自由开源软件贡献源代码的人，不适用这部条例；为了管那些“已经发布、但还没按 CRA 意义投放市场、却被别人拿去赚钱”的关键组件，立法者发明了一个新角色：开源软件管家（open-source software steward）。

管家必须是法律实体，不是个人。它持续、系统地支持特定自由开源产品的开发，这些产品被用于商业活动，它还对产品存续负主要责任。基金会、在商业语境下发布开源的实体，都可能对号入座。欧盟给管家的是轻触式制度：要有促进安全开发和漏洞处理的网络安全政策；要和市场监督当局合作；要报告自己知晓的、正在被积极利用的漏洞，以及影响其产品安全的严重事件。官方还写明：按第 64 条第 10 款，开源软件管家不就违反 CRA 被处行政罚款。

这一点必须和制造商分开说。律所摘要里常把制造商罚款写成最高 1500 万欧元，或全球年营业额的 2.5%，以高者为准。那是厂商侧的威慑。有的二次解读会把同一套罚款直接扣到管家头上，和委员会自己的开源页面并不一致。读到罚款数字时，先问一句：你谈的是把产品卖进欧盟市场的制造商，还是只在托管和维系上游项目的管家。

真正危险的是边界案例：技术支持收费超出成本补偿、把用户个人数据拿去干和安全无关的事、捐赠规模已经明显超过设计开发成本。这些才会把一个“看起来免费”的项目拖进制造商义务。不意图营利地接受捐赠、制造商偶尔给钱或提交代码、定期发版本身，按 GitHub 当时整理的澄清，通常还不构成商业供应。

压力会顺着依赖树往下传

对卖产品进欧盟的公司，9 月 11 日不是开源政治，是供应链闹钟。你把别人的库嵌进自己的产品，你就是制造商，要尽职调查第三方组件，不能因为上游是 as-is 就当没看见。如果你在组件里发现漏洞，应当通知制造或维护该组件的实体，并说明你为修复做了哪些改动。

这会改变公司跟开源相处的姿势。过去常见的做法是扫一遍依赖、生成 SBOM、过了审计就结束。现在还要能回答更难的问题：这个漏洞是不是“正在被积极利用”，谁有资格做这个判断；24 小时和 72 小时的钟，从安全团队内部确认开始算，还是从网上已经有利用代码开始算；修复是走上游补丁、自己的下游补丁，还是先把产品从市场撤下来。

Red Hat 对自己所管家项目的说明，把温差讲得很清楚：制造商被期待主动监测并报告；管家的报告义务建立在“知晓”上，并不要求把社区改造成公司安全部。合作仍然关键，因为没有维护者提供的事实，SRP 上的表格填不完。反过来说，合同里若把“你必须在 N 小时内配合我们向欧盟报告”写进贡献协议，轻触式制度就会在纸面之外重新变重。监管对象是厂商，采购条款却常常把成本转给最弱的一方。

Zephyr 这类嵌入式项目已经在文档里把角色写死：项目自身按管家理解义务，把 Zephyr 集成进产品的厂商按制造商理解义务；厂商若在组件中发现漏洞，还要把相关修复信息送回去。特殊不特殊，最后都会落成：这份仓库的安全联系人是谁，谁有权说“我们已知晓”，谁去登录 SRP。

反方不是拖延术，也不是免死金牌

支持 CRA 的人理由很硬。消费市场已经证明，单靠声誉和协调披露，买不到几年安全更新。把报告义务提前到 2026、把设计义务留到 2027，是在先建神经反射，再改产品骨架。对认真做安全的厂商，24 小时预警并不比现有的重大事故通报更离谱，它只是第一次覆盖到带软件的烤面包机和路由器。

反对的人理由同样具体。SRP 与义务同日切换，测试未完就立法生效，首周误报、漏报、重复报都会出现。“积极利用”没有实验室里那么干净：扫描器误报、概念验证代码、定向攻击样本，都会把法务和安全团队拉进同一场定性吵架。美国和其他非欧盟公司一样卖软件进欧盟市场，准备程度却极不均匀；法律不看总部在哪，看产品有没有进入欧盟。轻触式管家制度写在条例里，执行却可能被大客户的安全问卷改写。报告扩散到多国 CSIRT 有助于联防，也可能在“推迟扩散”的例外条款里变成情报博弈。

还有一种更安静的反对：把开源安全问题立法化，容易让公司觉得“报上去就算完成”。真正降低风险的仍是补丁到达设备、更新默认打开、停更周期写进包装。CE 标志能告诉采购这件产品声称符合要求，不能代替两年后的安全更新有没有人做。

接下来一周，比口号值钱的是三张名单

对卖产品进欧盟的团队，现在就该能点名三个人：谁有权判断“正在被利用”，谁在 24 小时内提交早期预警，谁跟上游维护者说话。依赖清单如果还停留在“我们用过这些包”，9 月 11 日当天帮不上忙。你需要的是每个关键组件的安全联系方式、自己改过哪些补丁、哪些产品已经投放哪些成员国。后者决定通知会扩散到哪些 CSIRT。

对基金会和管家候选实体，真正要交的不是一份能上官网的政策 PDF，而是知晓路径：漏洞报告进得来、能留下时间戳、能区分“社区讨论中的 CVE”和“已有在野利用”。报告归管家，漏洞管理仍归项目，除非事先另有安排。不要用这部法去要求个人贡献者承担制造商义务，那既不符合条例，也会把贡献赶跑。

对个人维护者，默认答案仍然是：你大概率不是这部法的对象。该做的实事更土：SECURITY.md 写清楚、安全公告能被下游找到、接受厂商把修复回馈回来。如果有公司以 CRA 为由要求你签署无限时响应条款，那是合同问题，不是你突然变成了布鲁塞尔的制造商。

一句话结论：2026 年秋天，软件安全的竞争变量从“会不会发 CVE”，切到了“谁必须在 24 小时内向监管承认：这东西正在被打”。 开源没有被一刀切进罚款机器，但 as-is 也不能再当所有人的挡箭牌。厂商要为装进产品的组件报时，管家要为知晓的在野利用报时，个人贡献者则应继续写代码，而不是去考欧盟法。钟已经上了弦。剩下的问题很具体：你的产品、你的依赖、你的联系人，能不能在 9 月 11 日把那张早期预警交出去。