在FCIS 2024网络安全创新大会的实战攻防与供应链安全高峰论坛，悬镜安全技术合伙人周幸应主办方的特别邀请，发表了主题为“面向研发过程的软件供应链风险检测与治理”的演讲。

悬镜安全技术合伙人 周幸

以下为演讲实录：

大家好，我是悬镜安全周幸，本次分享的主题是“面向研发过程的软件供应链风险检测与治理”。我将从软件供应链安全背景，软件供应链安全治理代表性技术，面向研发过程的软件供应链安全治理三个方面来阐述。

01 「软件供应链安全」背景

首先我们要明确什么是软件供应链和软件供应链安全。

大家在各种各样的场合其实都看到过一些类似的定义。软件供应链安全是指软件设计与开发的各个阶段，来自本身的编码过程、工具、设备或供应链上游的代码、模块和服务的安全，以及软件交付渠道和使用安全的总和。

在软件供应链维度，我们可以把它理解为一个软件供应过程，这个过程最终形成一个链条，包含了上下游供应商之间关系的链条，也包含了研发和生产过程的链条。

本次分享的侧重点就是在研发过程中，整个软件供应链安全风险的检测与治理。

软件供应链安全管理体系

上图里是一个相对完整的软件供应链安全管理体系。安全工具链一般来说是最底层的工具支撑维度，再往上则是平台和体系的维度来支撑整个研发过程。平台化能力里面会包含安全管理、安全开发、安全交付和安全运营等维度。在软件供应链全生命周期有引入环节、生产环节和应用环节。研发过程则对应的是软件供应链全生命周期当中的生产环节。

软件研发、供应和使用环节的安全风险与应对措施

具体到软件研发、供应和使用环节的风险、痛点和措施：

02 「软件供应链安全治理」代表性技术

软件供应链安全治理代表性技术能力

软件供应链安全治理相关的技术能力，首先是以静态应用安全性测试（SAST） 为代表的白盒技术大家可能知道的比较多，也相对成熟。

传统的SAST工具依赖于静态解析，可能会产生较高的误报率或漏报问题。通过在SAST 中引入一些大模型的能力，如通过收集和处理代码库、历史缺陷数据、误报案例等数据，将代码的控制流和数据流信息构建成知识图谱，学习并构建相当于安全专家的跨文件、跨函数的复杂分析和漏洞验证能力，提供更准确的检测文本的分析和治理建议。

在代码修复层面，比如说数组越界，之前的白盒修复方案只能告诉大家通用的代码修复示例，但是如果有大模型介入，能够看到定义的字节和数组要怎么修改。

软件成分分析（SCA）的一些新的可结合的技术点，比如可达性分析（外部可达、组件可达、函数级漏洞可达等）。我们会发现其实组件有没有用，有没有引入，关键点在于是否触发这个函数。如果用了一些危险的组件，但可能没有用到那个危险的函数，所以在很多的治理和修复过程中可以用一些漏洞可达性的方案来去解决这一块的问题。

SBOM清单本质上是由其他工具产生的，比如说软件成分分析工具，容器镜像、二进制等，都能产出的一些清单。软件物料清单有国际的标准，但是对于大家来说，可能更好的方式是做一些人可读的台账。

SBOM 国际标准示例

这里列举了这三种常见的SBOM国际标准。当前国内因为软件供应链安全相关的行标和国标出台，大家都在积极参国内SBOM清单标准的推进和落地。国内也在积极尝试标准化SBOM格式，比如由OpenSCA社区发起，开源中国、电信研究院、中兴通讯等机构共同参与，更面向实战化场景的DSDX（Digital Supply-chain Data Exchange）格式。

现在国内的 SBOM清单一定是能够兼容国际标准的内容的。最早的SBOM的内容主要是为了机器可读。现在国内的SBOM清单和 SBOM台账要做区分。台账，一般来说主要是为了人可读，一般是Excel、Word 等。机器可读的虽然人的可读性比较差，但好处是统一规范格式之后，不管是供应商提供的，还是我们自己检测导出的SBOM清单，换了另外一个检测设备也都是可读的，这就是我们规范的意义。

随着国内的SBOM相关标准的陆续发布，SBOM 应用在兼容性方面相信是没有问题的。无论是国际标准还是DSDX为代表的国内标准，这4种SBOM清单标准都可以使用。

SBOM 清单台账生成

把研发过程分成外部研发和内部研发两部分，他们的区别就在于能不能拿到源码。

在自主研发的过程中，有自己的代码仓库，有的企业还会有组件仓库。那么就可以基于组件仓库和代码仓库进行一些触发式、定时的安全扫描。当然，是选择触发式的还是定时取决于企业用的工具和安全管理策略。一般生产分支采用触发式的，其他类型的分支采用定时的方式做安全扫描的情况较为常见。

还有一些外部开发或合作开发的，大部分只能提供二进制或者是制品包的场景。有些企业会要求供应商提供 SBOM清单。我们以前做风险治理的过程当中，有一些开发项目组在早期的时候没有办法把所有应用包提供过来的情况下，我们会要求他们提供一些 SBOM清单，这算是一个基础。

拥有提供的 SBOM清单，我们对于提供的制品还要不要进行安全扫描？答案是要的，所以我们这里面会有一个审查对比差异性，因为我们不可能完全信任别人提供 SBOM清单。所以提供制品我们也要做一遍安全审查。两个结果对比之后，我们会生成一个SBOM清单台账。

有时候会出现对方提供的和我们做审查得到的SBOM清单不完全对应的情况。一般原因有几种情况，一是从源码级别他们会引入一些清单，但是实际上在编码构建过程中没有使用；另外就是相关检测工具不一致出现了误报等情况。

03 「面向研发过程」的软件供应链安全治理

面向研发过程的软件供应链安全治理架构

软件供应链安全治理工作，我们要从哪几个维度展开？

首先是开源软件。开源软件广义上的定义，包含所谓的中间件、组件和相关工具。第二部分是采购的一些资产。第三部分是合作开发的一些外包软件。开源组件的引入，可以通过平台化的方式接入，但是单一供应商可能要采用上传的方式去做检测。

在这个过程当中，一般分数据展示、管理，场景和能力支撑等维度。在场景的维度上面，大家会看到针对于漏洞、后门的检测，风险面（包括许可证、组件、漏洞等），以及一些更具体的场景，像二进制、容器镜像包等。

此外，光有自身的能力还不足，还要有对外视野。比如说供应链攻击事件、攻击情报和漏洞库的情报等。

在管理制度方面，要包括针对于开源组件、供应链以及相关的采购和审查。

软件供应链防火墙

在研发过程当中，除了把这些维度的管理完成之后，另外一个经常听到的就是软件供应链防火墙。软件供应链防火墙的建立其实是为了在边界上阻断和告警。这个边界就存在于从外网仓库到本地仓库、编码侧人员去本地仓库拉取，以及底层流水线去本地仓库去获取几个维度。

这几个维度上，第一个就是把组件从互联网往内网拉取的过程。因为大家都知道漏洞、情报都是有时效性的，所以在拉取的过程当中，即使它发布了一些新的版本，但这一版本可能在这些时间已经爆出了新的漏洞。所以通过更新供应链防火墙的策略，可以对于一些新爆发的，比如投毒、组件漏洞等，对一些要拉取的动作做拦截。

在编码侧有两种，一种是在流水线上的，另外一种是在IDE上的。程序员自己在做本地环境和固件编译的时候，在构建的过程中一般会从本地仓库去拉取。这个过程当中通常也会做一次安全检测。因为你不会知道你的组件仓库，比如说我有5000个甚至更多，无法确定某些组件什么时候能够被企业内部技术人员用到。除了定时的对组件仓库进行检测之外，另外一个有效的方式就是在大家用的时候做实时的检测。如果有问题，可以告警并返回结果给相关责任人，明确告诉大家什么组件因为有什么漏洞，不能再使用，然后把这个策略返回到安全管理维度，再对组件仓库进行更新和退出动作。

DevSecOps流程中的安全检测

这是一个典型的DevSecOps流程。在这个过程当中我们能看到从最开始的编码侧研发人员的介入开始，从需求管理到技术研发，代码仓库，再到构建环节，以及上面从互联网端到整个制品仓库，以及下面的上线的管理流程、环境，这样的过程是在研发过程当中大家能够看得到的比较完整的一个体系。

在最左侧就是一些技术的使用要求和规范，比如说像建立SBOM清单和台账的一些基线。

第一部分是对制品仓库的检测。比如供应链防火墙的一些能力。第二部分是IDE的插件。IDE的插件包括软件成分分析、源代码审计等能力。第三部分是代码仓库的拉取，这里我们要做一些细分，比如说生产库、测试库、检测的频率和方式等。在构建阶段，我们可以在从本地仓库拉取时候拦截。在测试阶段，对于发布的制品做一些安全检测。

这样在整个生产链的过程当中，大家会发现还有一些门禁措施，不同的场景门禁措施也是不一样的。比如说对于第三方的软件，我们是采用黑名单还是白名单方式做管控。重要的核心业务代码，我们是采用漏洞评分的机制，还是漏洞利用行为做拦截。

结合供应链安全情报进行实时监测与预警

最后，讲一下在发现风险之后要做的工作。刚才提到漏洞的可达性，同时安全情报也很重要，比如供应链的投毒情况、后门、可利用性的验证分析等。可利用性里面会包含一些PoC和Exp。在可达性方面的分析，比如说用的组件有没有使用这些函数，这些函数的一些触发点。是否具备运行时的安全监控能力，以及在遇到投毒事件，0day/nday漏洞恶意利用的时候，能否做到及时的响应。

在风险排查过程中，经常会遇到用到组件非常多的情况，比如50个应用可能对应6000到7000个组件。这种情况出了问题要如何快速修复？一个思路是可以选择根据对应通用漏洞评分系统（CVSS）的评分，但这个相对来说比较僵硬。灵活点的话，可以结合一些外部的情况，比如说对于漏洞的PoC和 Exp的分析，结合源码定位到函数级别的可达性的分析，然后做一个整体的研判。这样就能够得到更佳的漏洞处置优先级排序。

所以未来，在应检尽检的前提下，要尽可能的结合安全情报，对漏洞的可达性、可利用性进行综合分析，这样能够减少在治理的过程中产生的一些脏数据影响我们高效的对组件或漏洞进行修复。通过软件供应链攻击的事件进行筛选排除，把资源的重心真正放在那些危害性大、对于业务可达的风险的治理上面。

以上就是我本次的分享，谢谢大家。