零漏洞代码包为何仍是软件供应链的最大隐患

AI

软件供应链安全威胁已成为安全领域今年最受关注的核心议题。

Red Hat通过Lightwell针对应用层依赖项发起攻势；GitLab与GitHub相继推出AI服务，以提供更深层的代码扫描和软件成分分析（SCA）能力；Harness持续强化其在自动化流水线安全门禁方面的定位，用于拦截未经验证或不可信的第三方构件；Gartner也适时将该领域各路重要厂商纳入其评估体系。

在此背景下，专注软件供应链安全的企业RapidFort本周宣布与文件安全厂商ReversingLabs达成合作，共同推出开源依赖库（Open Source Dependency Libraries）——一个集策展与加固工具于一体、并由独立第三方验证背书的软件包目录。

RapidFort首席营销官Mike Wood在接受采访时表示，开发者需要从更广泛的视角审视供应链中的潜在脆弱环节，并牢记"如今，构建过程中最危险的软件包，可能恰恰是那些零CVE（公共漏洞和暴露）记录的包"。

"软件开发者不应该被迫成为恶意软件分析师。"

他强调，XZ后门、Shai-Hulud、Nx、Axios（一款广受欢迎的JavaScript HTTP客户端库）以及tj-actions等事件，远不只是普通的漏洞故事，它们本质上都是信任链的断裂。

"软件开发者不应该为了引入一个库而被迫成为恶意软件分析师，"Wood说，"这次合作让工程团队在他们已经使用的包管理器、已经依赖的开源库基础上，在软件包进入构建流水线之前多了一层独立的验证屏障。"

为实现其所称的"严格多阶段加固流水线服务"，RapidFort的开源库目录由ReversingLabs进行验证。验证过程采用"深度二进制恶意软件检测"技术，借助神经网络分析编译代码中原始可执行二进制文件的结构流，识别可能与威胁相关的隐藏模式或混淆手段。

"一个软件代码依赖项看上去完全合法，安装过程毫无异常，却依然可能窃取凭证、开启后门，或污染持续集成流水线。"

Wood进一步解释道："包管理器生来是为了分发，而非为了建立信任。近期的供应链攻击已经证明，一个软件代码依赖项可以看起来完全合法，安装顺畅，却依然能够窃取凭证、开启后门或污染CI流水线。RapidFort与ReversingLabs正在将信任决策前置，让开发者在承担风险之前就能获得保障。"

Wood及其团队指出，该领域的其他解决方案通常需要迁移到专有包管理器、定制操作系统发行版或厂商专属工具链。相比之下，RapidFort Libraries兼容任意操作系统、任意软件开发框架，以及通过pip、Maven、npm等标准包接口运行的任意应用包管理器。RapidFort Libraries支持即插即用式替换，无需迁移、无需中断现有工作流，也不存在专有操作系统发行版带来的平台迁移或生态系统单一覆盖问题。

Pentest Tools首席安全研究员Matei Badanoiu表示，"零CVE运动"近期正在获得越来越多的关注，从总体而言这是件好事，但它仍然无法覆盖未知漏洞。

"这里提到的几次失败——XZ、Shai-Hulud、tj-actions——都发生在漏洞情报根本观察不到的层面：维护者更迭、发布令牌被盗、CI工作流遭污染，"Badanoiu说。

他认可独立二进制级别的验证相比将清单与CVE列表进行匹配是一种实质性的进步，因为它检查的是构件本身包含什么，而不是外界对它的已知报告。

"不过需要注意的是，即便如此，仍然需要有人来判断某个内容究竟是合法功能、潜在的新型漏洞（无论是否有意为之），还是恶意植入的后门。XZ在5.6.0版本之前一直是'干净'的，"Badanoiu补充道，"有保障的开源代码库并不是新概念，谷歌本身也提供类似的项目。但重要的是，你在这里仍然是在把信任托付给另一方。"

Huntress高级安全运营分析师Michael Tigges也认为"有保障的开源代码库并不是新概念"，谷歌自身就提供有保障的开源软件（OSS）计划，而Wiz等厂商也为Docker等服务提供加固镜像基础。

"但值得注意的是，你依然是在把信任托付出去——只不过不再是委托给开源维护者和仓库管理员，而是委托给了提供保障的组织，"Tigges说，"这并不自动意味着软件包不含恶意代码；更恰当的理解是，有保障的软件代表的是一套经过审查的发布与审核流程。"

Tigges解释说，使用有保障软件源的用户，实际上是在为另一家组织对某个开源应用的专家判断、检测能力和分析结论付费。

"以XZ后门事件为例，在其被尝试纳入Debian、RHEL等多个发行版之前，无疑已有大量用户审查过这份代码库。这应当提醒我们：尽管我们对谷歌、RapidFort等机构的审查能力抱有较高信任，但它们同样不是万无一失的，"Tigges指出，"总体而言，有保障的开源软件是一件好事，它集中了信任，有助于将风险和责任委托给单一组织。但这也意味着补丁周期可能更慢，或者该组织需要达到极高的标准，才能真正确保其分发的软件是安全的。"

面对网络安全行业的种种努力，以及业界对软件供应链所蕴含的代码依赖与服务互依问题的深刻认知，软件供应链的整体形态将走向何方？

谨慎来看，前景或许将变得更加复杂而非清晰——Kubernetes的广泛普及、恶意行为者日益频繁地入侵开源组件，并将威胁深埋于容器镜像层级之中，这些都是传统工具力所不及的挑战。

公平地说，RapidFort与ReversingLabs已经正视了这一问题。两家公司表示，通过将ReversingLabs的Spectra Assure独立恶意软件分析服务引入RapidFort库目录中的每一个软件包，企业可以获取经过严格加固、并在进入构建流水线之前通过独立评估确认干净的开源依赖项。

然而，流水线与供应链仍在持续扩展。希望它们能够保持尽可能完整的功能状态，引领我们远离潜在的风险泥潭。

Q&A

Q1：RapidFort和ReversingLabs合作推出的开源依赖库能解决什么问题？

A：这套开源依赖库的核心价值在于，在软件包进入构建流水线之前，提供独立的第三方验证。它采用深度二进制恶意软件检测技术，通过神经网络分析编译代码的结构流，识别隐藏的威胁模式。不同于仅依赖CVE漏洞数据库的传统方案，该服务能发现那些"零漏洞记录"却仍存在恶意行为的软件包，覆盖信任链失败、后门植入、凭证窃取等CVE清单无法捕捉的风险。

Q2：为什么零CVE记录的软件包仍然可能带来安全风险？

A：CVE记录的是已知且已披露的漏洞，但软件供应链攻击往往不依赖传统漏洞。XZ后门、tj-actions等事件的根源在于维护者账户被盗、发布令牌遭窃或CI工作流被污染，这些攻击让软件包看起来完全合法、安装正常，CVE扫描却毫无反应。因此，一个没有任何CVE记录的软件包，依然可能携带恶意代码或后门，仅凭漏洞数据库进行判断存在严重盲区。

Q3：有保障的开源软件库是否能彻底解决供应链安全问题？

A：不能彻底解决。安全研究人员指出，使用有保障的开源库本质上是将信任从开源维护者转移到提供保障的机构，但后者同样不是万无一失的。XZ后门事件证明，即使经过大量用户审查的代码库也可能出现问题。此外，有保障的软件库可能导致补丁周期变慢，且提供保障的组织需达到极高标准才能真正确保安全，因此它是一种有效的风险管控手段，而非终极解决方案。