devgo.cn想象一个做智能家电的团队，产品卖到欧洲，代码里藏着一个已被攻击者利用的漏洞，而你没有在 24 小时内上报监管机构——2026 年 9 月 11 日起，这就不是道德问题，而是法律义务。欧盟《网络弹性法案》（CRA，Cyber Resilience Act，针对所有含数字元素产品的网络安全法规）给制造商设了一条硬性红线：凡是产品中被实际利用过的漏洞（actively exploited vulnerability），或造成敏感数据、功能受影响的安全事件，必须在知晓后 24 小时内通过单一报告平台（Single Reporting Platform）上报，同时通知协调机构 CSIRT（计算机安全事件响应小组，各国负责处理网络事件的官方组织）和 ENISA（欧盟网络安全局，负责统筹协调的机构）。很多做软件的公司第一次面对这种被监管的产品安全义务，9 月的截止日期听起来远，但落地评估往往一团糟。别慌，先搞清楚自己现在站在哪，再把缺口变成行动清单。
CRA 对“已利用漏洞”的定义很具体：“有可靠证据表明恶意行为者未经系统所有者许可在系统中利用了该漏洞”。注意，即使你觉得自己没触发上报条件，监管机构在审计时也会独立判断你是否有责任。而“严重事件”则覆盖两种情况：一是影响了产品保护敏感数据或功能的可用性、真实性、完整性、机密性；二是导致或可能导致恶意代码被引入产品，或进入使用者的网络和信息系统。无论哪种，都是 24 小时内上报。
那怎么评估自己的代码库是否达标？原文给出了 7 个问题，每个都能按四级成熟度打分：未证实（absent or unknown）、临时方案（partial, inconsistent or manually dependent）、标准化（defined, evidenced and consistently applied）、强制化（enforced, 能自动阻止不合格项推进）。凡是低于“标准化”的，就说明这个控制还没可靠建立。
**1. 安全默认值**：代码库是否默认开启安全控制、禁用不必要的能力？如果低于标准化，产品初始状态就不安全，安全可能依赖用户或运维手动改配置。CRA 附录 I 第一部分 2(b) 明确要求产品以 secure-by-default 配置交付。
**2. 安全敏感变更**：涉及安全关键代码和配置的改动，是否被识别、评审并测试？如果做不到，漏洞或事件是怎么被引入的、影响了哪些版本、你采取的纠正措施是否有效，全都说不清。这直接支撑附录 I 第二部分第 3 条要求的“有效定期的安全测试和评审”。
**3. 发布可追溯性**：每个发布能否追溯到精确的源代码、构建输入和依赖？如果做不到，你无法确定发布里到底有什么第三方组件，漏洞评估和修复就会失真。CRA 附录 I 第二部分第 1 条要求制造商识别并记录产品组件和漏洞，包括至少覆盖顶层依赖的 SBOM（软件物料清单，一份列出软件所有组成部分的清单）。可追溯性比最低要求更进一步，但能支撑每次发布的准确清单。
**4. 合并前安全检查**：每次代码变更是否必须通过安全检查才能合并？如果缺失或依赖个人团队自觉，漏洞可能在合并时就溜进主分支，最终变成被利用的入口。这是典型的“预防”而非“报告”环节，但 CRA 附录 I 第一部分 2(a) 禁止发布已知可利用漏洞，第二部分第 3 条也要求定期安全测试。
**5. 发布强制拦截**：当严重安全问题未解决时，能否阻断构建或发布？如果安全发现问题只是“告知”一下，项目还是带着明显的洞上线，等于把弱点暴露给攻击者。CRA 要求及时修复漏洞（附录 I 第二部分第 2 条），拦截阈值和例外流程应该基于产品的网络安全风险评估，不能一拍脑袋。
**6. 对抗误用的自动化测试**：自动化测试是否针对安全关键代码测试了误用和恶意输入？如果测试只覆盖正常行为，安全逻辑在遭受攻击时崩不崩溃你根本不知道。
**7. 发布测试验证安全行为**：发布前的测试是否验证了代码实现的安全行为（比如权限控制、加密、输入校验）？这不仅是测试有没有跑，而是验证“安全特性真的按设计生效”。
看到这里你会发现，这 7 个问题几乎就是软件供应链安全的现代实践清单，只不过 CRA 用法规的口吻把它变成了最低底线。最让我意外的是，它并不要求你做出什么超前的安全工作——只是把“好工程”做到制度化、可举证。这里的“举证”很关键：法规要的不是“我们做了”，而是“有证据、一致地做”。所以评估时要诚实，不要因为团队里有人手工做过一次就算“标准化”，必须形成书面定义、留下证据并持续执行。
这套清单能直接用到哪些场景？如果你所在团队开发的是具有网络连接、可升级的软件或硬件产品，且面向欧盟市场销售，那么从今天起就可以按这 7 个问题给每个发布流程打分。即使你的产品不卖欧盟，这套框架也能帮你找出安全流程的薄弱环节——比如发布可追溯性和发布强制拦截，通常是最容易被忽视的，等到事故查原因时才发现连“哪个版本用了哪些依赖”都说不清。要注意的坑是：别把“有工具”当成“已达标”，像 SBOM 这类东西，CRA 只要求至少覆盖顶层依赖，但你要做的是保证每个发布都能生成准确的物料清单，这就离不开可复现的构建链。另一个坑是过度依赖手动流程，法规认可“强制化”意味着自动检查应该能在不通过时阻止合并或发布，哪怕你团队小，也要在 CI/CD 里把关键检查卡死。
对多数组织来说，从“临时方案”走到“标准化”并不需要重构整个研发流程——把安全默认值写进模板、给安全敏感变更加一个强制评审标签、让发布包自动附加精确的构建记录，这些改动成本可控，但都能显著降低 24 小时上报窗口内的应对成本。CRA 的第一次强制上报日期是 2026 年 9 月 11 日，留给你的并不是“还有一年”，而是需要现在就把代码库的基线测量出来。先用这 7 个问题跑一遍，得到自己的真实成熟度，接下来每一项低于“标准化”的控制，就是你应该优先投入的改进项。
内容与图片版权归原作者所有 · 原文: https://hackernoon.com/7-questions-for-assessing-cyber-resilience-act-codebase-readiness?source=rss