欧盟《网络弹性法案》为您做了什么(能做什么)?

Lobsters Hottest 新闻

摘要

本文讨论了欧盟《网络弹性法案》将于2027年全面实施,对含有数字元素的软件产品的要求,并主张该法案并非开源软件的终结,而是要求更好的工程实践。

<p><a href="https://lobste.rs/s/oy4gen/what_has_can_eu_cyber_resilience_act_done">评论</a></p>
查看原文
查看缓存全文

缓存时间: 2026/06/20 14:32

# 欧盟《网络弹性法案》已经为你做了什么(又能做什么)? 来源:https://nxdomain.no/~peter/what_hascan_eu_cra_donedo_for_you.html 《网络弹性法案》横幅来自 https://digital-strategy.ec.europa.eu/en/factpages/cyber-resilience-act-implementation,并添加了 FreeBSD、OpenBSD 和 NetBSD 图标(https://nxdomain.no/~peter/blogpix/cra-bsd-banner.png) © 2026 Peter N. M. Hansteen *欧盟《网络弹性法案》(CRA)(https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act)及其各种国际同类法案将在2026和2027年全面生效,新的法律要求被一些人认为对软件开发人员,尤其是开源开发者而言,充满风险或挑战。* *有人预测这项立法将是**开源软件的终结**,以及我们所知世界的终结。在本文中,我们将证明情况远非如此。* --- **注意:** 本文亦可通过*含追踪器但格式更佳的版本*(https://bsdly.blogspot.com/2026/06/what-has-can-eu-cyber-resilience-act.html)获取。 --- ## 是的,时间比你想象的更紧迫 正如我们在之前的几篇文章和演讲中提到的(稍后我会提供链接), > *2027年12月12日,就已经太晚了。在那前一天,欧盟*《网络弹性法案》(CRA)(https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act)*将全面生效。*2027年12月11日,*《网络弹性法案》(https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act)*在欧盟成员国及关联国家和领土全面生效。从那天起,任何“*带有数字元素的产品(https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=OJ:L_202402847#art_3)”*的供应商都必须提供这些产品,并附上产品所用所有组件和依赖项的完整概览和洞察。如果你是一个*制造商*或供应商,提供任何“*带有数字元素的产品(https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=OJ:L_202402847#art_3)”*,都要求你提供这些产品,并附上产品所用所有组件和依赖项的完整概览和洞察。除非,当然,你是一个乐于被视为二流甚至没有资格获得利润丰厚合同的供应商。销售未获得其产品类别*CE 标志(https://single-market-economy.ec.europa.eu/single-market/goods/ce-marking_en)*的产品是行不通的。CRA 分阶段实施的时间线在*此处(https://eprnews.com/the-eu-cyber-resilience-act-685305/#compliance-timeline)*等处有概述。引自*欧盟 CRA:比你想象的更紧迫,是时候提升工程能力了!(https://nxdomain.no/~peter/eu_cra_its_later_than_you_think_time_to_engineer_up.html)*(也见于*此处(https://bsdly.blogspot.com/2025/09/eu-cra-its-later-than-you-think-time-to.html)*) 如果你想知道这在实践层面意味着什么——对于个体*开发者*、承担*自由软件维护者*角色的组织,以及更广泛的 IT 行业社区或生态系统中的其他参与者——请继续阅读。 ## 从此以后,欧盟设定标准 *欧盟《网络弹性法案》(https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act)* 是一系列不断扩展的立法的一部分,其中包括 *《通用数据保护条例》(GDPR)(https://eur-lex.europa.eu/eli/reg/2016/679/2016-05-04/eng)*、*《金融业数字运营韧性条例》(DORA)(https://eur-lex.europa.eu/eli/reg/2022/2554/oj/eng)* 以及 *《网络与信息系统指令》(NIS2)(https://eur-lex.europa.eu/eli/dir/2022/2555/2022-12-27)*,这些法规在欧盟、关联国家及领土范围内对信息技术和带有数字元素的产品进行监管。 其根本动机是保障欧盟、关联国家及领土居民的安全、福祉和公民权利。牢记这一点对于理解监管背后的基本驱动力非常重要。 从表面上看,旨在保障个人和企业安全的举措不应引起争议。新技术的发展带来了社会变革,无论是技术人员、他们的客户还是他们选举的政治家,都未能提前预见这些变革。 我们稍后会提到一些关键事件,但总体来看,这些事件清楚地表明,有必要制定明确的立法以及坚定而合理的执法制度。 在*网络安全*和*数字韧性*领域,长期以来,出于所有显而易见的原因,欧洲和美国的规范制定和标准化工作都相当同步。 早期,美国率先以2021年5月12日的 *美国第14028号行政命令——改善国家网络安全(https://www.federalregister.gov/documents/2021/05/17/2021-10460/improving-the-nations-cybersecurity)*(2021年)的形式,针对这一主题领域制定了正式立法;而欧盟最终在2024年通过了其版本的立法,即 *欧盟《网络弹性法案》(CRA)(https://eur-lex.europa.eu/eli/reg/2024/2847/2024-11-20)* 。这两套立法的计划都是让具体部分逐步生效,并在大西洋两岸保持同步。 然而,第二届特朗普政府用了1年零9天就撤销了 *2021年5月12日的美国第14028号行政命令——改善国家网络安全(https://www.federalregister.gov/documents/2021/05/17/2021-10460/improving-the-nations-cybersecurity)* ,使得这些规范和新出现的标准在美国联邦权力范围内的项目和采购中仅成为*可选*项。 而欧盟则没有放松其努力。这意味着,展望未来,是欧盟《网络弹性法案》(CRA)定义了那些为包括欧盟、关联国家及领土在内的任何国际市场开发带有数字元素产品(PDEs)的人所需遵循的参数。 接下来,我们来看看随着立法生效,不同类别的人群和组织将面临哪些实际后果。 我们先从乏味的部分开始,然后进入可怕的方面,最后才是有趣的内容。 ## 制造商、维护者和开发者 根据 CRA,参与生产或销售带有数字元素产品或组织的人员和组织可以分为几个类别。在开源软件扮演角色的背景下,最受关注的角色有: **制造商**:在欧盟市场上投放产品的企业,定义为: > 开发或制造带有数字元素产品,或委托设计、开发或制造带有数字元素产品,并以自己的名称或商标进行销售的自然人或法人,无论是有偿、盈利还是免费提供(摘自 *CRA 第3条第13款(https://eur-lex.europa.eu/eli/reg/2024/2847/oj)*) 关键在于,这里的情境是这些活动属于*商业活动*(*CRA 第3条第22款(https://eur-lex.europa.eu/eli/reg/2024/2847/oj#art_3)*)。 **开源维护者**:协调开源项目的组织,通常是基金会(非营利公司),定义为: > 非制造商的法人实体,其目的或目标是为特定带有数字元素产品的持续发展提供系统性支持,这些产品属于免费开源软件且旨在用于商业活动,并确保这些产品的生存能力(摘自 *CRA 第3条第14款(https://eur-lex.europa.eu/eli/reg/2024/2847/oj)*) **开源开发者和维护者**:编写和维护开源软件的人员。虽然 CRA 在此种情况下没有包含定义,但相关文本是: > 就本条例而言,非营利组织开发的、属于免费开源软件的带有数字元素产品不应被视为商业活动,前提是该组织的设立方式确保扣除成本后的所有收益均用于实现非营利目标。本条例不适用于那些为不属于其责任的、属于免费开源软件的带有数字元素产品贡献源代码的自然人或法人。(摘自 *CRA 序言第18条(https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=OJ:L_202402847#rct_18)*) 如我们所见,有三个不同的类别,每个都有其特定的角色和义务。 ## 作为开源开发者或维护者的职责 如果你是*个体开源开发者*,我希望此时你已经从 *CRA 序言第18条(https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=OJ:L_202402847#rct_18)* 的引述中得到安慰,实际上你没有任何正式义务去做任何特定的事情。作为开发者,你可以完全自愿地对自己的工作流程进行任何想要的更改。 尽管如此,新出现的法律要求确实提供了*机会*,值得探讨。我们稍后会回到这一点。 *开源维护者*,根据对 *CRA 第3条第14款(https://eur-lex.europa.eu/eli/reg/2024/2847/oj)* 的任何合理解释,通常会是像 *FreeBSD 基金会(https://freebsdfoundation.org/)* 这样的非营利组织或基金会,其运营目的是支持项目的活动。这些组织负有一定责任,需要维持足够的基础设施和组织来支持诸如错误和事件报告、跟进制造商、报告机构或公众提出的任何安全相关问题等活动。 查阅 *CRA 第24条(https://eur-lex.europa.eu/eli/reg/2024/2847/oj#art_24)* 以及序言 *第17条(https://eur-lex.europa.eu/eli/reg/2024/2847/oj#rct_17)*、*第18条(https://eur-lex.europa.eu/eli/reg/2024/2847/oj#rct_18)* 和 *第19条(https://eur-lex.europa.eu/eli/reg/2024/2847/oj#rct_19)* 以获得更多细节,会很有帮助。 ## 另一方面,如果你是制造商 正如你所料,任何投放市场的产品的实际和财务责任在于生产和销售该产品的*制造商*。 制造商负责确保产品适合其预期用途,符合欧盟为其产品类别指定的任何要求,包括其预期用途所需的任何规范。CRA 在一定程度上扩展了按需提供产品信息的要求,包括一份 *软件物料清单(SBOM)(https://en.wikipedia.org/wiki/Software_supply_chain)*,其中应指定产品的组件及其依赖项。 一旦产品上市,制造商负责产品在运行中的持续安全,包括向指定机构报告安全相关的错误和事件。 执法制度的具体参数仍在制定中,但对于不合规产品和制造商的潜在制裁,根据问题的严重程度,包括强制召回已销售产品,以及最高可达 *1500 万欧元* 或 *制造商上一财年全球年营业额的 2.5%* 中的较高者(见 *CRA 第64条(https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32024R2847#art_64)*)。 ## 但为什么?为什么是现在? 那么,为什么需要这样的立法呢?为什么现在才生效? 解释为什么需要《网络弹性法案》这种模式的立法,我们需要回顾一些历史。有一系列事件导致我们走到今天这一步,并塑造了我们在软件安全和软件质量背景下的自我认知。 值得记住的是,在近期相当长的一段时间里,软件被公众理解得很差,普遍被认为不重要,或者在被认为至少并非不重要的情况下,也被该领域的主导参与者视为*商业秘密*,因而对任何真正的安全或质量检查都遥不可及。 一个非常明显的后果是,很大一部分自称“IT安全”或“网络安全”的业务,其核心是销售工具,用于扫描它们能获取的任何数据,以寻找不断增长的*恶意软件签名*集合,或者在网络流量捕获的情况下,寻找诸如探测常见错误配置或已知可被利用的漏洞等恶意活动的迹象。 另一方面,在行业的*开源*部分,由于系统源代码可供研究,关注代码*质量*和代码*正确性*不仅是可能的,甚至是受到鼓励的。 当源代码触手可及时,如果你的代码足够有趣,被认为可以在与你自身环境不同的环境中使用,那么外部审查可以而且*将会*发生。 有了源码在手,一些项目甚至采取了额外的步骤,不仅改进代码质量和正确性,还创建了机制,使得即使代码中目前未知的漏洞和缺陷也更难被利用。可以说,*OpenBSD(https://www.openbsd.org/)* 项目在漏洞利用*缓解*和*预防*方面特别具有创新性。 代码质量在使带有数字元素的产品变得健壮和安全方面所起的作用,并没有被那些致力于制定 CRA 以及我们被期望采用的最佳实践的人们所忽视。 我们稍后会回到最佳实践,但首先,快速回顾一下近期的历史。 ## 历史上,“只是一点打字而已” 软件是一个相对较新的现象。在很长一段时间里——你可以可信地说,在其存在的大部分时间里——软件被社会和整个行业理解得很差。 曾经有过一个时期——我年纪大到能记住那个时期——软件被视为 IT 交付中一个次要的、有点烦人但必要的组成部分。 在更极端的情况下,你偶尔会听到有人说软件根本就不重要,实际上*只是一点打字而已*。 然而,对于开发者和从业者来说,越来越清楚的是,正是软件让所有那些昂贵的硬件变得有用。但对大多数人来说,软件始终是短暂的,而且在几乎所有情况下,源代码都是保密的,客户被期望照单全收,按原样接受。 这种认知随着时间的推移而改变,在最近几十年里,软件行业本身就是一个独立的行业,这一点已不再受到质疑。 尽管如此,在前互联网时代,将源代码作为商业秘密隐藏起来,被行业的大部分人视为创收的关键,并且对于实现可接受的安全水平而言,既是必要的,甚至是充分的。 ## 但后来软件突然变得重要了 然后,正如我们中一些人仍记得的那样,互联网出现了。 当时很少有人意识到,但这是历史上两个重要事件大约同时发生的时刻。 首先,对于开发者来说,至少变得显而易见的是,我们都依赖的基础设施,其力量和韧性主要归功于这样一个事实:它由基于“*粗略共识和可运行代码*”的标准构建的软件组成,而这些代码是开源的。 ## 不是10,000只黑猩猩在打字——

相似文章

关于欧洲技术主权及欧盟开源战略的通信

Hacker News Top

欧盟委员会宣布了一项全面的技术主权战略,包括《芯片法案2.0》、《云与人工智能发展法案》、欧盟开源战略,以及数字化和人工智能在能源领域的路线图。

⚖️ 欧盟委员会推出新技术主权方案

Reddit r/ArtificialInteligence

在美国限制Anthropic向外国公民提供其先进AI模型后,欧盟委员会发布了技术主权立法方案,包括《芯片法案2.0》和《云与人工智能发展法案》,凸显了欧盟对美国技术供应商的依赖。