OSCS-软件供应链安全威胁与业界解决方案
背景
提到这个话题，其实它的背后是整个软件的发展，以及整个开源生态的发展，包括像云原生以及低代码这些新技术的发展，我们可以发现软件的开发越来越像是一个在搭积木的过程。这些积木，其实就是这些开源组件、开源软件。
有机构调研显示说，在2015年到2019年之间，整个开源代码在项目代码里面使用的占比是翻了一倍的，直到今天，它大概是到了78%的一个水平。
从上边的这一组数据来看，每个项目里面引入的开源组件可能会超过一百多个，这里面有28%都是有漏洞缺陷的。同时呢，这些有漏洞的组件，它不止存在一个漏洞，平均是两个三个漏洞，这些开源的项目有63%存在开源许可证的侵权的风险的。
所以我们可以看到，从软件供应链的生产到使用的整个链条，在过去两年都发生了非常多的安全事件。
从国家监管的层面来说，我们可以看到在最近两年，不管是中国还是美国，都出台了比较多的相关律法规，整个监管是越来越严格。
供应链安全威胁
从整个威胁来看，我们会发现对于攻击者来说，去攻击一个通用软件，它的攻击性价比是很高的，因为它的杀伤面会非常大。
在去年有两个比较大的漏洞的事件，一个是十月份的时候，境外的黑市论坛有一些组织去卖中国的银行的一些代码和数据，还有去年12月的Log4j2的事件，这些漏洞的事件影响力还是非常大的。
第二个是关于这个组件的投毒。在今年三月份，有用户发现说在这个NPM中有一个组件叫node-ipc，它针对俄罗斯的用户加入了一些反华的标语，包括在之前的版本是加入了这种文件擦除的逻辑。同时，这个组件的引用量非常大，每周下载量超过百万，我们可以看到投毒现在也变得带有政治色彩。
还有一类，关于这个开源许可证的侵权的问题，尤其是涉及到一些海外业务的公司需要注意。比如说GPL的开源许可证，它约定的是，如果你使用GPL许可证的代码修改了的话，你修改之后的项目，在发布的时候也是要提供相应的源代码，也就意味着，其实在商业使用上它会受到一定的限制。
接下来，我列举了两个标志性的案件：
第一个案件，2019年，柚子公司抄袭了数字天堂的GPL开源许可证，然后被告侵权的案件。这在中国是第一次把GPL的许可证作为侵权的依据。
第二个案件是在2021年，在中国的法院首次明确了GPL的许可证是有法律效力的，这也就意味着在之后开源许可证不再是一个君子协定，如果你企业违反了这些协议的许可证的约定的话，那么是需要付出相应的经济和声誉上的损失和代价。
面临的挑战
以上是关于软件供应链安全的一些威胁，这些威胁其实背后对应的是三大挑战。
供应链如何准确识别
首先是怎么去识别我们用到了什么样的供应链，背后的复杂性有多种多样的形态，它可能有不同的场景。
比如说像这个Java有比较集中的包管理的机制，但是像C/C++，相对来说它的包管理是非常分散的。
软件其实有不同的这种形态，你要去识别的可能是源码，可能是像Java这样的机制，也可能是像Windows下可执行的文件。
你要去检测的这些环节，你要识别的场景可能是在开发的阶段，也可能在线上的环境。其实就要求你的检测工具，你的识别能力是能够适应各种各样复杂的形态场景的。
风险如何检测/预防
当我们识别出来用到了什么样的供应链，我们怎么去识别有什么样的风险包括漏洞，我们的漏洞库是不是足够的全，你获取到的这些信息是不是准确的。比如像CVE，是不是足够的结构化。
像投毒这样的事件，它背后其实是非预期的行为，怎么去界定预期和非预期，怎么去界定这个期限，它是比较难的。
刚才提到的开源许可证，本质上是一些自然语言描述的条款。对于这些条款，机器其实很难做到百分百的准确识别。
企业治理落地难
对于企业来说，企业想要去治理这些软件供应链的风险，都会面临落地困难的问题。
比如研发同学反馈说，这些有直接依赖，有间接依赖，我们依赖这么多，要怎么去修复呢？
有的同学会抱怨漏洞太多了，如果我全都要修的话，我可能要修一两个月，那我就不用干活了，我们怎么判断哪些漏洞应该先去修，哪些可以放一放。
又或者研发同学可能会说，虽然在依赖配置里面，我是引用了这个组件，但是我代码里没有调用，那我到底是不是真实的受这个漏洞的影响。
最后说这个漏洞库漏报误报的问题，这些问题其实都在困扰着甲方的安全团队。如果甲方想要去彻底的去解决，他的整个边际成本是会比较高的。
业界解决方案
从整个业界来看，有什么样的解决方案以及我们的一些实践。
首先是关于开源组件的识别，也就是常说的SCA软件的成分分析，我把它大概分成了L1到L4四个级别，它实现的难度是递增的。
L1级别
我们看到很多的高级语言，它会有比较成熟的包管理器，我们可以基于它的依赖配置文件去识别，但是这里面也会有一些坑，比如说像右边这个是Java的这个maven的pom配置文件，在这里面它用到了一些比较复杂的特性，比如说它配置的继承关系，它的版本并不是直接书写，而是用了模板语言，所以不同的依赖可能有不同的作用域，如果你的识别工具并不能适配这样的写法和场景，就会导致识别出来的结果是不准确的。
L2级别
像C/C++这样的，它没有像maven这样统一的包管理器。那这样我们要怎么去识别？
思路大概是可以继续它的编译配置文件，比如说这个Makefile，然后去看它链接了什么样的动态库静态库以及根据它在本地的一些文件，比如说代码文件，去和云端的数据进行一个哈希的匹配，当然这就要求你在云端需要有相应的哈希对应的组件，以及版本的特征库。
L3级别
我们看到很多的比如C/C++的一些代码，研发同学在开发的时候，他不会完整地引入某一个组件，他可能看到某一个代码片段写得不错，就复制粘贴过来。那这个要怎么去识别，就需要对这个代码片段有一些识别的机制。
L4级别
相比在之前我们都是白盒去识别，可能还有很多黑盒的场景，比如说对于这个Linux Windows下的这些可执行的文件，以及安装包这些怎么去识别，这其实是对SCA能力的一个考验。
识别的结果，就是经常会提到的SBOM。SBOM大家可能会想到有不同的格式，那其实SPDX成为了这个业界标准，那常见的像SWID、CycloneDX这样的格式，都是能够满足大家的一个基本使用要求。
前面我们聊了组件的识别、软件成分的分析、漏洞，提到漏洞大家会想到CVE，那最近的一个变化是，我们现在使用的CVE格式的版本是4.0的版本，它是在2019年开始使用的，然后CVE预计在接下来几个月的时间内，就会切换到5.0的版本。那5.0的相比之前我放了一个对比的截图。
在5.0中，影响的产品信息，变成了一个必填的字段，在4.0版本中是选填的，所以导致现在很多CVE的数据是没有准确的影响组件的信息。同时，这里面它丰富了非常多的字段，比如说这个包名，以及说这个包的下载地址，以及说这个漏洞缺陷是在哪一个文件当中。这样一些丰富字段能够很大程度去降低CVE的漏洞数据和SBOM的一个关联的成本。
可以预见，在未来的一段时间，漏洞和我们资产的匹配可能会变得越来越标准。
关于漏洞，大家可能还会想到我们要怎么去能够构建一个尽可能全面的一个漏洞库，下面这个大概是一个比较理想的模型，首先我们需要有足够多的数据源，包括像CVE，CNVD官方的漏洞库，以及说像GitHub这种第三方的漏洞库。
同时，我们还要去关注这些开源软件，比如说代码库的变更，它发了什么样的安全通告，有谁在博客、推特这样的渠道去讨论这些漏洞的信息，我们还需要社区的一些白帽子去做贡献。
有了这些广泛的数据来源之后，这些数据经过清洗，主要是去除掉脏数据之后，可以给到AI的模型去做一些文本的分析，识别出这一段文本是在讨论什么样的内容。
策略系统可以帮助我们去基于已有的经验去识别，对信息做一些准确的提取，有了相对比较完善的信息之后，还需要专家团队人工的去对漏洞的数据进行校验，最后才能够保证说输入到这个漏洞知识库里面是一个比较准确的数据。
关于漏洞，我们怎么能够去更早的发现呢？
一个漏洞，从发现到提出issue，开发者去修复，发版本，然后发安全通告，从整个过程来看呢，我们会发现越往后面的环节，大家的关注度越高，但是越往后时间的间隔越短。
那么也就意味着，如果想要更早地去发现这些漏洞，就需要越往前去走，越关注前面的环节。
我们基于这样的一些理念去实践，我们实验室其实也在最近的这几个月多次提前发现了一些0day的信息。
从整个业界来看，有两个项目是非常有特点的，一个是Huntr，他们创业公司做的一个赏金平台，特点是对这个GitHub上所有的开源项目，它都去收取漏洞，那不管是提交漏洞，还是这个开发者去修复漏洞，都给你支付赏金，并且帮助你去申请CVE，它会有相应的一些定价标准。
第二个项目是在今年年初由微软和谷歌一块启动的，是基于Linux基金会下专注在开源安全领域的一个基金会，它们启动的叫Alpha-Omega项目，这个项目分成了两部分，一部分是会和开发者去加强合作，有更多的人工介入去帮助解决最重要的开源软件的安全问题。
除此之外，还有很多长尾的问题，长尾的软件大概有1万个，他们会给长尾的软件通过一些自动化的手段去发现风险，提供一些修复的建议。
关于投毒，最近有一个非常火的一个项目叫Sigstore，这个项目是通过一些自动化的签名和校验，去实现软件供应链的这个零信任。同样是OpenSSF基金会，他们有一个很重要的举措是在推动Python、Java、Ruby这样的包管理器，去使用Sigstore做签名校验。
我们可以看一下Sigstore大概的流程有几个环节，首先是开发者可以去申请签名。申请签名的时候，是会通过向GitHub登录的三方认证，认证通过之后，fulcio会颁发一个短期有效的证书，并同步到负责记录信息的模块叫rekor。
开发者拿到这个证书，就可以对制品进行签名，下游的制品的使用者，也就是下一个开发者，他就可以用基于rekor的信息去校验这个签名的有效性，这样就能够确定这个制品确实是合法的开发者去发布的。然后它有一个monitor的模块去审计rekor证书颁发的这个日志。
关于开源的许可证，我们刚才讲到开源许可证本质上是自然语言描述的各种各样的条款，所以就会发现开源许可证可能出现在各种各样的地方。
比如说可能会单独写在一个文件里，也可能会写在代码的注释里面，还可能会写在配置文件里面。它其实是不标准的，比如说像右上方的这个，写在这个pom文件里面的，可能名字和它对应的链接是冲突的，这样其实我们没有办法准确的去判断它到底想要表达的是什么样的许可证。
这块的标准，其实是SPDX。SPDX是在持续的推进这个开源许可证的标准化。我们看到它已经定义了400多个常见的许可证，并且已经有越来越多的这些开源项目在推荐，在使用它推荐的短标识，能够帮助机器去更准确的识别这个项目用到什么样的开源许可证。
关于漏洞，可能大家都会想到刚才提到的一些问题，比如说这个漏洞要不要修的问题，那漏洞要不要修，然后我们有什么样的优先级去修，这些常见的它可能会由以下的几个维度去决定这个事情。
首先是说这个漏洞它到底是有什么样的危害，这个项目到底是不是真的受到这个漏洞的影响，比如说有的研发同学会说，我只是引入了这个依赖，这个漏洞是不是真的可利用在外，是不是有一些公开的利用工具，然后这个利用条件是什么样的等等。
我们判断的依据是对整个漏洞知识库的数据字段有比较高的要求，这也就意味着，我们其实很难武断的去决定，去判断一个漏洞要不要修，它其实是需要背后有一个比较丰富的漏洞知识库作为支撑的。
关于漏洞怎么修，我们看到这里面的核心点是，如果漏洞在尽量前置的这个环节去修复，它的成本是会更低的。
所以我们核心在于要和整个研发的工具链去做集成，去降低研发同学修复的成本，在代码开发的环节，以及说在代码入库入仓的环节，我们构建部署的环节等等的这些环节，其实我们都可以去和相应的这些工具能力去做继承。
基于这样一些理念，我们做了相应的一些开源工具。首先我们的核心其实是检测的客户端，那右边可以看到我们使用界面的一些截图。
这个客户端其实干的就是两件事情，第一件事情是去分析这个项目里面用到了什么样的依赖信息，把这些依赖信息上报，然后和整个后端的知识库去匹配，发现存在的一些漏洞的情况，我们提供了一个控制台，可以去查看整个识别到的这些风险的情况。
我们还做了相应配套的IDE的插件，这个插件我们也发布到IDE的插件市场。通过插件其实能够帮助研发同学，在他的开发过程中就能够识别，并且能够帮助他一键修复代码中的依赖问题。
这是大概的一个交互的逻辑示意，客户端会识别依赖的信息和服务端的这些漏洞的知识、风险的知识去匹配，然后会返回结果到我们的IDE插件，到我们的客户端。
有了开源的工具之后，对于企业的安全团队要怎么样去做治理的落地呢？我认为核心可能是两个，一端是管理的制度，另一端是配套的工具支持。
从制度的角度上，它的核心在于我们需要首先有明确的要求，包括奖惩机制，因为这个其实是我们安全团队在做很多事情的的一个抓手。比如你可能需要先去发一个开源软件，安全管理规范的制度，在有了这样的制度之后，你才事出有因，能够去做相应的这些治理的动作。
那在工具的支持上的话，核心的是需要有几个关键的工具，第一个是需要有基于代码仓库，基于CI/CD，能够去旁路去先识别风险的工具。还需要能够去基于像比如说IDE的能力去检测，去修复漏洞，去帮助研发同学去解决问题。第三可能还需要有全盘的这种风险的视图，去帮助你做安全管理。
从整个落地的步骤来看，它分成这么几步。比如说你想要去开展一个这样的安全治理项目，事前事中事后会是怎么样去做的。在这里面可能涉及到什么样的工具，包括我们的一些开源的实现。然后在下面的其实是整个研发流程的一些关键环节。
假如你想要去开展一个治理项目，首先核心的点在于你可能需要结合这个代码仓库，以及说这个像Jenkins这样的CI/CD的能力，然后先去做一轮全面的风险的盘点，先识别出来整个公司，从项目上代码上有什么样的风险，基于这样的风险去制定对应的管理的机制。
第二步就是基于在前一步识别到的风险，去建立相应的这些治理能力，那这里面有两个关键的点，第一个是说这些风险的治理能力需要尽量的前置，那就会包括像IDE插件这样核心的能力，它的一个关键点是它能够推动研发的工程师作为这个安全问题的第一责任人，他能够在这个开发的环节中去解决这些问题。
然后呢，你还需要有相应的这种卡位的流程。比如说如果研发同学他没有用这个插件，那你需要有相应的这个识别的能力，比如说在代码入仓的时候，在项目发布的时候，你能够去对它进行相应的提醒，以及阻断，那这是很关键的一个卡位的机制。
那么在事后，你可能需要基于这个SPOM的清单去做一些应急响应，以及说基于风险管理的能力去评估整个治理的效果。
在中间的话，我们现在开源的一些工具，这里面会包括说和Gitlab去集成的工具，和Jenkins集成的工具，以及说我们开源相应的IDE的插件，我们检测的客户端，这些都可以在Gitlab找到，然后去做一个落地。这大概是一个比较基础的落地方案。
总的来说，对于整个软件供应链安全现在所处的一个状态，在过去一段时间出了很多的安全风险事件，可能这些风险事件还会持续的出现，但是我们看到它在变得越来越标准化，整个业界是在持续的推动它的治理，这里面一个优秀的解决方案，是需要有比较完善的工具链的支持，以及说有比较丰富的这些关于漏洞，关于组件，关于我们用到的各种各样的场景和知识数据的支撑。
在当前，对于软件供应链安全这个领域，也像其他领域一样，没有一个万能的解决方案，也就是没有银弹，我们在当前想要去很好的解决，是需要做很多琐碎非常细节的工作，才能把它做到相对可接受的水平。
关于OSCS
OSCS是开源软件供应链安全社区，社区致力于帮助每一个开源项目变的更安全，也让每一个开发者能够更安全的使用开源项目，促进开源生态的健康发展。
欢迎各位拥抱开源的朋友加入：oscs1024.com