作者：公安部三所供应链安全能力中心

2024年3月29日，微软开发人员在liblzma/xz工具和动态库中发现一个涉及混淆恶意代码的供应链攻击。这是一起典型的软件供应链安全事件，暴露出供应链脆弱性给网络安全带来的威胁。在我国现行法律框架下，针对开源软件供应链安全风险问题，如何用足用好现有法律条款，防范开源软件供应链带来的安全风险是极其迫切的现实问题。

一、事件简述和现实危害

xz供应链安全事件的主要时间线如下：

● 2021年1月26日，GitHub账号JiaT75创建。

● 2022年起该账号开始向XZ Utils项目贡献代码。

● 2024年2月24日，在GitHub release中发布了第一个包含后门的版本5.6.0。

● 2024年3月30日，微软工程师Andres Freund在排查sshd服务异常后发现xz-utils的上游tar包问题，并报告给oss-security社区。随即引发各大安全厂商的轮番研判。

XZ-Utils是Linux、Unix等POSIX兼容系统中广泛用于处理.xz文件的套件，包含liblzma、xz等组件，已集成在Debian、Ubuntu、CentOS等发行版仓库中。作为一种通用的数据压缩格式，liblzma/xz通常也会集成在各类社区项目或是商业产品发行版中。

按照Red Hat等主要厂商观点，目前含有后门版本为XZ Utils版本5.6.0和5.6.1，主要在预发布版本中，尚未在Linux发行版中发现。已知受影响的Linux包括Fedora Rawhide、Fedora 41、Debian非稳定的测试版5.5.1alpha-0.1到5.6.1-1等。从安全技术问题的实质上看，本次xz事件的威胁主要是由于SSH底层依赖liblzma等组件，攻击者可利用后门在受影响的系统上绕过SSH远程连接的认证，直接获得系统权限，执行任意代码。

作为定性为非典型漏洞的供应链安全事件，xz事件中攻击者的操作尽管不多见，但并不是第一次在通过编译过程中构造和生产恶意代码。早年业界也有类似的手法表达，xz事件的攻击者或许就受其启发，但一般认为此类植入方式过于复杂和存在成功与否的概率难度，因此也有研究观点认为，xz事件是具有国家背景的APT行为。

二、我国有关供应链安全的法律规定

开源模式已经成为全球软件技术和产业创新的主导模式，开源软件或组件成为网络系统中庞大软件体系的主要基础。国际上的普遍观点认为有60-80%应用软件直接借鉴或建立在开源代码的基础上。对开源软件的依赖性普遍存在，开源软件供应链安全风险已经严重威胁到包括我国在内的大多数国家网络与数据安全，建立安全的开源软件供应链生态体系和规则已成为国内外关注焦点。

我国法律和行政法规层面没有专门对开源供应链进行规范，ICT供应链安全问题主要体现在关键行业的部门规章和标准层面，如早年发布的《关于境内企业承接服务外包业务信息保护的若干规定》和《银行保险机构信息科技外包风险监管办法》等。随着《网络安全法》《数据安全法》《个人信息保护法》《关键信息基础设施安全保护条例》等法律法规密集发布实施，我国网络与数据安全管理的框架基本成型。对供应链安全提出了明确和可解读的相应要求并设置了相应的法律责任，覆盖了管理制度、管理机制、产品与服务安全、人员安全、供应链管理活动等等。

《网络安全法》对网络产品、服务提供者保证安全和保护个人信息的义务作出规定，包括不得设置恶意程序，发现风险时的补救和报告措施，不得擅自终止提供安全维护，遵守个人信息保护规定等。

《数据安全法》《个人信息保护法》对数据安全保护义务、国家机关委托处理数据、个人信息处理者委托处理个人信息等问题作出要求。

2021年《网络安全审查办法》立法目的之一便是“确保关键信息基础设施供应链安全”，这也是我国目前为数不多出现“供应链”字眼的部门规章。该办法设定了供应链安全评估的基本原则，对关键信息基础设施运营者采购网络产品和服务的网络安全审查提出要求。

2020年公安部发布的《贯彻落实网络安全等级保护制度和关键信息基础设施安全保护制度的指导意见》将“加强供应链安全管理”和“确保供应链安全”作为主要内容。明确要求“网络运营者应采购、使用符合国家法律法规和有关标准规范要求的网络产品及服务，第三级以上网络运营者应积极应用安全可信的网络产品及服务。”

此外，《网络安全法》第二十七条对从事危害网络安全的活动等违法行为作出禁止性规定；《数据安全法》第三十二条第一款要求任何组织和个人不得窃取或者以其他非法方式获取数据；《个人信息保护法》第十条要求任何组织和个人不得非法收集他人个人信息。这些条款对于在开源软件供应链中的威胁行为也可适用。

三、开源软件供应链的监管难点

结合xz供应链安全事件，鉴于法律概念、供应链关系、违法行为人等方面存在的认定难题，尽管我国现行法律框架可以做出对威胁行为的适用性解读，但对于开源软件的监管仍存在两大现实困境。

一是在法律概念方面，开源软件的开发方和分发方是否能够认定为属于《网络安全法》下的网络产品、服务提供者，尚存在争议。有观点认为，开源软件属于网络产品，可参考GB/T 39276-2020《信息安全技术 网络产品和服务安全通用要求》标准3.2对网络产品的定义，“作为网络组成部分以及实现网络功能的硬件、软件或系统,按照一定的规则和程序实现信息的收集、存储、传输、交换和处理。网络产品包括计算机、通信设备、信息终端、工控网络设备、系统软件和应用软件等”，从该规定看，开源软件也属于网络产品，开源软件的开发者和分发者属于网络产品、服务提供者。另有观点认为，开源模式的特征便是开放、平等、协作、共享，开源软件的发布、传播、使用等环节都是免费和自愿的，本身并不存在商业化的交易行为，而开发者和分发者也无法对后续的商业化行为进行控制，如果将对网络产品、服务提供者的义务“前移”，对开发者进行规制会影响其积极性，不利于技术创新。如果强行认定，包括国际和国内的各类Linux发布厂商，还是GitHub应作为网络产品、服务提供者，也极具挑战。因此，开源软件不应该被定义为受法律规制的网络产品、服务。这也是早期各个国家的主流观点，在立法中也对开源软件开发者的安全责任进行豁免，或尽可能避免直接对开源软件的适用性进行阐释。

二是对于在开源软件中植入后门的开发者身份认定问题，实践中由于跨境追溯、网络匿名化等原因，很难确定行为人真实身份。即使能够确定，限于《网络安全法》的境外适用范围的局限性，执法机构存在管辖困难，当然这一困难对其他国家的公共安全机构的执法和调查也同样存在。对于部署后门后实施的窃取数据、个人信息等违法行为，以及由于该后门尚未部署到主要的稳定版系统和生产环境中，难以计算其具体的损害程度和后果，根据《网络安全法》《数据安全法》，即使执法机构有管辖权，但实践中很难落实处罚措施。

四、开源软件监管的制度思考

建立安全的开源软件供应链生态体系已进入监管视野，成为国内外关注焦点。公安、工信、网信作为《网络安全法》《数据安全法》《个人信息保护法》《关键信息基础设施安全保护条例》等法律法规明确的监管部门，也应重视对开源软件供应链的管理，夯实开源软件开发方、分发方、使用者等链条上的各方义务，通过生态合力共同实现风险治理，共建开源软件供应链安全治理生态。国际上，欧盟的《网络安全弹性法案（CRA）》引入了“管家”，试图设置“中间层”以区别于商用软件的提供者，同时又赋予了开源软件不同角色的职责；美国《开源软件安全法案》引发开源社区的强烈反弹，经修改后再次进入立法进程。这些国内外的立法和执法探索都说明，开源软件的供应链安全问题由于同时涉及到法律强制与协议约定的不同监管强度，不像一个人工智能的、可以推陈出新的“翻新概念”，而是错综复杂、新老问题纠缠的“保留议题”，因而不能一劳永逸或用单一治理进行解决。综合各国新近立法政策的动向和我国开源软件的法治进程，本文认为，良性互动、繁荣规范的开源软件监管需要考虑以下三方面：

一是充分利用市场化力量，将被动响应转变为主动发现机制，全面提升防范安全风险的能力。凝聚由科研院所、产品、服务厂商力量，形成软件产品的底数库，形成开源软件使用问题发现、反馈、解决等闭环机制，推动开源软件安全不断迭代升级。鼓励开源社区发挥自律作用，推动不同国家开源社区的交流融合，通过广泛的参与和安全开发规范的制定提升开源利益相关者行为符合性。

二是加强对开源代码使用方责任义务的监督检查。如果网络产品、服务提供者开发产品并使用开源代码，则开源代码成为产品的组成部分，需对产品的安全性负责。公安机关可通过面向关键信息基础设施等重要行业、领域的强制性基线监督检查和采购方的合同义务约束，包括由采购方合规驱动的对网络产品、服务提供者是否进行开源许可安全合规审查、事前技术评估和安全评估、制定和实施使用流程、开源物料清单建设等。

如果网络运营者、数据处理者、个人信息处理者等主体使用开源代码的产品，此时开源代码成为产品运营的组成部分，这些主体应当积极落实网络与数据安全法律要求的风险监测、漏洞补救等义务，但义务范围和认定上有别于网络产品、服务提供者。

三是强化打击力度，督促落实整改措施。积极适用网络安全法与数据安全法，特别是《关键信息基础设施安全保护条例》和强制性国标中的规则，如发生行为人在开源代码中植入后门、或网络产品、服务存在漏洞等安全风险，或产生危害后果，适用现有法律规定加强违法行为打击和处罚力度。通过一案双查、一案多查等工作机制，夯实开源代码使用者等主体的网络安全保护义务，加强开源代码管理作为数据安全保障措施的合规控制，及时落实相应整改措施，并在合规不起诉等制度中予以明确。

五、开源软件监管的技术建议

技术方法应对供应链植入后门的行为，可分为主动监测和被动检测。主动监测可建立威胁情报中心进行组件或后门事件的及时预警，另外可分析后门代码片段组成后门基因库以及根据SCA软件成分分析建立内部软件组件SBOM清单。同时，根据组件的历史版本数量，文件大小、Star/Commit数量等元数据，设定不同权重。实时监测清单中的组件变更情况，若发现变化，则使用静态扫描和动态扫描，再结合人工验证的方式植入后门行为的核验。被动检测处于事中和事后，属于被动行防守。首先尽可能的利用威胁情报进行，漏洞组件以及后门信息的收集整理，再利用静态扫描、动态扫描以及二进制文件分析的技术检测交付或使用中的软件及其安装包是否存在植入后门行为。

一是收集多源威胁情报，减少错误情报误导。多元化的情报收集策略不仅能丰富数据的多样性，还有助于交叉验证信息的准确性，减少被单一错误或恶意情报误导的风险，提高对复杂和变化快速的威胁环境的理解能力。及时的对最新出现的漏洞进行预警，在威胁被广泛利用前今早修补组件漏洞或植入后门事件对系统的影响。

二是使用SCA软件成份分析技术对软件中的组件进行分析。通过组件发现识别所有第三方开源组件，并构建依赖关系图以梳理组件间的依赖性，同时识别关键组件的供应商。与已知漏洞数据库进行对比，识别含有安全漏洞的组件，并验证组件来源的可靠性和完整性。

三是使用静态代码扫描技术进行特征匹配和语义分析。特征匹配是匹配黑名单特征，选择利用后门攻击高关联度的curl、dig、/dev/tcp，还有攻击者常用的恶意域名，如ceye.io、ngork.io等，正则特征速度快、效率高，但缺点是比较死板，攻击者较容易绕过检测。语义分析是从软件包入口代码开始，解析程序语义，通过指定污点汇聚点检测后门特征。

四是使用动态代码扫描技术模拟触发后门函数。攻击者在后门攻击中常常会加入各种混淆、加密等干扰程序分析的手段，甚至将恶意代码打包为二进制文件进行分发，这种情况下纯静态扫描能力就会出现瓶颈，需要引入动态扫描以作补充。动态扫描实现方式为在沙箱环境中模拟受害者触发恶意代码，扫描时可通过容器技术做沙箱环境隔离，在容器内启动测试应用引入待扫描的软件包，并调用对应软件包的关键函数，观察安装期间和使用软件包关键函数的网络、进程、文件访问行为、命令执行、域名访问、网络连接等行为，判断是否存在恶意代码。当后门的恶意代码被触发时，即可捕获到网络请求包详情、访问域名等信息，关联函数调用链路，定位到实际触发Hook点的文件位置。

五是二进制检测可以对源代码检测进行补充。针对一些软件无法获取源代码，因此可根据二进制检测技术进行无源码检测。静态二进制分析是将二进制代码转换为汇编代码的过程。一些反汇编工具可以将二进制文件转换为汇编指令序列，以帮助分析程序的代码结构和控制流。通过反汇编可以还原程序的指令序列、跳转指令、条件分支等控制结构，从而构建控制流图。动态二进制分析利用运行时插桩检测技术，检测应用真实运行加载的第三方组件，可排除未执行加载冗余的组件，检测精度高。相对的，仅能看到执行的代码，因此这种方法可能会遗漏程序中一部分。但是遗漏的部分也可能是程序永远不会触达的部分，就算有风险也是可以忽略。具体需要结合漏洞可达性进行进一步分析。

声明：本文来自公安三所网络安全法律研究中心，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。