近三年来软件供应链安全概念持续升温，新型威胁仍层出不穷，从Log4j漏洞到node-ipc组件投毒，近年来自软件供应链安全威胁涌现，企业违反GPL许可证的案例也屡见不鲜。

供应链安全事件爆发的频次和影响面都在持续扩大，供应链安全已经成为企业开展经营活动不得不面对的一个隐患，也是所有安全厂商致力于要解决的问题。开源是更安全还是更不安全？

王福维：《概念之下的开源软件供应链安全真实威胁》

此前，很多的对源供应链问题阐述，都会引入DevOps的流程，以这个模型来作为软件供应链安全模型，我们认为这样的模型实际上是有所欠缺的。因为它更多的是站在一个开发者的角度看待整个开发过程当中面临的问题，对于开发流程的上游以及下游缺乏足够的建模。

对于供应链相关方的模型，我们可将其分成三个角色：

①软件的供应者，其中包括自由软件基金会、大型的基础类型项目、独立开发者。其中，最主要的开源代码贡献者属于独立开发者；

②软件的消费者，除终端用户使用开源软件的二进制制品外，作为开发者为开发商业项目，不可避免的也会使用到开源代码，同时，开源工具及容器镜像的使用者，也在消费者定义之内；

③平台方，例如各家的云服务提供商，其实也是这样一个中间的状态：一方面儿他们是从开源生态中获取、封装像K8S这样的基础软件，同时他们又不是这些软件的直接使用者，而是作为一个软平台的基石去向消费者提供托管、服务和镜像。

这三个角色，并没有完全绝对的界限。例如腾讯的自有产品和服务的开发者，既是开源代码的消费者，又是提供服务的平台方；同时对于自身在业务中根据最佳实践，向上游开源项目贡献代码或者将内部项目反哺到开源生态，又具有生产者角色。

这三个角色的相互作用，形成了软件供应链。而针对供应链的威胁，我们认为本质是参与者站在任何一个环节里面，所受到上游威胁的直接和间接影响，以及对下游影响的透传，这是我们对开源软件这样的一个概述。

从技术角度，需要从“漏洞”和“后门”两个维度，对供应链威胁做明确的阐述。这两个维度，分别代表了开源软件相关方在供应链路中，被动遭遇的问题以及可能受到的主动威胁，这些威胁又各自有不同的复杂度和表现形式，以这两大类进行抽象，更有助于清晰地认识问题并提炼出根本解法。

首先，我们需要去明确的是，漏洞真实的威胁远远不止0day这么简单。对于漏洞在供应链当中所造成的、区别于孤立软件（如客户端软件）的效果，做了三个定义，即供应链对于漏洞的增强效应：

• 长尾，影响的软件和受众随着fork和依赖层级延长，漏洞的确认和修复时间无法收敛；

• 放大，对软件下游的影响随着依赖链路延伸而倍增，远不仅局限于直接下游；

• 隐藏，在不同开发生态中有各种供应链依赖形式，难以统一分析，且存在关注盲区。

这里以一个在案例分析中发现，且首次披露的供应链威胁实例，说明这三种效应，以及围绕着三点的威胁表象。

漏洞之于供应链的威胁

某由NGINX的二次开发项目**ngin*

1. 案例分析

该在上游NGINX项目基础上，引入大量增量feature，代码文件与上游存在普遍差异，无明确基线版本，因此对于上游项目披露的漏洞，进行存在性确认，存在一定的复杂度。

本例中，我们分析发现，该项目截止到2021.12都有活跃的开发维护，因此选取了一个NGINX在2021.03披露的漏洞，判断其修复状态。根据原始漏洞patch，很容易发现，该项目所基于的基线代码受到该漏洞影响，且该CVE漏洞的修复代码始终并未被移植过来。

进一步，我们注意到，根据shodan的数据分析，该二次开发项目具有极其广泛的使用者，主机数甚至达到原版NGINX的1/13。然而分析观察，可能是随着项目的变动，该开源项目已经失去了有效的维护，项目本身没有被归档，但也未声明停止安全修复等支持，面对开源社区的询问，仅表示其开源版本和“内部使用版本”存在断代。

2.案例延伸

对该案例进一步分析，可体现前述的放大效应。

长尾效应：随开发维护、fork链路延伸，下游失去上游背书，可维护性减弱。考虑到NGINX的商业版和开源版本，到该项目的内部与开源版本，逐级传递下，安全修复和支持逐步丧失，而再下游的fork项目则完全失去了得到安全修复的机会。

放大效应：fork二次开发项目，新增功能模块的实现存在对原有代码的平移，潜在保留了漏洞克隆风险。例如本例中，在额外引入的另一套SSL套件代码中，存在仿照OpenSSL功能模块，克隆得到的国密相关密码和协议代码，这部分保留有源头代码的未修复漏洞；在这些新增代码中，漏洞的存在不断得以复制。

隐藏效应：由上游开源项目做二次开发的实践形式，混淆了对应基线版本，功能backport行为杂糅了多版本，较难分辨出文件和代码块的来源版本和漏洞存在性。

3.核心问题与潜在解法

漏洞之于供应链的威胁核心问题，从治理角度触发，可期望通过开源代码使用感知和统一管理，尽可能消除已知威胁：

• 完整的依赖关系测绘，解决易忽视的次级依赖链路；

• 次生开源依赖质量评估，解决无条件信任的次生开源依赖；

• 动静态库模块化引用依赖，替代源码形式引用包含依赖代码；

• 细粒度代码成分相似度判定，规避开发中粘贴不可信来源码引入的威胁；

• 使用有更新管理的软件版本，而非长期使用一个工作即可的陈旧版本；

• 使用EPEL等源，或对编译制品专项维护，取代自行编译的软件版本在镜像中长期使用；

• 构建类似OSS-fuzz的开源分析与共享平台，扭转被动依赖漏洞相关信息披露的状态。

后门之于供应链的威胁实例披露

相比于漏洞，后门的威胁更多来源于主动攻击，近年来众多的软件上游投毒事件，证明了对DevOps全链路均有可能实现后门的植入，但过于零散的事件，可能让人忽视问题的关键，即后门最大的风险总来源于无条件信任形成的盲区。以下通过对DevOps中最信任的基础设施——Git的一个实验，说明这种信任的脆弱。

1. Git“历史篡改”：

Git一直被认为具备数据可靠性，关键是其存储的链式历史结构与去中心化。但近年Git仓库凭证泄漏事件频发，真的只有泄密风险，而不存在篡改和后门植入的可能吗？

这里我们借助开源工具BFG repo-cleaner，一定程度上实现了尽量“无感知”的git历史篡改。BFG通过对git历史commit中，敏感信息的全量修改，并强制覆盖远端分支数据，来实现保留历史提交信息不变的数据变更。借助这一能力，我们的实验中，在一个fork出来的bash项目中，针对一个历史commit修复的高危CVE漏洞，篡改commit内容，并保证该篡改在后续历史中得以保留，从而实现了无新增commit、无历史痕迹的历史漏洞（后门）的植入。

2.案例延伸

虽然这个实验中，git历史的篡改是“有条件”的，即篡改的远端分支，与该项目其它参与开发者的本地存储有数据冲突，可能被发现；但结合一些当下的特殊场景，这种攻击还是完全可以被用于构造真实的供应链后门攻击。

例如，在时下流行的云原生生态，一个热门的开发模式是围绕WebIDE展开的云端开发，该模式下实际没有了开发者的本地开发环境，那么对于篡改的git历史也就没有发现的机会。又比如在开源生态中，有各种git镜像的仓库，包括原本非git托管的项目在GitHub上同步的镜像，以及类似gitee这种镜像站；这些仓库是否与原本项目是否完全一致，作为使用者往往不会有意识地做额外的哈希校验。

3.后门之于供应链的威胁：核心问题与潜在解法

核心问题：①破除一切无条件信任；②具备对“意图”的感知；③解决规模化问题。

审视一切信任：对所有依赖的上游、使用的平台工具，以攻击者视角分析，及至假定面对的是国家对抗力量。

可控可信平台：打造具备充分的一致性校验、必要的多因素验证的平台、自主CI/CD平台以及全过程可审计、攻击可感知。

后门检测技术：基于一切三方不可信原则，打造源码、commit级、面向语义多维度的扫描能力以及动态持续测试机制。

开源协作建设：以生态的方法解决生态的问题，在自主可控平台上打造自主接入、可复制的扫描能力共建，并共享信息。

最后，对于现今生态或者说自由软件世界的现状的了解和方案的展望，随着自由软件世界的右转，缺乏成熟的商业化模式。更多的，是聚焦面向问题的技术环节的成熟，希望能够给行业更多机会和期待。

墨菲安全欧阳强斌：《软件供应链安全威胁与业界解决方案》

随着软件行业以及开源生态的发展，开源软件已经成为了整个数字世界的基石。软件供应链升级使开发过程越来越简单和低成本，有数据统计从2015年到2019年，开源代码的使用占比增长了一倍，现在已经到了78%的水位。平均每一个项目可能会引入超过100个开源组件，这其中可能有20%-30%的组件都存在不止一个漏洞，63%的开源项目如果直接拿来商用，会存在许可证侵权的风险。在过去的两年时间，从软件的生产到使用各个环节都已经出现了各种各样的安全事件。

开源技术应用、国际形势复杂、软件供应链的多样化，供应链各个环节的攻击急剧上升，已然成为企业主要的安全威胁。从黑客视角来看，针对通用软件供应链的攻击成本低，攻击覆盖效果好，可窃取数据、勒索、挖矿等多种获利方式。综合来看，供应链安全目前主要面临如何准确识别资产、风险如何检测或预防、企业治理低成本落地三大挑战。

具体来说，第一点是比如怎么去识别用到了什么样的开源组件，它的复杂性在于整个软件以及软件引入的场景，是非常复杂的，它有多种多样的形式，有不同的场景。

第二点，在风险检测上比如说投毒的背后其实是非预期行为，那预期和非预期你怎么去划定一条很清晰的界限呢？这个其实也是比较难的；开源许可证是自然语言描述的一些条款，导致没法通过机器百分百正确识别，也就导致在识别效果上需要做大量工作。

第三点是大部分企业都非常头疼的问题，发现了很多问题，怎么让研发工程师高效地修复。常见的问题会是：发现有很多的漏洞，这些漏洞有直接依赖引入的，也有是间接依赖引入的，那开发者要怎么去修复？这些漏洞这么多，应该先修哪一个？虽然在依赖配置了这个组件，但是代码中没有调用，或者没有调用有问题的函数。这些问题都影响着甲方安全团队的治理落地。

我们经常会考虑的一个问题是，怎么能保证获得更全面的漏洞信息，下面这个大概是一个比较理想的模型。首先，是我们需要有足够多的数据输入，那会包括像CVE/CNVD这样的官方漏洞库，以及包括像GitHub这样的第三方漏洞库；同时，还需要有所有开源项目的代码库变更、官方发布的公告、漏洞相关的舆情，再加上社区力量贡献。

从业界来看，huntr、debricked等初创公司推出了创新的产品，openSSF基金会在积极推进sigstore、scoreboard等解决方案，NPM、docker等包管理增强管控机制，CVE、SPDX这些标准也在不断演进。

总体来说开源软件供应链是处在一个安全风险高、来自攻击者和国家监管的关注度都很高的状态。一个好的解决方案，需要完善的工具链支持，以及丰富的组件、漏洞等知识数据才能够实现的。不管是组件还是漏洞，都在走向标准化，在未来可能会做得非常标准化。但是，现实到未来其实还有很长的一段路需要走，在接下来的一段时间，可能类似的一些风险事件还会继续发生。最后，像其他安全领域一样，在软件供应链安全这个领域，其实也没有任何的一个解决方案能够解决所有的问题，在当前我们仍然需要做大量的非常细致、琐碎的工作，才能取得一个比较好的效果。

下期精彩内容敬请期待！

如若转载，请注明原文地址