背景

随着企业内部架构越来越庞大，开发的东西越来越多，为了避免重复造轮子，势必会使用各种开源组件。这些第三方组件库构成了软件供应链的一部分，虽然它们的集成是有益的，但同时也给软件供应链带来了风险

在刚开始公司对供应链安全的防范并不是太重视，随着log4j，spring等开源组件接连爆出重大安全漏洞，企业内部也不得不认真开始考虑供应链的安全问题。

鉴于供应链安全带来的巨大威胁，公司内部也开始了对供应链进行了安全管控。我们管控供应链安全主要包括这几个方面：SCA系统的搭建，上线前管控，上线后监控，源头解决的探索。

自建SCA系统

SCA系统简介

先来说一下什么是SCA系统。

SCA（Software Composition Analysis）系统就是软件成分分析产品，通常在开发过程中对应用程序进行分析，以检测开源软件组件是否带有已知的漏洞，例如具有可用安全补丁程序的过期库，以及需要相应授权许可（法律风险）的商业软件或第三方产品。 说直白点，就是应用中使用的开源组件是否存在重大风险漏洞？是否存在许可证风险？

因此如果要做供应链安全就必须要搭建一套SCA系统，这里可以选择商用或者自建，如果预算充足当然首选商用，可以节省大量人工，缩短项目的整个周期；而自建的好处就是自主可控，易于扩展。选择哪种方式要根据公司的实际情况进行选择。

SCA主要包含两个方面，一个是应用中开源组件的识别以及开源组件漏洞库。

开源组件的识别

通过分析应用的依赖文件，识别其依赖的三方组件清单，分析依赖组件的名称、版本，将组件信息保存到统一的数据中，这是其它操作的基础。我们公司的技术栈主要是java，我们就首先实现了通过分析java项目的pom文件来提取用到的组件。另外一种方式就是应用打包后直接去提取lib库中的组件来进行补充。

漏洞库的搭建

这是SCA系统中最重要的部分，而且是投入人力最多的地方。我们借助于外部三方的漏洞平台并加以整理来构建企业内部的风险组件库。通常风险组件库会开放给到业务侧的应用研发，因此需要在风险组件中，描述其潜在的风险信息、以及对应的修复建议。漏洞库搭建的过程是一个缓慢的过程，需要不断的跟进调整。

比较常用的漏洞平台，包括：

上线前管控（重管控）

第二步我们做的是阻止风险组件上线。按照SDL生命周期，可以选择在开发阶段，测试阶段以及上线前做管控，由于实施的成本以及效率问题我们不能在每个阶段都去做。本着越早发现漏洞，修复成本越低的原则，我们选择了对预发布代码库进行扫描以及Jenkins卡点来实现上线前的管控。

代码库扫描

我们将预发布环境的代码接入了SCA系统，这样应用发布到预发布以后，可以直接同步到SCA系统进行同步组件风险分析，将分析的结果输出并建立工单通知相关的负责人进行跟进处理。

jenkins卡点

考虑到误操作或者其它原因有可能绕过代码库的扫描，因此需要在正式上线前再进行一次扫描，我们通过Jenkins插件实现了这一作用，在Jenkins发布时如果扫描到风险组件禁止上线。

上线后监控（重监控，应急）

产品上线以后，还需要不断跟进。因为当前众多产品都是基于开源组件或者是公司通用组件，这些开源组件或者通用组件的安全问题可能是不断更新的，因此有必要及时监控，预警，跟进。这个阶段需要有一个平台能及时追踪最新预警信息，同时要能根据预警信息快速定位相关产品，通知相关产品负责人及时升级修复问题。同时要有负责人反馈机制，以便后续的责任定位。

在应急时通常不会直接通知相应的项目组去升级组件，在漏洞刚出现的阶段我们首先采取临时解决方案，当厂商更新了稳定的修复版本时在通知相应的项目组进行修复，这样做是为了避免频繁的更新。

源头上把控风险

这里大家可能有点疑问，如果可以从源头上解决风险，为啥还要做上面的那么多。最开始我们也想要直接从源头上解决这个问题，实际操作下来就会发现各种问题，如开发人员私自从外网下载组件，新来的开发人员不明确组件使用流程，各个项目组使用不同的私服等等。

各种措施都不能保证100%的效果，因此需要多种方法共同作用。

加强安全教育

建立公司内部安全组件基线，并对风险组件的引用制定相关流程，明确组件的获取渠道、使用方式，并针对使用不合规组件的行为建立处罚机制。

构建安全组件库

建立公司内部统一私服库，对第三方组件做一个安全检测，检测通过的组件会进入安全组件库进行存储，应用在构建过程中需要依赖的三方组件需要从该安全组件库中进行获取。

总结

供应链安全我们也是从零开始做起的，目前还存在很多问题，后续在运营中可能会逐步改善发现的问题。各位如果有什么好的点子欢迎来交流。