目录
- 2026 年 9 月 11 日究竟开始了什么？
- 到底谁需要承担义务？
- 为什么 24 小时期限是一个告警问题？
- 24 小时预警通知里到底要填什么？
- 如何在 24 小时倒计时前放上一部会响的手机？
- 第 1 步 —— 创建一个只用于 CRA 候选事件的电话频道
- 第 2 步 —— 把各条检测路径指向这个频道
- 第 3 步 —— 用条件确保只有合理候选才会响铃
- 第 4 步 —— 接住只会发邮件的系统
- 第 5 步 —— 把所有已注册的代表都放进这个频道
- 第 6 步 —— 在 9 月 11 日之前演练，而不是之后
- Echobell 做不到什么
- 常见问题
- 用了 Echobell 我们就 CRA 合规了吗？
- 24 小时倒计时到底从什么时候开始？
- 我们是小公司，可以豁免吗？
- 我们的安全邮箱在工作时间有人看，这样够吗？
- 合规、法务和工程能收到同一条提醒吗？
- 这对第 14(8) 条告知用户的义务有帮助吗？
- 我们已经在按 NIS2 或 DORA 报告了，这是同一件事吗？
- 电话真的能突破勿扰模式吗？
- 只有 iOS 能用吗？
- webhook 里应该放什么内容？
- 相关文章
2026 年 9 月 11 日，欧盟《网络韧性法案》（Cyber Resilience Act，CRA）的报告义务开始适用。从这一天起，制造商一旦知悉其带数字元素产品中存在被主动利用的漏洞，或知悉影响该产品的重大事件，就必须在 24 小时内向其协调 CSIRT 与 ENISA 提交预警通知（欧盟委员会，法规 (EU) 2024/2847）。
这个期限有一个大多数合规期限没有的特点：它按自然时间走。没有"仅计工作日"的豁免，没有周末暂停，也不会因为负责报告的同事正在飞机上而顺延。而你提交报告的平台——ENISA 的单一报告平台（Single Reporting Platform，SRP）——是一个网页表单，"现阶段不会提供任何应用程序接口"（ENISA 常见问题）。必须由具名的人登录并提交。
因此，24 小时规则首先是一个告警问题，其次才是一个文书问题。本文讲解如何用 Echobell 把"知悉"的那一刻变成一通响铃的电话，同时坦率说明 CRA 准备工作中有很大一部分是任何通知工具都碰不到的。
2026 年 9 月 11 日究竟开始了什么？
带数字元素产品的制造商必须通过统一的欧盟平台报告被主动利用的漏洞和重大事件，倒计时从"知悉"那一刻开始分阶段计算。 CRA 的其余部分——CE 标识、附件 I 的基本要求、合格评定——自 2027 年 12 月 11 日起适用。报告义务提前了十五个月，并且适用于已经在市场上的产品，而不仅仅是这一日期之后发布的产品（cyberresilienceact.eu）。
第 14 条定义了两条结构相同的并行路径：
| 阶段 | 被主动利用的漏洞——第 14(2) 条 | 重大事件——第 14(4) 条 |
|---|---|---|
| 预警通知 | 知悉后 24 小时内 | 知悉后 24 小时内 |
| 正式通知 | 知悉后 72 小时内 | 知悉后 72 小时内 |
| 最终报告 | 纠正或缓解措施可用后 14 天内 | 72 小时通知之后 一个月内 |
原文措辞是"不得无故拖延，且在制造商知悉后无论如何不超过 24 小时"（第 14 条）。24 小时是上限，不是目标。
第 14(5) 条界定了什么算"重大"：某事件对产品保护敏感或重要数据、功能的可用性、真实性、完整性或机密性的能力产生负面影响，或有可能产生负面影响；或者已经导致、或有可能导致恶意代码被引入或执行。"有可能"这三个字很关键——在客户实际受损之前，你可能就已经负有报告义务。
第 14(8) 条还并行增加了一项义务：你必须同时告知产品的受影响用户该漏洞或事件，并在必要时告知他们可采取的纠正措施。这是与 CSIRT 完全不同的受众，走的是另一条路径。
到底谁需要承担义务？
带数字元素产品的制造商，无论注册在哪里；此外还包括开源软件管家（steward），但范围更窄。 位于欧盟之外、向欧盟市场销售的公司同样无法免除义务；法规要求由一个位于欧盟的经济运营者承担相关责任（cyberresilienceact.eu）。
你需要向你在欧盟主要营业地所在成员国指定为协调方的 CSIRT 报告，并同时报告给 ENISA——但你只需通过单一报告平台提交一次，平台会同时分发给双方（欧盟委员会）。
开源软件管家适用的是一个明确的子集：第 14(1) 条的义务在其参与带数字元素产品开发的范围内适用；第 14(3) 与 14(8) 条的义务在重大事件影响到其为该开发提供的网络与信息系统的范围内适用。如果你维护着一个被广泛使用的项目，请把第 24 条与第 14 条一起读，而不要武断地认为自己完全在内或完全在外。
第 15 条还允许自愿报告——制造商及任何其他自然人或法人都可以自愿报告漏洞、网络威胁、事件以及未遂事件。自愿报告不会产生新的义务，但用的是同一个平台，也面临同样的"必须有人醒着"的问题。
为什么 24 小时期限是一个告警问题？
因为倒计时从你"知悉"时开始，而知悉很少发生在上班时间。 触发条件是某个事实抵达你的组织，而不是你的组织做出某个决定。
看看这个事实通常从哪里来。周六晚上 23:40，一位安全研究员发邮件到 security@。一位下游客户提交工单，描述了被利用的迹象。你所发布组件的 CVE 或 KEV 情报源亮了红灯。你自己的 EDR 在构建系统中发现了代码执行。DLA Piper 的准备工作简报特别指出了供应链版本的这个问题：制造商往往不是最先知道的人，信息通过进口商、分销商、研究人员或组件供应商传来（DLA Piper）。
上述每一条路径的终点，都是一条你现有配置很可能静默投递的通知：共享收件箱里的一封邮件、深夜无人查看的 Slack 频道里的一条消息、周一才会分诊的队列中的一张工单。它们都没有失败，都正确送达了——送给了没有人。
有三个细节让这个缺口比看上去更大：
- 没有 API。 ENISA 明确表示现阶段不会提供报告 API。你无法写一个脚本，让它在所有人都睡着时替你提交预警。
- 访问权限是逐人配置的，且必须提前完成。 授权代表需使用 EU Login 账号注册，指定的协调 CSIRT 会在其首次访问后验证其权限。角色分为主代表和备用副代表，而给副代表的邀请七天后过期（ENISA 常见问题，cyberresilienceact.eu）。如果唯一能提交的那个人联系不上，期限不会因此宽容。
- 罚则属于最高档。 第 64 条把违反第 13 条和第 14 条义务的行为归入最高一档行政罚款："最高 15 000 000 欧元，或者若违规方为企业，最高为其上一财政年度全球年营业额的 2.5%，以较高者为准"（第 64 条）。
关于最后一点有一个必须如实说明的限定，因为它会改变小团队的判断：第 64 条将符合微型企业或小型企业标准的制造商，从未能满足第 14(2)(a) 或 14(4)(a) 条期限——也就是恰好是那个 24 小时预警——的行政罚款中排除。但报告义务本身仍然存在，该豁免也不延伸到 72 小时通知或第 14 条的其余部分。请直接阅读该条文并咨询专业意见，不要仅凭一篇博客判断自己属于哪一类。
24 小时预警通知里到底要填什么？
内容很少——这正是关键所在。 ENISA 的指南描述了预警阶段一组很小的必填字段：通知类型（漏洞或事件）、通知级别、报告时间、报告人信息、制造商或管家名称、产品、标题，以及对事件而言是否怀疑存在非法或恶意行为。此阶段的可选字段包括 CVE ID 或 EUVD ID。
更完整的技术画像——漏洞或利用手法的一般性质、初步评估、纠正与缓解措施——属于 72 小时通知，而不是最初的 24 小时。
所以预警通知不是一个研究项目，而是一份准备充分的人几分钟就能填完的短表。真正的瓶颈不是表单，而是一个已注册、已获授权、并且醒着的人能否及时知道。这是一个通知路由问题，而它今天就可以解决。
如何在 24 小时倒计时前放上一部会响的手机？
Echobell 把一次 webhook 调用或一封邮件变成像来电一样响铃震动的提醒，这也是它能突破 iOS 专注模式和勿扰模式的原因（参见突破 iOS 专注模式）。下面的配置与你已有的工单和 PSIRT 流程并行，并不取代它们。
第 1 步 —— 创建一个只用于 CRA 候选事件的电话频道
在 App 中创建频道，把通知类型设为来电（通知类型）。用它触发的决策来命名，而不是用数据源命名："CRA —— 24 小时倒计时可能已开始"比"安全告警"好得多。
这个频道必须保持安静。如果它为每一条公告、每一次扫描失败、每一次依赖升级都响铃，人们就会不再接听，你也就把唯一那个"吵闹"的通道浪费在噪音上了。把这些分流到别处——告警疲劳指南讲了怎么划分。
从频道详情中复制 webhook URL，格式类似 https://hook.echobell.one/t/<channel-token>。请像对待密钥一样对待它，因为任何持有它的人都能让你团队的手机响起来（Webhook 指南）。
设置在凌晨两点、半睡半醒时也能在锁屏上读懂的模板：
标题：可能需要 CRA 报告 —— {{product}}
正文：{{kind}} —— {{summary}}（{{time}} UTC 起知悉）
{{time}}、{{date}}、{{hour}} 以及其他系统时间变量始终以 UTC 注入，因此即使发送方忘了带时间戳，通知里也会有一个。这个时间戳不是"何时开始知悉"的法律证据，但在你日后复原时间线时是一个有用的锚点。
第 2 步 —— 把各条检测路径指向这个频道
任何能调用 webhook 的系统都能触发该频道。你发送的字段会成为模板变量：
curl -X POST https://hook.echobell.one/t/<channel-token> \
-H "Content-Type: application/json" \
-d '{
"product": "Acme Gateway 4.x",
"kind": "被主动利用的漏洞",
"summary": "研究员报告，附带可用的利用代码",
"craCandidate": true,
"externalLink": "https://issues.internal.example/PSIRT-4412"
}'externalLink 这个特殊变量会在通知记录中变成可点击的链接，因此接起电话的人只要一次点击就能打开承载细节的工单。
按"最常成为第一信号"的大致顺序，值得接入的有：
- 你的 PSIRT 或安全受理队列——当某个问题被标记为 CRA 候选时发出 webhook。
- 构建已发布产品的仓库上的 GitHub 安全公告与 Dependabot 告警（GitHub 集成）。
- 你的 SIEM、EDR 或 WAF，针对构建、发布或签名基础设施的检测——第 14(5) 条明确涵盖可能导致恶意代码被引入的事件。
- 你已经在消费的漏洞情报源，过滤到出现在你自己 SBOM 中的组件。
第 3 步 —— 用条件确保只有合理候选才会响铃
这一步决定了频道的可信度能否维持。 Echobell 条件可以对模板使用的同一批变量和 HTTP 头求值，只有表达式为真时频道才会触发：
craCandidate == true && confirmed == true
如果发送系统无法自定义请求体，也可以基于请求头过滤：
header["x-cra-severity"] == "reportable"
阈值应设在"一小时内应该有合格的人来看一眼"，而不是"这肯定要报"。判断是否触发第 14 条本身就是需要掌握事实的人做出的判断；频道的职责是让这个人尽快接触到事实。在这里过度过滤才是昂贵的错误，因为一份从未启动的报告，比一通其实不必要的电话糟糕得多。
第 4 步 —— 接住只会发邮件的系统
来自公司外部的第一次接触大多是邮件——研究员、客户、国家 CSIRT、组件供应商。Echobell 的每个频道都可以拥有自己的邮箱地址，因此在 security@ 上设置一条转发规则就能把这些邮件变成电话（邮件触发）。
邮件触发会把 from、to、subject、text、html 暴露为变量，因此无需解析即可过滤：
subject != "" && (from == "cert@vendor.example" || subject == "[EXPLOITED]")
请与经常向你报告的研究者和关键供应商约定一个主题标记，然后按它匹配。这是一个很小的约定细节，却能把一个非结构化的收件箱变成可路由的信号。
第 5 步 —— 把所有已注册的代表都放进这个频道
把频道分享给所有真正能提交报告的人：主授权代表、备用副代表，以及能就第 14 条做出判断的安全负责人。每位订阅者可以自选通知类型，因此当班的人可以设为来电，其余人设为时效性通知。
这正是整件事的意义所在。SRP 要求一个已注册、已验证的自然人。如果全公司只有一个人完成了注册，那么你的 24 小时期限就有了一个单点故障——而且这个单点还依赖一块手机电池。
第 6 步 —— 在 9 月 11 日之前演练，而不是之后
有两场演练，本月就值得做：
- 告警路径。 在真正开启勿扰模式的情况下，用上面的
curl触发一次，用的必须是那部真的会放在床头的手机。在 App 中打开重试失败通话，让失败一次的来电能被再次尝试。未经测试的升级路径只是一个假设。 - 提交路径。 用 ENISA 的分步注册与提交指南在纸面上走一遍完整流程，这些指南在 2026 年 8 月期间仍在更新（ENISA SRP）。现在就创建 EU Login 账号，确认哪个 CSIRT 是你的协调方，并尽早发出副代表邀请——它七天后就会过期。
第二场演练有一个值得知道的波折：截至 ENISA 7 月的指南，平台的公开 URL 仍然标注为"将在上线时提供"，因此还无法进行真正的端到端测试（cyberresilienceact.eu）。ENISA 已承诺平台将在 2026 年 9 月 11 日前投入运行。请把你能控制的部分全部演练到位，不要把平台是否就绪当成推迟自己准备工作的理由。
Echobell 做不到什么
在这个话题上把这一点讲清楚格外重要，因为它涉及监管：
- 它不会让你合规。 Echobell 是一个通知通道。梳理产品范围、运行漏洞处理流程、判断是否触发第 14 条、在 SRP 注册并按时提交，全都是你自己的事。没有任何告警工具履行过报告义务。
- 它不会替你提交任何东西。 目前没有可供提交的 API；即便有，调用它的也不会是 Echobell。它负责让手机响，剩下的由一个已注册的人完成。
- 它不是法律意义上的时间戳。
{{time}}变量记录的是触发抵达 Echobell 的 UTC 时间。"何时开始知悉"是关于你的组织的事实问题，记录它的应当是你的事件记录，而不是一条推送通知。 - 它没有升级策略，也没有确认机制。 没有"十分钟无人接听就打给下一个人"，没有轮班表，也没有谁确认了什么的审计记录。要这些就需要事件管理平台——参见 Opsgenie 替代方案。
- 它无法保证送达。 一通电话依赖推送基础设施、网络和有电的手机。请把它当作缩短"事实抵达"与"有人知道"之间时间差的一层，而不是可以在审计中指着说的控制措施。
- 它不跟踪本地时间。 内置时间变量只有 UTC，不跟随夏令时。用条件划定时间窗口时，每年需要手动调整两次。
常见问题
用了 Echobell 我们就 CRA 合规了吗？
不会。CRA 把义务加在制造商身上，没有任何通知类 App 能替你履行。Echobell 处理的是其中一个具体的失效模式：24 小时预警之所以错过，是因为本可以提交的人直到下一个工作日才知道。这个失效模式真实且常见，但它只是一个大得多的合规体系中的一小块。
24 小时倒计时到底从什么时候开始？
从制造商知悉该被主动利用漏洞或重大事件时开始。法规没有定义一个精确的时刻，知悉与否取决于事实本身以及这些事实能多快被确认（DLA Piper）。实务上这意味着分诊要快、要有记录：信号抵达与有人评估之间的间隔越长，事后越难解释。
我们是小公司，可以豁免吗？
报告义务不能豁免。第 64 条只是把微型企业和小型企业从"未能满足第 14(2)(a) 或 14(4)(a) 条 24 小时期限"这一项的行政罚款中排除。报告义务本身仍然存在，72 小时通知和最终报告不受影响，而微型企业与小型企业的定义也不是你自己说了算。请把它当作一个范围很窄的缓解，而不是一张通行证。
我们的安全邮箱在工作时间有人看，这样够吗？
只有在你愿意在一个普通周末损失最多三分之二的窗口时才够。周五 18:00 抵达的报告，期限是周六 18:00。工作时间监控对其他事情是个不错的默认选择；而 24 小时倒计时恰恰是它覆盖不到的那一类。
合规、法务和工程能收到同一条提醒吗？
可以，而且应该。共享同一个频道，每位订阅者都会在同一次触发时收到通知，各自选择紧急程度。确认漏洞被利用的工程师，与将要提交表单的人，需要在同一分钟开始，而不是一前一后。
这对第 14(8) 条告知用户的义务有帮助吗？
有间接帮助。第 14(8) 条要求告知受影响用户该漏洞或事件，并在必要时告知纠正措施。那属于客户沟通，需要你自己的渠道。Echobell 能让负责这项沟通的人与负责提交报告的人同时被叫醒，从而让两条工作线并行启动。
我们已经在按 NIS2 或 DORA 报告了，这是同一件事吗？
不是，尽管形态相似。NIS2 与 DORA 依据行业与关键性向实体施加义务；CRA 依据你投放到欧盟市场的产品向制造商施加义务。同一家机构可能同时受三者约束，而它们的倒计时不同、接收方也不同。如果这些制度对你同样适用，请参阅 DORA 与 NIS2 事件报告提醒——注意即便义务不同，告警层是可以共用的。
电话真的能突破勿扰模式吗？
来电类通知以通话形式送达，这正是它能在 iOS 上突破专注模式的原因。但这不是魔法：它依然取决于系统设置、网络和有电的手机。在你真正依赖它之前，请在实际设备上、在真正开启专注模式的情况下测试，并打开重试失败通话。
只有 iOS 能用吗？
不是。Echobell 同时提供 iOS 版和 Google Play 上的 Android 版（Android 版发布）。来电式提醒在两个平台上的行为有差异，请在响应人实际携带的设备上测试。
webhook 里应该放什么内容？
刚好够判断"要不要爬起来"的最少信息：产品、信号类型、一句话背景，以及指向承载细节工单的 externalLink。Echobell 把通知内容与历史保存在设备上，服务器只保留账号、频道和订阅关系（隐私模型），但处理安全敏感材料的正确习惯，仍然是发送一个指针而不是内容本身。