“AI干的”不会在欧盟监管机构找上门时救你

欧盟的《网络弹性法案》（CRA）即将在数月后生效，标志着消费者网络安全保护进入新时代。该法规设定了两个关键合规期限：2026年9月11日起，须报告被积极利用的漏洞；2027年12月11日起，所有软件和硬件开发商须履行全部主要义务。在AI深刻改变软件开发的当下，组织必须立即行动，以降低网络安全风险并确保能在欧盟市场销售产品。

CRA并非针对特定领域的法规，而是首部“横向”法规，适用于在欧盟销售的几乎所有联网产品或软件。其广泛范围不区分人类编写或AI生成的代码——这是现代软件开发中的关键变革。组织正进入一个承担法律责任的时期，同时却越来越信任能快速生成代码的自主工具，而团队往往无法全面审查和理解这些代码。安全“最佳实践”正成为强制性要求，给整个软件开发生命周期（SDLC）带来沉重的文档负担，尤其是在AI编码工具大幅增加代码量的情况下。

“组织正进入一个承担法律责任的时期，同时却越来越信任自主工具。”

为满足CRA的尽职调查标准，组织必须提供简化、标准化的证据，证明其产品构建正确且维护安全。安全和合规负责人应立即制定准备计划。设想一下：审计和把关每一项安全实践——从每天数千次提交到生产部署和部署后监控——是一项巨大的协调工作。将新的合规要求融入日常工作流程非常耗时，尤其是在AI显著加速开发的背景下。

核心条款已定，尽管部分实施细节仍有待确定：

• 安全设计：安全必须融入开发周期的每个阶段（设计、编码、测试、部署），需要可审计的证据证明一贯遵循安全开发实践，包括确保产品上市时无已知可利用漏洞。
• 生命周期漏洞处理：合规责任不止于初始发布，还需要持续管理漏洞和披露。制造商必须承诺生命周期内打补丁和持续漏洞管理。关键的是，这一义务涵盖在整个支持生命周期内处理集成第三方组件（包括开源）中出现的漏洞。
• 彻底透明（SBOM）：为进行符合性评估，制造商必须提供特定技术文档，包括生成软件物料清单（SBOM）并展示组件透明度。组织需要可靠地生成CRA相关的指标和文档，包括特定的SBOM输入、生命周期支持数据和漏洞处理证据，以用于这些强制性评估。
• 快速漏洞报告：漏洞披露的延迟宣告结束。制造商必须在知晓任何被积极利用的漏洞后的24小时内向欧盟网络安全机构ENISA报告。这要求重大的行为和流程转变。

尽管具体的“协调标准”和最终指南仍在制定中，但核心法律义务已足够明确，组织现在就可以采取行动。

CRA将网络安全变为跨职能工作，责任不再局限于孤立的安全团队：

• 开发人员与工程领导：负责处理发布速度与可证明的安全设计交付之间的张力，并提供合规所需的可审计证据。
• 产品安全团队：负责漏洞处理、披露流程、SBOM准确性以及满足24小时内向ENISA报告的要求。
• 法律与合规：管理正式认证、与监管机构联络，并确保正确履行所有报告义务。
• 执行领导：负责治理、预算和监督，必须确保存在审计线索以证明尽职调查和风险管理。
• AI领导与专家团队：在维持对AI输出信任的同时战略性扩展AI应用，通过管理容量限制和保持AI投资回报率。

鉴于核心规则已确立，应立即启动CRA准备审计以降低风险并避免最后冲刺：

• 全面清点：创建所有软件产品及其供应链依赖的全面清单，特别关注AI生成的代码和开源组件，这些在溯源和漏洞管理方面往往带来独特挑战。
• 记录实践：正式审查并记录安全开发生命周期实践——如果没有记录，监管机构会假定未实施。
• 实施SBOM工具：立即开始生成和管理详细、准确的SBOM。这一基础将为应对技术标准演变提供有力支持。

“AI生成的代码的复杂性不容忽视。监管机构很可能要求高度的透明度和人工监督。‘AI干的’不能成为安全漏洞的辩解。在开发者采用工具时，实施稳健的流程来验证、测试和保护AI生成的代码，总是比事后追赶更容易。”

合规窗口正在关闭。准备工作量巨大，积极主动的团队现在开始准备审计，将降低风险并避免最后一刻的慌乱和成本。最终，为CRA做准备不仅是避免处罚，更是构建更安全、更有韧性、更易维护的软件的催化剂。通过嵌入这些强制实践，CRA准备将转化为产品质量的推动力，并在追求信任和透明的市场中成为显著的竞争优势。