论坛回顾｜技术驱动——打造最实用的软件供应链安全工具

大家好，我是欧阳强斌，来自墨菲安全专注在软件供应链安全领域的一家创新公司。很高兴能够在这里分享我们对软件供应链安全的理解，以及我们以技术驱动的产品实践。

1905 年供应链的概念就被提出来，然后引申到了软件供应链，软件供应链 最早在1953 年就出现了。那时候雷明顿公司卖的是右图中的商用计算机，在出售商用计算机的时候，会附带提供他系统的源码，这也是最早的开源软件，所以说软件供应链安全其实是一个比较老的话题了。

2015年，国内发生 XcodeGhost 事件，当时是有 1.2 亿的用户下载，通过带后门的 Xcode 开发出来的 IOS APP 同样也带后门。类似这种由编译器引入的风险、攻击事件，最早在 1984 年就被提出了。当时 UNIX 的创造者提出：如果在编译器里面加了后门，开发者是很难发现的。所以他当时做了一个原型，在编译器里面加入后门之后开发出来，开发者使用编译器编译出来的软件也带后门。攻击者可以通过这个后门去获得相应的系统权限。

过去-2015年

我们来看软件供应链安全的发展时间线，在 15 年是一个分界线。在 15 年之前，比如说软件供应链的投毒在 03 年就已经出现了，但是这些事件可能没有那么广泛的被大家知晓。而在这个阶段，事件主要针对开源软件，风险相对来说是局部的，例如他没有涉及到整个流程中的分发环节的风险。然而那个时候互联网的发展也没有像现在这么普及，会关系到国计民生，所以没有造成特别大的影响，因此也没有体系化的解决方案。

2015年-今天

在 15 年之后，事件数量是在快速地上升，它背后是整个开源代码的快速地发展。

最近这几年，从整个软件的生产到使用，在整个链条里面发生了非常多的典型事件。例如：开发的阶段，恶意地去提交代码，代码库被入侵，去篡改；构建阶段，构建的非官方代码，存在后门，构建的依赖存在漏洞；分发阶段，分发错误的代码，对应的包管理仓库可能被攻击之后被篡改；终端消费者下载一个来自仿冒官网的假冒软件。所以在整个流程里面都可能出现相应的安全风险。所以整个业界就开始去思考怎么去体系化地解决这些问题。

业界积极探索体系化解决方案

首先在标准框架的层面，大家会提到 SBOM/VEX ，SLSA 治理框架，以及通过安全积分卡去度量开源软件的安全能力。

然后在风险识别的能力上，大家提到最多的是软件成分分析，从源码-固件-二进制等等各种形态的分析。当然还有比如说许可证合规，企业内部的私有源管理，供应商的管理，以及引入之后获取情报的能力。以上都是在风险识别上很重要的解决方案。

还有一类，对整个安全基线的加固。包括从代码到制品的完整性的校验，对这个研发人员代码的身份校验，以及提供一个基础安全的容器环境。这些是整个业界在探索的一些解决方案。

从食品供应链看软件供应链

我们在去思考未来软件供应链安全应该是什么样呢？抛开软件，我们去看更成熟的管理体系，比如食品供应链，食品安全是比软件的安全更为敏感的一个场景。我们看到市面上实体商品食品，他可不能像软件一样，我发个补丁。他只有要么销毁要么下架召回，一旦上市他的处置成本会非常的高。可以看到食品从原材料，到加工存储、批发零售，整个环节上任何一个问题出现问题，都会对终端消费者造成不可预估的后果。

参考欧洲食品安全的成熟管理体系，其中他的发展也是经历 1996 年疯牛病的事件，1999 年毒饲料事件。这些损失惨重的事件推动了出台相应的法规政策，去推动全链条的治理。

其中德国食品安全治理体系中能够做到对一个鸡蛋溯源来自哪个养殖场，哪一个围栏，是以什么样的方式去养殖的。整个溯源机制的背后其实是由监管机构做评估、立法、管理企业做相应的自检，消费者做监督，形成一套有机协同的治理体系。

其中德国食品安全管理原则-从农田到餐桌具体的管理原则共7项：

• 厂商责任原则

• 可追溯原则

• 官方的食品和饲料监督预防原则

• 预防原则

• 独立、科学的风险评估

• 风险评估与风险管理分离

• 风险沟通透明化

对应到软件供应链安全，我认为它就应该像食品一样，核心是更加的透明，体现在比如说食品的配料表、营养成分、存储条件，检验准入标识等等。

• 厂商要做到的是从源码到中间制品到整个产物的全流程的溯源；

• 监管机构要实现风险可以评估、处置。

软件供应链中，例如软件成分分析 SBOM 的使用约束，许可证的情况，风险信息管理，以及对整个软件的安全准入的评估。所以需要从监管机构到软件提供者，不管是企业还是个人，还是软件终端的使用者去做有机的协同。那这是我们对整个治理的理解。

软件提供者在治理生态中的定位

软件提供者在治理体系中，要对自身去做控制去做管理。并且发现风险，向风险下游，以及监管机构、公众去做预警。这些是需要相应的产品能力去做支撑的，包括管理体系的能力，控制的能力，由产品和数据组成的技术能力。

管理体系包括制度、流程、规范。

控制能力：引入前预防，例如漏洞攻击风险，供应链断供的风险以及知识产权的风险。需要控制引入的东西是什么？至少包括开源的组件，比如像 Log4j 的开源组件，还有商业软件，通常是闭源的软件，包括引入前的风险、准入、检测、卡位。在引入中需要风险的检测，风险修复，以及持续运营整个过程。引入后相应的情报能力，应急止损、溯源的能力。如何做到风险管理？最底层是来自于漏洞软件和合规的知识数据，去支撑相应的产品能力。

企业风险闭环治理基本逻辑

对于企业而言，去治理风险的基本逻辑我们经常会说跟看病一样。

第一步化验，首先拿到 SBOM ，知道我有哪些资产；

第二步问诊，拿着化验单对应有什么样的风险；

第三步治疗，针对风险进行“开药”如何治疗；

第四步监测，往往经过一次治疗是不够的，因为健康状况是在不断的变化，所以需要去做持续的监测，持续的监测风险、资产。

以上流程在落地实践中，同样存在有四大痛点。

化验阶段，资产识别能力不足，源码、二进制识别能力；

问诊阶段，漏洞识别不全、不准、滞后；

治疗阶段，修复成本高；

集成阶段：流程不标准，管控落地难。

源代码级的软件成分分析挑战

从源码识别，主流的开发语言都有相应的包管理机制，比如图中 Java 的 maven 配置文件，pom 的配置文件也是比较复杂的，其中有很多的高级特性，包括配置的继承。

二进制文件成分分析挑战

难点：

1. 从源码到二进制，源码特征消失，比如依赖信息，函数符号信息；

2. 不同体系架构，指令不一样；

3. 打包压缩直接分析很困难。

解决方案：

1. 提取真实的二进制，需要适配常见的压缩安装包

2. 识别特征的字符串常量、函数符号特征等基础的特征维度

3. 从特征的字符串常量、函数符号特征等基础的特征维度去识别，其中从语义特征上，通过审计网络去训练模型，从控制流图里面提取转化成向量，把问题转化成一个向量的搜索和匹配，去找到汇编代码层面和它最相似的一个二进制文件

全球主要公开漏洞库

从全球来看，已经有了比较多的公开漏洞库，包括 cve 、cnvd 。

cve 从 99 年开始运营，是最早开始运营的权威的漏洞库， cnvd 从 05 年开始运营，涵盖了 cve 中的信息。由此对应的衍生库漏洞类型等等，已经有了这么多的公开漏洞库。但是我们发现这些公开漏洞库它存在一些普遍性的不足。

1. 漏洞覆盖不全：部分漏洞未被官方漏洞库收录，如fastjson的反序列化漏洞

2. 漏洞信息更新慢：CVE漏洞信息公开普遍滞后几天至几个月

3. 漏洞信息不准：CVE中的受影响组件模糊不清

4. 内容质量不高：缺少漏洞的利用条件、缺陷触发函数等有效信息

5. 标准化不足：不完全结构化、实体命名难互通

所以基于这样一些问题，促使我们自己去建立、运营我们自己的漏洞库。

墨菲安全漏洞知识库

首先还是从公开的漏洞库里面会获取全面的漏洞信息。同时我们会去关注开源代码的变更，厂商发的公告，以及像 Twitter 博客上大家在讨论的安全相关的舆情以及社区的信息。有了这些数据作为输入之后，我们经过清洗模型和策略加工得到一个基础的信息。同时我们安全专家团队对这个基础的信息再去做校验、孵化，再输出到漏洞知识库当中。

• 漏洞覆盖全、准、快

• 明确漏洞真实影响

• 各版本升级兼容性评估

• 明确是否线上真实调用

• 漏洞触发点及利用条件

1、漏洞样例

首先是漏洞优先级的评估，包括强烈建议、建议修复、还有可选修复；从真实利用上来说，会标注 poc&exp ，进一步说明利用条件是什么。在修复上，给出兼容性评分，希望通过这样的信息能够减少用户的决策成本。

2、版本号规范

第二块就是当我们有了这个漏洞之后，我们主要的版本号主流规范是 12 年由 github 的是联合创始人提出的语义版本的规范。可以看到其核心由三部分组成，第一步版本号的核心，它是由这个三部分的数字组成的，就是这个主版本、次版本以及这个补丁的版本，这三部分都是整数。

漏洞可达性带来的挑战

当安全工程师推动研发工程师去修复漏洞的时候：

第一种研发说没有用到这个组件，不需要修复，可能这是一个冗余的依赖；

第二种没有用到这个方法，漏洞触发不了，不需要修复；

第三种增加了相应的安全防御机制，漏洞利用不了。所以安全工程师，去盲目的找到一个漏洞去让研发去修，她可能会有这么一些话去回怼你。

解决方案从检测能力上，通过代码的静态分析，分析组件是否真实引入，判断是不是真的调了有问题的函数，进一步的我们可以去做相应的数据流的分析判断，是不是有相应的过滤转移机制。

常见恶意组件特征维度：

• 元数据：包名编辑距离（typosquatting）；

• 静态代码：敏感函数调用、数据流分析、信息墒；

• 动态行为：文件、系统调用、网络行为。

这样的机制是在持续地对抗的，在今年 7 月份的时候我们监测到在 npm 仓库里面有一些新增的包，会去获取当前运行的环境信息，判断是不是处在在一个沙箱的环境里面。如果他认为处在沙箱的环境，那他就提前退出，避免被你发现。比如说这个包使用了五种机制去进行判断，首先它会获取这个环境变量，拿到环境变量之后，看环境里面是不是配了淘宝的源，腾讯的源，用户现在的目录是不是他规定的一些黑名单或者说白名单。

第二是去判断环境变量的数量。通常在沙箱环境里面，一个沙箱只会跑一个检测任务，所以环境变量的数量是会比较少的，因为任务少所以做这样的一个判断。第三是判断包的存储路径是不是做了相应的修改，是不是做了流量的捕获？最后他判断包名的版本号是不是还存在，因为你可能做了相关的重新赋值操作，通过这样的一些机制，去绕过你的检测。

这就需要你的检测能力覆盖这样的场景。在修复上要体现兼容性，兼容性问题是根据研发使用场景不同不能一概而论。当安全工程师推动研发去修复的时候，研发很大可能因为因为评估不了兼容性选择不修复，所以我们在这块尝试做一些量化。

漏洞修复成本高：兼容性

兼容性问题我们在社区内也收到了很多反馈，比如说依赖升级某版本后不兼容。我们会通过收集社区内不兼容的情况，以及使用人数等等维度，通过模型去打分。

漏洞修复成本高：直接依赖VS间接依赖

比如安全在找研发去修复依赖的问题，可能研发同学会说我没有用到这个这个依赖，这个依赖不是我直接引入的，可能是个间接依赖，又不能把所有的间接依赖写成直接依赖，这样非常不利于依赖的管理。所以我们会在云端提前构建依赖关系，在修复的时候给出直接依赖的安全版本就大大解决了这个问题。我们的 IDE 插件的一键修复功能，就是用到了这块相应的数据能力。

在整个研发流程里，从组件地引入到开发到代码的入库构建部署，我们都加入了相应的插件，能够非常低成本地去和现有的能力集成。如果你有在这个流程以外的需求，你也可以基于我们开源的客户端（https://github.com/murphysecurity/murphysec），去做二次封装。所以我们希望通过这样的方式能够帮助大家去降低集成的成本，能够去推动整个治理管控的快速落地。

软件供应链安全并不是一个全新的问题，只是现在暴露出了严重的问题，以及面临着很多新的挑战。我认为在未来，治理的核心就是增加透明度，这其实是需要整个监管机构、企业以及个人的开发者、软件的提供者、下游的软件消费者去实现有机的协同。墨菲安全在不断努力在这里面提供针对软件供应链安全的全栈解决方案，能够去帮助用户客户去全面地准确地识别风险，快速地修复，高效的管理！

墨菲安全是一家为您提供专业的软件供应链安全管理的科技公司，核心团队来自百度、华为、乌云等企业，公司为客户提供完整的软件供应链安全管理平台，围绕SBOM提供软件全生命周期的安全管理，平台能力包括软件成分分析、源安全管理、容器镜像检测、漏洞情报预警及商业软件供应链准入评估等多个产品。为客户提供从供应链资产识别管理、风险检测、安全控制、一键修复的完整控制能力。同时产品可以极低成本的和现有开发流程中的各种工具一键打通，包括 IDE、Gitlab、Bitbucket、Jenkins、Harbor、Nexus 等数十种工具无缝集成。

添加 Abby 加入交流群