机器人被黑了，还是它自己翻车了？
欧盟《网络弹性法案》2026年9月11日起要求制造商在24小时内上报被主动利用的漏洞或严重事件，2027年12月开源维护者也纳入义务。真正的难点不在填表流程，而在现场如何快速分清攻击与正常故障——基线率日志能力，正成为机器人出海的隐形门槛。
2026年9月11日，欧盟CRA（Cyber Resilience Act，欧盟官方文本编号 Regulation (EU) 2024/2847）的上报义务正式生效：发现被主动利用的漏洞或严重安全事件后，厂商须在24小时内提交早期预警，72小时内完成完整通报。日期是死的，但真正难的不是填表，而是那道工程题——当一台部署在外的机器人行为异常，你如何在24小时内判断：这是攻击，还是系统自身故障率的正常波动？这道题不分厂商大小，只要你的机器人要进入欧盟市场，答案就必须有。
⏱️ 24小时，从法条落到工程台面
法条只有几行，落到工程上，就是一条7×24小时待命的证据链。
义务本身在官方文件里写得清楚：依据欧盟官方公报刊载的 Regulation (EU) 2024/2847（可在 EUR-Lex 检索全文），自2026年9月11日起，制造商在得知一起被主动利用的漏洞或严重事件后，须通过ENISA单一上报平台在24小时内提交早期预警、72小时内完成完整通报。这是硬性时限，不是行业建议。更值得注意的是第二只靴子：自2027年12月11日起，开源steward也将被纳入义务范围。
立法者在这里默认了一个前提：厂商“能识别、能分类、能上报”。但恰恰是识别这一步，是机器人行业目前最薄弱的环节。上报义务实质上把“安全事件分类能力”从加分项变成了准入项。
如果把这条义务翻译成工程师的语言，错位大概是这样的（作者概括）：合规部门看的是时限，工程师面对的是一团没有标签的异常数据。
🔍 单次异常，双向不可判
没有对照组的异常，在工程上既不能叫攻击，也不能叫噪声。
这个问题的尖锐之处，在公开的工程实践里有清楚的对应物。软件工程界早就证明：对一次异常下判断的前提，是保留“同任务、同种子”的干净对照运行——这正是确定性重放（deterministic replay）与事后复盘（postmortem）文化的核心。Google SRE 手册将“能否在受控条件下复现问题”列为故障归因的第一道门槛；机器人领域的对应物则是 rosbag 录制与受控回放。有了这组对照，一次失败的rollout才有解读空间——它能被归因到环境扰动、模型缺陷，或者外部的恶意输入。
而一旦没有对照，结论就是双向不可判：你既不能说这是攻击，也不能说这是噪声。单个坏样本，什么都说明不了。
| 维度 | 实验台 | 现场部署 |
|---|---|---|
| 对照运行 | 可保留同任务同种子 | 无法重跑 |
| 环境状态 | 受控封闭 | 开放多变 |
| 观测窗口 | 不限时长 | 24小时硬期限 |
| 单次异常 | 可归因 | 双向不可判 |
现场的残酷在于：你永远拿不到那个“同种子重跑”。机器人一旦部署，环境在变、轨迹在变、观测窗口还被法案压到了24小时。这其实是IT行业安全事件响应的老问题（可参见 NIST SP 800-61 对事件分类与基线依赖的讨论），在具身智能身上被放大——传统服务器有APM、有历史性能基线可查，而机器人领域这套遥测基础设施，基本还是空白。
🧭 ROS世界没有现成答案
机器人栈的日志，一直是为磨损写的，不是为攻击写的。
ROS的官方文档与社区生态可以为这个判断提供佐证：ROS的诊断（diagnostics）体系围绕硬件心跳、急停、碰撞检测、异常停机设计，整套日志规范都以硬件失效和磨损为主线——这是机器人工程长期以功能安全（safety）为导向的直接体现。而CRA关心的是安全攻击（security）——外部诱导的失效（induced failure）与系统自身基线故障率（baseline failure）的区分，属于完全不同的范式。在 ROS Discourse 上检索"baseline""reproducibility""determinism"等关键词，能找到零散的讨论，但针对“安全事件基线率日志”的成熟实践，目前几乎没有可以照搬的先例——这是作者基于公开社区材料的判断。
具身智能系统让问题更棘手：感知噪声、策略漂移、环境光照变化，任何一项都可能产生“看起来像攻击”的异常行为。区分它们的判定链，目前只能靠工程团队自己搭：
注意图中那个“只能定性为不可判”的分支——它不是极端情况，而是大多数现场团队今天的常态（作者推断）。而“不可判”在法案语境下，等于丧失了24小时窗口。
💡 基线日志，从合规成本变成产品能力
能把“攻击还是翻车”回答清楚，本身就是竞争力。
好消息是，建基线不是玄学。以下是一套可落地的路径（作者观点，由公开的工程实践推演整理，非成熟行业标准）：核心任务保留同种子对照运行；部署侧设立金丝雀任务，定期用已知输入校验系统行为；故障日志按部件、按策略维度分别统计，让“正常波动区间”有数可查。这套东西不依赖新技术，依赖的是把实验台的严谨搬到运维侧的纪律。
同样需要说明的是，下文属于作者的产业推演，而非有公开数据支撑的事实陈述：欧盟客户的采购合同会把合规要求层层传导给上游供应商。能给出“可辩护的24小时结论”的厂商，在标书上就多一条硬理由；反之，事故发生时拿不出基线数据的团队，输掉的不只是一次申报。即便你不直接把产品投放欧盟市场，只要身处供应链，这套能力迟早会被买方写进验收条款。
✅ 换个角度看，CRA其实在逼整个行业补上一堂课——机器人的“安全运营”（SecOps）。这堂课补完了，受益的不只是合规。
⚠️ 2027年12月，开源栈也被拉上桌
开源不是免责牌，只是晚一年进场。
很多人（包括素材作者本人）的第一反应是：我们不是在欧盟市场投放产品的制造商，这项义务跟开源栈无关。这个判断在2026年是对的，在2027年12月11日之后就不成立了——CRA明确把开源steward纳入义务范围。
| 环节 | 时限 / 节点 | 内容 |
|---|---|---|
| 早期预警 | 24小时 | 被主动利用的漏洞或严重事件 |
| 完整通报 | 72小时 | 经ENISA单一上报平台提交 |
| 开源steward | 2027年12月11日起 | 被纳入上报义务范围 |
这对国内团队的含义很具体：大量机器人公司的软件栈构建在ROS及各类开源组件之上。即便你的角色是“用开源”而非“维护开源”，一旦你的栈被下游集成进进入欧盟市场的产品，供应链条款就会把举证要求一层层压回来——你的组件是否被利用、你的日志能否支持下游判定，都会成为被问到的问题。
换句话说，基线率日志这件事，制造商会做，开源社区也绕不开。现在开始在自己维护的模块里积累异常基线数据，2027年到来时就不是救火，而是交作业。
小结
合规日期不会为任何人推迟：2026年9月11日考验流程，2027年12月11日考验开源生态，而真正拉开差距的，是那道技术题——24小时内，分清攻击与故障。当基线率日志从一个论坛里的提问，变成产品遥测的标配，具身智能行业才算真正有了“安全运营”的地基。这块地基平时看不见，出海竞标和事故现场里，它就是门票。
参考与延伸
- Regulation (EU) 2024/2847（Cyber Resilience Act）官方全文：https://eur-lex.europa.eu/eli/reg/2024/2847/oj
- ENISA 网络弹性法案专题页（含上报机制说明）：https://www.enisa.europa.eu
- NIST SP 800-61《计算机安全事件处理指南》（事件分类与基线依赖）：https://csrc.nist.gov/publications/detail/sp/800-61/rev-2/final
- Google SRE 手册（事后复盘与可复现性实践）：https://sre.google/sre-book/table-of-contents/
- ROS 2 官方文档（诊断体系与执行器确定性说明）：https://docs.ros.org
- ROS Discourse 社区论坛（基线、可复现性相关讨论检索入口）：https://discourse.ros.org