软件供应链安全威胁的前线观察与行业方案原创

欢迎来到腾讯安全大讲堂的第14期，呃，我们今天的分享主题是供应链攻击的前线观察和业绩方案。呃，大家也都知道供应链安全最近两年是我们这个行业里面非常火爆的话题，从2020年年末的solo wind事件开始，到去年的lock罪，以及前不久也爆发了一个Java生态的spring事件，呃，我们可以看到供应链安全事件的爆发的频次和它的影响力都在持续的升级，所以呃，在今天这个环境下，供应链的安全已经成为了一些呃所有的企业去开展它的经营活动必须要去面对的一个问题，呃也成为了我们所有的安全厂商致力于想要去解决的问题。

那么今天的安全大讲堂我们就请请到了两位的呃，两位资深的专家就这个议题进行展开的分享，呃其中一位是来自墨菲安全的创始人欧阳强斌老师，墨菲安全是一家专注于做供应链安全解决方案的厂商，在这个领域有很多年的积累，所以欧阳老师在这方面是非常有发言权的。呃另外一位是我们云顶实验室的高级安全专家王福伟，王老师在一八年的时候就曾经设计和主导过一个供应链安全的挑战赛，所以在这方面也是很有很前沿的一些。呃，观察和。以很多年的积累，相信这两位老师今天给我们的分享会带来很多新的启发，嗯，今天的主要的议程呢，就是围绕两位老师的分享展开，在他们分享结束之后，我们有一个大概十分钟的答疑时间。

那大家在听直播的分享的过程中，如果有一些问题想要去呃讨论的话，可以在我们的评论区或者在我们的腾讯会议里面去进行留言，我们在之后会请两位老师来解答，呃，大家也可以扫描屏幕上方的二维码，然后加入我们的社群进行呃，进行最后后一步的沟通，呃，那我就先不多讲了，把时间交给两位老师，首先给我们带来分享的是王福为王老师，有请。好，我们线上各位朋友大家下午好，今天首先由我来为大家带来我们的第一讲啊，概念之下的开源软件供应链安全真实威胁。呃，刚才感谢主持人提到了，呃，我之前在一七年底到一八年的时候，曾经在所任职的公司和团队介绍了这样一个课题的研究，就是软件供应链安全，在当时的话，这是一个完全全新的话题，甚至于我们去刚介绍这个话题的时候，搜索完全没有任何相关的一些信息，然后在这个围绕这个话题我们需要去展开一个攻防比赛的设计。

呃，在当时来讲，这个话题本身很新，松然有一些当时的历史案例，但是案例都比较零碎啊，没没有办法去体现这样一个威胁的矩阵，所以当时的比赛可能也显得有些曲高和寡。但是这年我们知道链这个话题已经加门被大家反复提出来，说体现了中个什么的形式啊，而且也有一些相关的解决方案提出来，那么我们今天啊，首先由我来讲一下，在这几年期间，我作为啊，包括云计算厂商以及头部的互联网厂商，我们站在前线所观察和思考到的关于软件供应链安全这个话题的一些真实威胁，以及未知威胁所在。

好，今天的话，我的演讲脉络大概是这样的一个框架，可能大家都看过了很多的一些相关白皮书，那白皮书里面对这个问题已经做了非常系统性的以及啊事无巨细的了，呃讲解，那我们今天将不再追求这种事无巨细，我们想针对两个所抽象出来的大的问题领域来谈一下我们现在观察说为什么这两个领域可以代表着我们认为供应链威胁的最关键问题，以及可收敛的一些呃方面所在，呃，同时我们更主要的是围绕这两个议题，呃，向大家去披露两个我们所发现的一些潜在的微信案例，然后让大家对这样一些概念更加有一些提感。那么接下来我们还会再去想一下，我们认为的所谓现在的开源软件供应链现状如何啊，潜在的解决方案有什么，以及我们做的更多的展望。

啊，首先不能满足的是我们也要对供应链，软件供应链做一个我们所理解的定义，那么可能之前很多的对员工链问题阐述，他们都会引入流程啊，这个流程当中各个环节，他所面临的威胁和已知的攻击是什么，以这个模型来作为软件供应链安全模型，那么这一块的话，我们认为这样的一个模型实际上它是有所欠缺的，因为它可能更多的是站在一个开发者的角度来看，他这个整个开发流程当中面临什么样的问题，他对于这个开发流程的上游以及下游缺乏足够的建模，那么我们这边对于供应链这一块的建模是分成了三个角色，首先是要有软件的用者，那么包括比如说像这里举例的阿拉奇这样的一个自由软件基金会，另外像SSL这样一些比较大型的，呃，基础类型的项目，它也会有自己的开源项目的委员会。

对于这个开源项目的一些啊，比如说客户以及他的重要决策去做足够的指导，但是除了这些以外，最主要的开源代码贡献者是属于那些独立的开发者，那比如说GI上广大的用户群，他们都是潜在的开源软件的应者啊，与公用者相对应的是这个消费者，那么这块我们指的消费者不只是这些由开源代码而来的软件的，呃，终端用户，而是指比如说我们作为一个开发者，我们可能去开发我们商业项目里面不可避免的会使用到开源代码，呃，看工具使用者以及容器镜像的使用者，也是在我们消费者这个角色的定义之内。而除这两者以外，很不可避免的要讨论的是一个平台，平台方，那平台方我们一方面可以这么理解，比如说我们每个人在去做开发的时候，使用到些上游的项目，那么这种使用它可能往往不是说直接去引用啊，这个项目在GI原始状态，而是使用RA，它所维护的一个长期稳定开发版本，那么这样一个语境下面专就是我们这儿所理解的平台方，同时呃包各家的云服务提供商其实也是这样一个终端的状态，一方面他们是从者那里去得到，比如说像呃K8这样的K8S docker这样的一些开软件，同时他们又不是这些软件的直接使用者，他们把它作为一个软呃平台的基石去向消费者提供服务，另外还有很多的托管服务和镜像，那么这三个角色我们认为共同维护和维形成了这样一个所谓的软件供应链。

而这里需要提到的是，任何一方他其实并不是绝对分割开的一个三个角色之一，他往往都是有各种角色的兼任和维护，那比如说腾讯自己，他是作为平台方，我们的开发者，自己也是一些开源代码消费者，同时腾讯自己也会把自己的很多优秀的代码实践和优秀的公开项目最终变为开源，那么这个时候我们自己实际上也是公用者，那么这三者之间实际上是互有迁移的，那么所谓的软件供应链就是这三者之间的一个数据和呃信息的流转，而针对东量的威胁，我们认为本质也就是说我们正在任何一个环节里面，它对上游所接触到的一些威胁的影响，以及我们对下游所造成的影响，这个是我们对于呃，一开始要先去开通，开通去讲我们对于开源软件这样的一个概述。

在这个语境的对比之下，我们再来描述一下所谓的供应链安全或者供应链安全威胁。可能大家看了很多的一些相关的paper和文章，他们对于呃，现在已知的各种事件都去套入到这个供应链里面，但是实际上看了那么多太多的案例，太多的以供应链知名去分析事件，我们可能去忽略掉这个供应链本身的一些本质问题。

那我们之前在2018年去组织呃叫攻守道公安全挑战赛的时候，实际上都在后门这个领域，就是说我们认为如果我们使用的开源代码是不可信的，里面是可能会被人污染，那么这种污染实际上体现成为的就是后门，但实际上漏洞也是一个不可呃回避的问题，那么一会儿我们也会围绕着漏洞和后门这两个大的领域去讨论，实际上漏洞和后门分别体现出我们在供应链当中，一方面是被动的去呃迎接威胁，另外方面就是更多的站在攻击者角度，他去主动的去进行投毒，那么他对链所造成的威胁，那么接下来我们就会围绕这样一个矩阵去进行讲解。当然这里面首先需要去提出来，我认为真正的或者说最具威胁性的这样一个供应链的攻击，实际上往往是出其不意的，它从我们所预想不到的地方出现，并且对上游造成一个无法感知并且深远的影响，那么这一块也是后续我们去讲的一个呃，最关键点。

首先我们来看一下呃，漏洞这个环节，当然首先我们需要去明确的，呃，可能很多人再去看这两年陆陆续续出来的一些安全事件分析，讲漏洞，我们大多数都关注在零漏洞。呃，比如说像这样的一个漏洞出现之后，它对整个供应链造成大量的影响，但是漏洞真实的威胁远远不止零倍这么简单。比如说我们还讲到刚才所提到这处这个漏洞来讲，那么它是在去年出现的，但是它对生态的影响是非常深远。

到现在为止已经经过了这么长时间，它已经远远不再是一个零类的状态，那么它的影响实际上还是在持续存在并且发酵了，那么这里面我们对于漏洞啊，这样一个东西，它在供应链当中所造成的一个与本地环境不一样的区别，和做了这样一个三个定义，有时候我们叫做供应链对于漏洞的增强效应，一个是常委。呃，长尾它主要是存在于软件开发和软件运维当中的一个间接依赖的一个问题，那比如说我们作为开发者，我们自己的项目依赖于什么样的？呃，开源软件对于一些有包光器的语言来讲，比如说Java，实际上是通过这种没问的包光器是很容易知道的，如果他是一个CC加项目的开发者，那么他实际上也是有办法知道它所以库的形式去依赖的有哪些的开源组件，但是那些库他们建的依赖实际上是没有办法很好的去做一个完全准确测绘，那么这一块会造成一个上游的污染，对下游的长尾效应。

同时我们也不可避免的要去讨论，现在我们的开源软件，实际上除了上游的开发者以外，它还有大量的比如说各个发行版，他们去对软件做一个呃，长生命周期的版本维护，那么这里面碎动化实际上也是引入了大量的问题，另外就是放大效应，这里面刚才我们已经举的例子像了，这就是这样的一个例子，它是一个基石类型的项目，它的开发非常早，也被大量的下游代码所引用，有些代码实际上也有一些引用，它的下游代码实际上已经成为了事实上的一个现在的基础软件。那么这样一些基石类的开源代码，它在生态系统当中应强面是一个倍增甚至于指数级增长的一个一个效应，另外还要谈一下copy的这样一个威胁，那比如说我们开发者，作为开发者的话，可能都会知道说，与其说我们去写代码，如说很多程度上我们是在去做代码的组，那么这个时候，比如说很多人会去flow上面去找是否有符合我现在主要的一个功能的一个代码片段，但这样的代码片段它是rap的。

但是它是否能够保证它有足够的安全性，是我做到了充分校验，这些都是无法感知的，那么这样的代码是在整个生态，特别是对于一些商业代码来讲引入了非常大的威胁。另外就隐藏这一块，我们重点提到的是一个二次开发项目里面所对于一些漏洞的隐藏效应，那么这一块是我们下面要讲的一个例子所重点去进行阐述的。呃，这块我们去举的这个案例是之前没有去做过披露的，当然我们已经反馈给了相应的厂商啊，这个案例的背景是这样，我们再去做人工量的威胁的时候，我们去考虑到说开源项目他做了大量的fo和二次开发，那么在这本当中各家的实践是怎么样的，这些实践的方式是否可能会引入额外的问题呢？我们选取了一个著名的web server开源项目和它是一个非常基础的项目，但是它本身可能也会有各种各样的呃功能缺失，所以在开业领域的话，也会有大量基于N做的包装和二次开发，那比如说像op这样的项目，它是对于这个项目做了一个呃版本的封装，同时对他增加了一些额外的语言支持。呃，另外一个例子就是我们今天要去讲的这样一个某个头部厂商所公开的。

方法，它叫做某安的项目，那么这个项目我们去看，他在一直到2012021也说去年年底之前都是有着非常积极的代码更新维护的。

那么这个时候我们去找了2021年三月份的一个上游N次的高危漏洞是202123017，我们根据这个漏洞直接去找到这个。和某安的项目，我们发现这个漏洞，实际上虽然啊，因为这个漏洞所存在就是说打配置这个文件里面，呃，它引入了一些额外的增量代码，所以发生了一些代码下文的变动，比如说行号变动，以及额外的函数的插入，但是对于有漏洞的这个函数本身，实际上它的这个漏洞是一直未修复的状态。但是我们去看这样一个某安置项目，在收领上我们去进行分析，发现实际上它的用户体量是非常庞大的，在全世界来讲，它和原始的politicss的这个存量已经达到了1 : 13的这样一个非非常庞大的体，这个一个比例，所以对于这个问题的呃，受众影响是可想而知的，但是这样一个漏洞修复的话，我们知道它对于开源，特别是开源社区，比如说在上面它的一个好处就是有很多人的眼在盯着，那么总是有人去发现这样问题，那么这块我们可以去看，在这个项目的开源JB的仓库里面有人提供了这样的问题，但是官方给的解释是说，呃，某它是有内部版本和开源版本的，这两个之间是做着一些人工的同步，但是最近可能这个同步并不是非常的呃，有时效性，所以这一块实际。

是一个没有过公公开。安全威胁始终存在的状态，那么接下来我们再就这个案例做更深入的一点形容下的分析。呃，我们来看这样一个案例当中的软件供应链是什么样的。

我们刚才所提到的是这个某engine的开源版本，以及它使用的NS开源版。我们都知道NS它原来是俄罗斯的开发团队开文出来的一个非常重要的开源项目，但是在前几年的时候，他已经被呃头部的网络商哈五所收购，哈五在对他进行收购之后还保持了这个项目的始终开源，但他们同时也对这个项目做了一定的封装和补充，推出了他们自己的plus商业版本。那么这个engine plus plus商业版本和它的开源版本之间是否还有这样一些这个feature迁移的版本等待我们是不得而知的。然后开版本又继续向下游，到了我们刚才所提到的某的内部使用版本，一再下游是它的开版本，而再往下游看的话，实际上在开，在使用者这个角度来讲，他们往往并不是直接去使用GI上某engine的开版本，他们基本上都是会去取它所放出来的一个二次分发包，或者是取他最新的一个，那么这个type实际上也甚至都没有体现出来某N它的master分支的最新代码变动，所以他们使用的实际上是更次一级的陈旧的tag与fo，那么这过程是构成了一个比较完整的供应链，那么这个供应链当中。

我们可能就已经能看到一些问题，比如说在的上游开源版当中去做了一些bug，那么这个B它不一定是针对C漏洞的修复，可能有一些是内部人测试发现的安全问题，直接去进行修复，那么这些都是没有去同步到下游的，因为我们知道。在实际的这样一个开二次呃开源项目的二次开发当中，因为他对源代码做了大量的呃定制化，以及不可避免的他需要把一些呃他所维护版本的上游的更新版本的新增的功能feature同步过来，那么这是一个BY的实践，在这个事件当中，它对于自己所维护这一个版本做了大量的代码的改变，所以要想把上游的一些呃代码修复和commit去平移到我二次开发过的一个项目code当中，是有非常大难度的。

另外就是我们再进一步的去分析这个项目，实际上还能看到所谓的一个呃，长尾效应的更好的例子。就是这个当中，它实际上去做很多的，比如有加议的实当中相直接用open sll，它可选的去使用了同一家公司所开源出来另一个根据open sll做了二次开发定制的某SSL项目，然后我们就进一步的再去针对这个某SSL的开源版本去进行分析，发现实际上它也是面临着和某N类似的情况，在2021年三暂出的一个owner官方。

呃，高危漏洞，在官方给出来的这个漏洞修复的PA之后，整整200天的时间，这个修复代码才被合并到某SL的项目里面，那么这一块虽然修复，但实际上是有非常大的一个时间断代，那么这个所谓的增量代码的额外依赖问题，以及这个生命周期内的漏洞响应，实际上它的威胁也就足见一斑。同时我们再回过头来看这个NS，它是开源项目被生业化的一个非常典型的代表，那么他被收购之后，哪怕某有N啊，哪怕这个N开源版本和它的这个和最终被集成到n pass当中的代码是完全一致，但是n pass实际上是围绕着这个N做了大量的功能新增和模块新增，比如说它有一些和额外的负载均衡和一些安全功能，那么这些功能实际上是可能对于一些针对N本体攻击达到足够的控防效果，那么这个时候这些功能是没有出现在我们的开源版本里边，所以这样的一个啊，场景效应也是不可避免的，呃，隐藏效应也是可以通过刚才的描述进行理解，那比如说我们做了二次开发，代码有了大量的目全非的改变，那么这个时候，哪怕是我们作为。

一个下游的开源使用者，我们想去看说这个某安镇当中是否有一些官方历史修复过的漏洞，我们甚至都是很难去进行有效的分析，所以通过这个例子，我们足以去说明我们刚才所所谓的三个，呃，漏洞在于软件公链当中的三个。

和发挥作用的效应，那么这我们再去做一个神而向而上的总结，呃，针对于一漏洞这个问题，我们看他在链当中的一个核心，实际上就是存在一些盲区以及管理的不到位问题，对于这样一些问题，实际上应该都是有办法可以去解决的。那比如说如果说这样的问题存在于刺激依赖，那我们就可以想办法去对我们现在的项目，它所有的直接依赖，刺激依赖和完整的依赖链路作为一个关系的测绘，如果是一，如果是这个我们对于某一些自身的开源，那比如说刚才的这个某安准，相比于N，这次它是一种次身开源的话，我们可能之前都是有一些无条件信任，认为它既然用户体量足够大，那么它必然是安全的，对这个问题我们可以去以公击者视角来额外的去做质量评估，另外在于这个开发的实践当中，我们经常会看到有一些开发实践当中。

他对于开源项目引用不是以包的形式，而是把开源项目本身直接以set party或者getate models形式放到我们的项目当中，那么对于这两种形式的话，我们要说把这种码形式引用改变这样一个形式引用，如果它是形式引用，那我们要保证它这种Mo始终去跟进官方的最新。另外可能还有下面的一些问题，我们都是有一些对应的解法，当然这些问题就不是我们今天所讨论的关键点了。而最主要的是我们这后面也会再去提到，作为整个生态来讲，我们每个人都是生态的参与者，我们之前可能更多的是被动的依赖于漏洞，一些信息的披露和响应，但是我们这儿可以看到，呃，如果不考虑说这个公关的问题，只是说对于零的漏洞，大家都是有一些挖掘的，那我们不妨类似于谷歌的这种S一样，我们去构建这样一种开源的共享的分析平台，来对这种公链当中的，比如说二次开发项目的历史流动扫描，做一个啊生态解决方案，这个是我们认为的合理的解法。

那么下一盘我们来讲一下后门这个领域。这我是去引用了一个典型的DV流程，它里面的每一个环节都是有一些呃，已知的供应链的攻击，那比如说典型的如果说这样一个D，它有一些上游依赖，那么上游依赖本身可能会被啊table就是就是说它以一个具有具有障连法的包名字去行碰瓷，那么这种都是我们已经非常熟知的碰应链的威胁，呃，类似这样的威胁在每个环节都有，当然我们这儿就不再去展开举例子了，但是这儿我们重点要去讲说后门，在这个整个软件功应的流程当中，如果说它有很大的威胁的话，那么它这种威胁肯定是来自于我们最意想不到的环节，那比如说除了前面五个这种我们所熟知的抵御up流程，还有一些比如说呃，我们的web server，它的运营监控是有一些开源的工具的。

可以对于机器的健康度以及这个存活度进行分析，那么这些软件是否是可能会被渗透，以及测试、发布、管控、配管和更新服务，这些是不是都能够被人利用起来去发起一次攻击？这些可能相对于前面这些都没有一些更成熟或者说更具有传播面的案例出来。那么对于这个环节，实际上是我们最应该去破除掉我们的信赖关系，去以攻击者视角做一下分析，那么接下来我们去讲一个例子，恰好就是针对于我们所谓的一个最被最多人所信赖的一个环节去发起的攻击的一个实验。

那么这里面我们举的这个例子，就是说我们在这两年会陆陆续续看到了一些攻击的事件，比如说他会对一些发行版的基础软件维护仓库去做了渗透，或者比如说之前啊这个勒索软件组织，它对于这个微软它某些开源代码的存储，比如说这个编译机去做渗透啊，类似这样一些这仓库的凭证泄露事件实际上已经是屡见不鲜了，但是我们去看到公开披露出来信息，认为这些事件对于代码的完整性是没有造成任何的影响的。呃，官方或者说专家认为这样的实践实际上只不过是黑客，他们对于人这个源码尝试从里面去便利，发现一些敏感信息进行利用，但是这个威胁确实止步于此了，我们要打一个问号。

那么这里面我们做了一个实验，就是尝试来分析一下，说它的可性和性到底如何，我们都知道，实际上是大家现在的开发实验当中所基本都在使用的一个。代码托管，并且它基本上也是现在D当中的一个核心流程，比如说现在一个GI的概念，就是说认为get是一切这个开发实践的核心，那么我们这儿就去看说get的一个。可靠性实际上是围绕着它的两个特性展开，一个就是它的链式，因为我们知道它的这个代码历史是每一步都有自己的一个焦点，哈希，那么后一个电路是基于前一个电路的状态了，如果前一个电路发生了改变，那么后一个这个科也将部分动态消微推翻。

那么另外一个就是仓库的去中心化。它的分布。如果我在一个仓库做大量修改，我不可能是说另外一个开发者，他本地的仓库存储不做修改的状态下，也能够完全完美的进行合并，那我们这个实验实际上就是想去破除这两个课号性，其中之一也是这个链式。就是说我们在实际的开发运维当中，可能会有一些仓库，不经意之间，呃，一次提交仓库里面写入一个。啊敏感数据，比如说啊密码口令，我们后续想再把这个项目开源的时候，把这样一些啊敏感的数据从历史当中进行消除，那么实际上就是需要对提交历史做一个全流程的修改，那么它的作用在我们这实际上就引用来对于一个项目，比如说是一个fo的项目。

在他某一次历史提交的状态下，我们把他的提交的这个commit代码进行修改，并且把这样一个修改在后续的提交历史当中都进行保留，所以就涉及到对于这个后续历史代码的完整重写。我们这里选择的是一个juu BA项目，并且选择它一个相对比较简单一点的高危漏洞。和2016年的一个十个亿，那么这个漏洞我们之之所以选择它是因为足够简单。它的漏洞修复代码是这样的，它是把一个set的操作前在的构成一个换成出的函数，根据条件呃在其中一个分支里面使用八去替换。实际上当官的是做了一些额外的，呃，这种交易操作。

那么我们所期望达到的效果就是说把这样一个pat在它的commit master分支里面去行回滚，来保证在最新的code base里边，后面的所有代码状态，代码提交状态都不变，这一个历史代码提交里面，它的提交被改写了，我们使用这个BF工具，我们可以看到它去进行分析之后，可以去发现它从某一个历史状态下往后面所有的这个可都需要进行改写，呃，使用这个工具进行修改，并且把修改强制推广推到远端分支之后，我们可以去看到它最终实现的效果是这样的，就是说我们fo出来的一个项目和官方的这个fo上游的项目去行比较，我们没有做任何的commit的新增，然后历史所有的commit，它的提交的时间戳以及提交的作者都完全不变，而且可想而知他每一次提交的这些增量代码，就说这个代码地也是完全不变的。所以在。

这样的一个状态下，如果我们是一个啊不理的开发者，我们去看到这个项目，实际上它是很难感知到它的区别，因为这里区别实际上只存在于啊我们所改写的这些commit比特的一个哈斯值的变化。那么我们来最终看一下，通过对于历一个历史的commit的代码排写，最终实现这样一个历史漏洞的回滚，它把这样一个安全的函数调用改成了一个之前不安全的代码调用，那么这样就实现一个历史漏洞在完全不去新增可以的状态下，在一个呃get项目当中的敲约生气的植入。那么刚刚才所提到这样一个实验，实际上它是有自己的制约性的啊，比如说这样一个，呃，提到之后，它虽然破除了我们刚才所说的get的这种链式，但是他还无法破除掉这个分布式存储，就是其中心化，我在一个仓库进行了修改，并且把它铺到远端，那么远端和这个项目的其他的用户的本地存储实际上是有冲突的，那其他用户再去进行呃代码的泛和push的时候，是会发现这样的冲突，所以所以会对会对这样的攻击有所感知，但是实际上这样一种所谓的有条件篡改，在某一些开发实践和现在特别流行的一些开发实践当中，是能够抹除掉这样一个小小的不足。

同时它也可以被移植到一些其他的攻击场景里面，那比如说我们现在看像redpad他所发布出来的这样一些，呃，它维护的开源软件的版本都是以对的形式去发布，而大多都是以S包的形式，那么它里面是维护了一个当前软件的最原始code状态，以及后续的累积的pat文件，那么如果我们在对这些PA文件进行篡改的话，它实际上是可以达到我们刚才所谓的这个中箱commit的修改的一个状态。

只要它不影响到后续排的一个补丁打上去的效果就可以。而回归到这个问题上，我们想现在大家都在提云原生啊，有一个云原生概念叫做云原生的云端开发，它围绕的是一个web IDE的这种基础设施外BIDE，它的最基本原理就是说我们各个开发者不需要自己去整这样一套本地开发环境，不需要本地去搭建这个开发环境的依赖包，只需要把代码从云端拖到一个临时搭好的比如说刀粕环境里面，然后在这个环境里边都已经具备了相应的一些依赖，开发好push，销毁这样一个本地的docker就可以了。那么在这里面实际上它是完全抹掉了GI固有的一个分布式存储，或者说去中心化的一个机制，那么这个时候因为没有任何的本地存储，所以也就完全可以悄无声息的去把这样一个篡改同步。

到所有的开发者那里，与此类似的业务，像比如说get enterprise club，它是一种协作的一个方案，那它实际上也是实现了一个类似的呃，把去中心化这个优势抹掉的一个，呃一种现在可以叫云延生机制，另外我们再次延伸考虑一下，比如说呃CN系统，如果它是可以被渗透的话。那么他是不是可以实现这样一种中间攻击，就比如说他对于官方的代码去进行了远端分支的篡改，但是它对这种篡改可以透明化的，不去向终端用户进行透传，那么它实际上比如说把它修改过后的哈希进行有意识的啊隐藏，那么实际上也是可以躲避掉用户的感知，另外更主要的是我们去考虑一下现在啊，因为各种各样的大家都知道原因，可能不是所有的开发者都能够很方便的去访问到这套这样的一个开源形象。

呃，同时也有一些开源项目的话，他们从一开始没有直接托管到GA上面，他们是有各种自己的托管服务，或者说内部托管，那么他们同时也会在GI上去维护一个mirror，那么这种mirror，包括说我们可能现在已经有厂商在对GI的一些啊典型的开源项目做镜像，那么这些镜像本身。呃，可能大家看到的是，它声称这一天和官方去进行次同步，但这种同步它的哈希是发生变化，我想可能很少有人会去注意过，那么如果没有注意过的话，他是不是真的已经有一些相关的污染啊，对这个问题可能我们啊觉得是一个可以讨论的问题。那么我们再做一个形式上的总结，就是说针对于后门这一块，我们刚才举了一个典型的例子，当然这个例子可能并不代表我们现在已经有的在野的攻击，但是从本质上来讲，它足以去说明我们这想去阐述的合作问题，比如说，呃，这个后门对于整个供应链的威胁，它最主要体现也是一个信任问题。

所以为了解决这样一个信任问题，我们需要去做这样一个层次的能力建设。当然这个也只是一个guideline，它并不是非常具有可操作性的一个具体的方法，但是我们认为它是一个足够具有呃指导性的一个意见。比如说我们需要去审视一些信任，那么这一块的话，我们很多无条件信任，比如说在201415年出现新浪低解之前，大家对由于open这样一个项目的信任一样，我们需要破除这样的一个信念来以攻击者视角进行分析来看，比如说这个项目它的开发者投入产比是不是足以支撑这个项目的安全性，然后如果我们作为攻击者的话，是可以造成是可以做怎么样的一个攻击，以及对于整个软件供链，或者啊这个D或者C流程当中的任意环，我们攻击是可以做怎么样的。

另外就是从防守方的角度来讲，我们呃，肯定是要去做一些可控可信的平台，比如说CC的流程，我们来保证这样的流程和审计和可感知，同时更主要的我们还要去打造核心能力，一方面包括后面检测的技术，那么我们之前的这样一些，比如说静态分析和这个动态分析都是各有侧动的，比如说静态分析个偏向于各语言开发的项目的，呃，这个通用活动，它不去检测这样一个后门。而正察发菌这样的技术，它也是更倾向于去发现bug一样的东西，那么针对于我们所能够想到的后门的植物和后门的呃意图，我们是不是可以结合原有的一些技术来去做一些额外的迁移和知识库的建立，来把这样的一个后门检测技术搭建起来，更重要的是，可能我们也没有办法去期望这样的技术能够很平滑很友好的接入到我们现在所谓的DV流程里面，因为这样的测试不可避免的肯定是一个长期甚至于有点像碰运气一样的过程，所以它本身应该是打造成了一种持续测试的机制，那这样一种持续测试机制。

肯定也更依赖于开源协作建设，比如说这个软件供电，或者说开源生态里面如果存在豪门的话，它实际上是一个生态的问题，这两个问题我们期望的是用生态的方法进行解决。那么这个就是类似于我们一开始提到的，像谷歌他去搭建了oss这样的一个公开平台，那我们是不是也可以去建立这样一种对于生态里面，特别是二次开发项目的安全性和后门检测的一个公开平台，来把所有的开源项目由生态的各个参与方进行接入，来做这样的一个能力的分享以及信息共享。那么最后我们来讲一下我们对于现在所谓的看人生态或者说自由软件世界的现状的了解和方案的展望。

呃，自由软件这一块，我们认为可能现状是不是令人很愉悦的，它体现为一个自由软件世界的右转，比如说我们之前看到的新闻guitar，它作为呃。各个国家都认为它是一个完全无国界的开源项目的基石，但GI在最近的时间当中去排除了特定国家和意识形态的开发者，那么实上我们都意识到这可能是一种倒退，但实际上我们再去考虑作为自由软件的话，它本身。呃，可能更多的我们之前理解都是用爱发电的一个领域，但是可能真的是因为之前没有找到更合理的商业化模式，但是如果它有商业化模式成熟的话，比如说我们前前面所提到的N，那么他们是否是会逐渐走向必然呢？另外我们讲到像前几年华为所经历的这样一个美国的呃出口管制，把它扩展到了K源软件的领域，虽然它当时的这种出口管制做的还是比较浅层，只是做到了一个加密算法的一个出口管制，那么我们是不是能够保证后续它的这种出口管制不会扩大到更多的，比如说针对特种国家所有开源文件的一概性的排除呢？这些我们都是无法无法保证的。总之开源已经不再是一个处理地，而更值得我们去警醒的是一些，比如说像美国国防部，他们很早就已经开展了一些研究，他去尝试发现巴克特尔的问题。比如说他去查。

看所有的软件里面的代码提交是不是有一些。一些可能比较简单的漏洞形式存在的，实际上是开发者所植入的一个后门。那这样的问题的话，实际上很多国家早就已经开始进行研究，我们现在完全无法保证说这样的一些研究是否已经被用在这个自由软件世界的悄无声息的污染。那么这样一个网络战备公开化的环境下，也许我们所谓的自由软件或者开源软件的信链早就已经被微软渗透过，那么对于这样一个现状，我们是需要做好准备，包括我们作为头部的互联网语音放提供厂商和开源软件的提供商，我们是需要有对应的解决方案，而我们现在知道已经有一些框架他们初具出行，比如说最近的这种，呃，OPS的概念已经非常的成熟，国家都有自己的方案。另外我们讲国内，最近呃，在红外的S决定退出它的官方支持之后，国内的开源操作系统和社区的建设也是如火如荼，但是他也残留了一个问题，就是国家现在的这种开源生态。

基本上都在围绕着Linux内核去进行建设，对于更多的比如说Linux，比如说类似于二七，它配套的这些基础软件的长期生存支持版本，我们现在实际上还都在沿用的red源，我们没有做自己的基础软件的维护，更没有我们自己的基础软件的分析平台，那么这样的平台是所欠缺的。而D我们刚才所提到，那现在做了大量的框架，它实际上对于对于S能力建设还停留在一些成熟技术，我们还期待有更多的面向问题的技术环节的成熟，那么接下来我们就提到说，我们期望能够给行业更多的机会和期待，那么包括我们所有的头部互联网厂商，我们有技术能力储备的厂商，以及整个行业里面的呃，小而精的行业参与者。

我们期望他们能够在这个问题领域贡献更多的啊经验思和产品，那么这也是我们接下来所要求的墨菲安全他们呃在这一方面的一个体现，我们也是期望能够听到更多的这样一些啊崭新的声音。那么我们把接下来的时间交给。安全的。后来老师。啊，大家好，非常感谢云顶实验室的邀请，那么很高兴能够在这里跟大家去分享一下我们对于软件供应链安全的一些观察，以及我们了解到业内的一些解决方案，那简单介绍一下，我来自墨菲安全，那我们的话其实是一家比较新的公司，那我们专注在软件供应链安全这个领域，那么我们期望是能够成为最懂甲方的安全厂商，那么我们能够提供最好用的安全产品，那我个人的话呢，主要是在做相关的技术研究，知识库的建设工作，那么在过往的经历上的话呢，我其实也主要是在做甲方的安全建设。

那接下来我要讲的内容呢，主要会以一个安全厂商的视角去给大家讲讲说为什么我们今天在这里要去谈论呃，软件供应链的安全，那我们到底面临什么样的威胁，那要解决这些问题，我们会面临什么样的挑战，那在从整个业界来看的话，有什么样的解决方案？那首先我们今天为什么要去聊这个话题，其实是因为在呃，整个这个软件软件的软软件整个行业的发展，以及说整个开源生态的发展，那整个开源软件其实已经成了成为了我们整个互联网数字世界的一个基石，那下方的话有一个数据显示是说从一五年到2019年，整个的这个开源站，开源代码的一个使用的占比其实是提升了有一倍的。

那么在右边的话呢，也有一些统计的数据，比如这里面提到说，呃，每一个平均每一个项目可能会引入超过100多个的开源组件，那这里面呢，可能有20%-30%的这些呃组件都是存在漏洞的，然后这通常来讲啊，这一个有漏洞的组件，它不止存在一个漏洞，它可能存在两到三个漏洞，那有63%的这种开源项目呢，你如果直接拿来用，比如说你直接拿来商用，那你是有这个许可证的侵权的风险的。那么在左边的话呢，是一个这个呃软件的从开发，然后到整个使用的整个链条的流程，那么我们可以看到说，在过去的两年时间，其实在各个环节都已经出现了很多各种各样的这些安全的事件。

那从整个国家的。呃，监管的一个层面来看呢，不管是中国还是美国，其实在最近这两年都陆续的出台了一些相关的呃法规标准，那其实我们看到说整体从国家层面对软件供应链安全的这些治理要求，它的监管要求是在变得越来越严格的。从攻击者的黑客的一个视角来看，其实他去攻击一个通用软件，开源软件，它攻击的性价比是非常高的，因为它的这个呃，攻击的杀伤力会非常大，所以大家也看到说在最近半年其实也出现了一些非常严重的一些事件，那这块的话，刚才云顶的同学其实也提的比较多了，我就不再重复去说了。那还有一类的问题呢，其实是关于这个开源许可证的风险，那尤其是一些涉及到海外业务的这些公司需要需要去注意，因为不同的这种开源许可证，它其实涉及到不同的这种权利的约束，比如说对于GPL的这个许可证来说，假如说你的一个商业产品也用用了某一个呃，GPR许可证的项目，然后去做二次开发，那么当你再去发布你的这个商业软件的时候，你也需要提供你的呃相应的源代码，否则的话就是违反了GP的这个约定的，那你就是属于一个侵权的行为。那么在下面呢，我列举了两个比较典型的案子，典型的案件，那么在其中一个呢，是在2019年的时候，数字天堂公司去起诉柚子公司啊，说违反了他们的这个金票开源协议的开源许可证的约定的这么一个侵权的这么一个事情。

那么虽然说最后这个案件，他其实法院判决说呃侵权并不是因为这个纸条的许可证，但是这个其实是国内第一起涉及到说呃把机票协议的一个呃许可证的一个侵权，呃作为一个这个呃作为一个起诉的依据的这么一个案件，那么实际上呢，呃第一起。

在国内去认可GPL的这个许可证的法律效力，是在去年的时候，去年四暂这个漯河公司去告风林公司，说是抄袭了他们的这个开源的代码，然后呢是最后法定，法院呢是认定说这个风林公司是是侵权的，也就是说认可了这个GP许可证它的一个法律的效力，那这个其实是在国内作为一个先例，那在我们相信是说在有了先例之后，其实就意味着是说在之后类似的一些案件，它法院在支持上会更加的更加的容易，更加的明确，这也就意味着其实说对于开源许可证来说，它不再是一个君子协定，你一旦违反了机票以及说其他类似的一些，呃，开源许可证的一些约定的时候，那对于商业公司来说，它是要承担这些经济和生育上的损失的。

那刚才我们提到了说一些典型的风险，那要解决这些风险呢，其实我们面临的三大的核心的挑战，那第一呢是说啊，怎么去识别，说我们有我们用到了什么样的开源组件，那它的复杂性在于是说整整个这个软件，以及说软件引入的场景，其实它是非常复杂的，它有多种多样的形式，有不同的场景，比如说对于这个呃，曝光机制来说，那像Java它可能就是比较集中，大家都在用nova gra去做这种包的管理，那像CC加加这样的语言，它可能比较分散。然后呢，你要识别的对象可能包括说从源码，然后到架包、外包这样的制品，以及说像Windows Windows下的这种可执行文件，甚至是说呃，IOT的这种固件，然后呢，你要识别的环节可能是不一样的，你可能是需要在开发的阶段识别。可能是需要在。

这个线上去识别，这其实就要求说你的识别能力是需要有很强的一个适配的，适应适应场景的一个能力的，那第二个大的问题是说，呃，我们提到的这种各种各样的风险，我们怎么去检测，怎么去预防，那比如说我们提到漏洞，大家肯定会想到说CVE，那CVE是不是足够的呢？它是不是全面呢？那他这里面的数据是不是能够支撑我们判断一个漏洞的影响面，这个漏洞是怎么利用的呢？然后他的这个数据是不是足够结构化，能够去和我们前一步识别到的这些资产信息进行关联呢？这些其实都会有比较多的问题，那第二点呢，是说刚才提到的投毒。

那他投毒本质上是是什么呢？本质上其实是非预期的行为，那预期和非预期你怎么去划定一条很清晰的界限呢？这个其实也是比较难的，那第三点呢，是说关于开源许可证，那它其实是自然语言去描述的一些呃条款，那针对自然语言，其实我们完全通过呃，通过机器去识别它，并不并不能保证说它完全识别正确，那也就导致是说这块其实识别效果还是会有一些差距的。那第三块大的问题呢，其实也是大部分的厂商呃，投入大大量的力量去攻克的问题，希望去解决的问题，就是企业怎么去治理这些风险，怎么去呃解决这些漏洞的问题，那常见的是说，比如说啊，我发现有很多漏漏洞，然后这些漏洞它有是直接意外引入的，也有是间接意外引入的，那我怎么我要怎么去修复呢？然后这些漏洞这么多，我应该修哪个呢？如果我都修的话，我可能几个月我都修不完，我不用干别的了。

那第三呢，是说可能很多的研发同学会说，哎，我虽然在这个依赖配置文件里面，我引用了这个这个组件，但是我现在没有调用啊，我没有调这个有问题的函数，这个方法，然后呢是呃，关于这个最后结果的漏报误报的问题，那这些问题呢，其实都在困扰着整个呃甲方的安全团队，但是这些问题其实它依赖的是说你对这些漏洞组件，这些知识的持续的运营，你对你工具的持续的迭代，那这些其实甲方的安全团队去去去投入显得是性价比比较低的，因为对于他们来说编辑成本会比较高。

那这些的话，其实是整个业界面临的一些挑战，那么说完挑战之后呢，我也会讲一下，呃，整个业界，从整个业界来看，我们大概有什么样的解决的思路，那首先是说在这个开源组件的识别上面，我们接下来会提sca这个概念，软件成本分析，那么我在这里的大概列举了有四个等级，把它标成L1到L4，那那L1级别呢，它可能是相对简单一些的，就是我们看到说很多的高级语言，其实它就比较比较成熟，比较统一的这种包管理器，它有相应的这个依赖配置文件，所以你肯定会想到说我们可以基于这些EI配置文件去做解析，但是这里面其实也有比较明显的坑，比如说像右边这个，呃，Java no中的这个po点叉L的配置文件，那你可以看到说它并没有直接的写明它所有的依赖，而是他用到了很多的高级的特性，比如说在这里面它用到了。

这个继承它它实际上是会继承其他的这个组件的配置，然后呢，它的这个呃，影响的版本，它其实是用了模板的写法，然后它的不同的依赖，其实有不同的作用域，比如说有的是在测试环境才会测试，测试的环节才会引入的，有的呢，才会编译到最终的价包里面，那这些呢，最终其实会影响到你的整个识别的效果。那。第二级别呢，是说，比如说对于CC加加这样的语言，我们可能没有统一的成熟的包管理器，那这时候怎么办呢？那一个做法就是说我们可以去解析它的编译的配置文件，比如说makefil，你可以去识别里面是链接了什么样的动态库，静态库，然后呢还你还可以根据说在整个项目中存在哪些文件，去计算这个文件的哈希，然后和云端的数据进行比对，当然这个前提是说你需要现在云端先构建一个这个组件版本文件到哈希的这么一套的特征库，然后才能走这个特征的比较的一个逻辑。

那第三个级别呢，是说我们可能没有完整的文件了，比如说我们看到呃，有很多的这种呃，BASE64的这种编解码的代码片段，实际上是被大家做了很多的副本的，比如说你可能看到啊，Stepflow或者是get up上啊某个某个人他写的，诶你觉得这个函数非常不错，然后你就把它考到了你的这个项目里面。那像这样的问题我们怎么去识别呢？就大概也是会有两种的思路，第一个呢，是说我们基于N行的代码去做匹配，比如说是八行十行的代码，我们把它作为一个最小的单元，然后我们去比较说这个最小的单元是不是也出现在了某一个开源组件当中，然后另一个呢，是说。

啊，我们可以结合语法分析，我们把我们识别到呃，一个个的函数，我们把函数作为一个最小的单元，然后去看说诶，是不是某一个开源组件当中有这样的函数，那前三种的场景呢，其实都是你能够获取到源码的场景，但是有些情况下你可能会获取不到源码，比如说你的供应商可能会提供给你的是商业软件，那它通常是一个二进制的文件，那在这样的场景下，我们要怎么去做检测呢？那右边这个的话是呃，国外的一个厂商他的一个呃原理的介绍，那么我们可以看到说这里大概他提到了几点，那第一个维度呢，是说去查找相应的特征的字符串，那这里面比如说大家在用课的时候，你你会用客杠V，这时候它会输出说，啊，我觉得是课7.77这个版本，那这时候呢，这个就可以作为一个特征字符串进行匹配，你可以去查找你的。

目标禁止文件中是不是包含有这个这这样的字符串。那第二个维度呢，是说可以看说你的这个呃，二进制文件中是不是包含某一个组件的这些函数，我们去算它的函数符号，它的函数的签名，然后进行判断，那第三个呢，其实比较偏这个传统的这种杀毒厂商，它的做法就是说我从不同的这个二进制的位置，然后去取它相应的这个机器码，然后我把呃这些机器码去算一个特征，然后呢，我把这个特征和我云端的进行。比对这个传统的杀毒软件通常都是这么做的，但这样有一个很大的问题在于是说它它是不能跨平台的，因为你比如说叉八六和M的指令集，它其实是不一样的，就是导致是说你的这个特征码其实它是对不上的啊对。然后呢，第四层呢，是说我们可以去识别这个二进制文件，它的一个呃功能的逻辑，它这个它这个文件，它具体他是干了什么样的事情，这个我们看到说腾讯安全的同学其实也有一些，呃之之前已经有一些研究了，是基于这个生成控制流图，然后加于加上这个图升级网络去计算两个二进制文件之间的一个相似度的，对这这些的话，是一些关于sca的一些做法的思路。

那sca它的结果是什么呢？它的结果其实就是我们经常会听到有人提到的这个SW，那SW呢，有常见的三种的格式，那这三种格式其实都是能够满足最小的基本的一个这个呃，物料清单的这个资产的一个描述的需求的，在这里我们就不做过多的展开。那刚才我们提到说关于这个SWM，它是资产的一个结构化的表达，那关于漏洞呢？关于漏洞其实我们现在在使用的这个CVE格式，它是4.0的版本，那4.0的版本是在2019年开始启用的，呃预计在接下来的两个月会切换到5.0的版本，那这里面很重要的一个区别是说，呃在4.0的版本，我们可以看到这个是呃4.0中的填写的截图，然后下面是5.0，那在4.0当中呢，它其实已经有一个影响信息的这么一个字段，但是在4.0中它是可选的，所以导致很多漏洞其实并没有这块的信息，那在5.0中呢，它其实是一个必填项，并且呢，它增加了很多的呃这种相关的一些字段，比如说这个，呃，软件包的下载地址，然后它是哪个模块哪个文件，那这样的信息呢，我们认为是说预计在接下来的一段时间，如果启用了五点。

零之后，其实能够很大程度上的去降低STEM的一个关联的成本，那这个漏洞和资产组件之间的这些匹配就会变得相对简单一些。

然后呢，关于漏洞，我们经常会考虑的一个问题是说，诶，我们怎么能够保证说能够获得更全面的这些漏洞的信息，那下面这个呢，大概是一个比较理想的一个模型，那首先呢，是说我们看到左边我们需要有足够多的这些数据的输入，那它会包括说像CVECD这样的官方的漏洞库，以及包括说像getar这样的第三方的漏洞库，同时呢，你可能还需要有所有的开源项目的这种代码库的变更，呃，官方发了哪些公告，然后有谁在讨论这些关于漏洞的事情，这些博客推上的一些舆情，以及呢，我们希望是说能够有社区的一些白帽子能够来去主动的去贡献一些漏洞的数据，那这是数据源上，那在有了数据之后呢，我们第一步是要去做数据的清洗，这里面主要是清洗掉一些脏的无效的数据，那在有了这些相对相对有效的数据之后呢，会由机器。

学习的模型进行识别，识别说，诶这篇文章是不是在讨论漏洞的事情，那如果是一个漏洞的话，那它是高危还是低微，然后呢，会由策略系统去根据我们过往的一些经验去判断说。去做一些信息的抽取，那在得到一个比较有效，比较完善的信息之后呢，由安全专家的这么一个呃团队去对数据进行校验校准，并且去对规则进行迭代，那同时呢，也保证是说整个输入到漏洞的知识库里面，每一条的这种数据它都是没有误报的，那就是关于说漏洞怎么去呃更全面的去发现。那漏洞怎么能够更早的发现呢？我们可以看说啊，一个漏洞它大概会经历这么几个关键的节点，那原点呢，其实是这个漏洞被发现。

的的其的点，然后呢，接下来会呃，这个漏洞发送者通常会向这个开发者或者是其他的组织去提出这个问题，然后开发者呢，会去提交他的修复代码，然后去发布新的版本，发发这个安全公告，在之后呢，到这个CVE的公开，那么我会发现是说你越往后的环节，大家其实关注度会越高，但是它之间间隔的时间也会越短，所以如果你想要说更早的去发现。这些漏洞，那也就意味着是说你需要更关注前面的流程，那基于这样的一些理念呢，我们在，呃，过去的一段时间，我们去时间，我们也发也提前发现了很多没有公开的漏洞啊，比如说在三暂的时候，Spring方的漏洞。那还有一个问题呢，是说大家很多都会关注，说哎，为什么有这么多的零的，我们到什么时候才能够去发现完，那我们看到说有两个项目，它是比较有特点的，第一个项目呢，是这个，呃，也是一家初创公司在运营的这个home的平台，那它的一个特点是说他收取get get上所有开源项目的漏洞，那不管你是提交漏洞还是开发者去修复漏洞，他都会支付相应的赏金，并且去给你申请CVE。

然后第二个项目呢，是open s sf基金会，那他是linus基金会下面的一个专注在开源安全领域的基金会，那么在今年年初的时候，由谷歌和微软呃一同去启动的这个阿尔法欧米伽项目，那在这个项目里面呢，它分成了两部分，第一部分是阿尔法部分，阿尔法部分它其实要解决的是说他们圈定出来了一批认为是整个业界最重要的这些开源软件，大概是100到200个，那针对这些他怎么去提升它的安全性呢？他们其实主要是和这个开发者去建立很强的联系，并且投入大量的人力去做代码审计，去帮助这些呃开源软件去修复这些问题，然后还有很多项目其实是属于这个腰部的。

这些呢，大概会有一万多个，嗯，那这些风险呢，要怎么去解决呢？在欧米伽这部分里面，他们强调的是说我通过自动化的工具，比如说自动的安全分析工具，以及这些其他的一些评价的机制，能够去给这些呃项目的开发者提供一些风险，以及说这个修复的建议。那就是关于零的一些发现。然后第二块的话，我们讲到说投毒，那投毒的预防里面很重要的一个项目其实是six store，那sixto它是什么呢？它其实是通过这种自动化的签名和校验的机制，它去保障这个供应链的完整性，然后它是希望能够做到说这个软件供应链里面的这个零信任的机制。

那同样啊，也是在这个open s s CF的这个基金会下面有一个最近启动的工作组，叫做软件仓库加固，那在这个工作组里面很重要的一件事情是他们在推动Python Java Ruby这样的语言，他的这个曝光礼器都去使用这个six去做签名，然后下游的这些开发者呢，在使用制品的时候就可以去做相应的校验，那虽然整个这个six store其实现在还没有到一个呃，非常稳定的正式版本。但是我们可以来看一下它的一个大概的流程。那这这个是six store的一个流程，我们可以看到在左边的话是这个呃，软件的开发者，那软件的开发者呢，他可以去呃申请对他的这个组件，它的这个软件制品进行签名，那他在申请签名的时候，会首先通过这个三方去进行身份的认证，那在拿到认证之后，中间这个呃叫做for sal的这个组件的这个模块会颁发一个短期有效的证书，那他们认为呢，短期有效的证书可以避免这种长效证书被盗导致的风险，然后这个证书颁发的这个信息啊，它会同步到右边的这个这个模块。

然后呢，开发者呢，拿着这个证书会对制品进行签名，并且对这个制品进行发布，并且这个签名的信息他也会同步到瑞克，好，这时候呢，在右边的这个终端用户，也就是下游的这些制品的使用者，他就可以拿着这个制品去向这个去验证这个签名的有效性，同时这里面呢，还有一个这个monitor monitor它呢是做了是说它可以通过它的这个日志审计他的这个，通过他的审计日志去审计他的这些证书是不是正确有效的去颁发了，那么这是大概的six store的一个签名校验的流程。

那我们还看到是说针对这个投毒事件的响应，其实在最近的这一段时间，不管是像NPM这样的中央仓库，还是像一些私有的制品库，其实他们都开始去支持这种下载的阻断功能，那下载的阻断呢，其实能够比较及时的去呃防止说呃对于企业来说，对于开发者来说，他的一个这个呃损失的扩大。那接下来我们聊一下关于许可证，许可证的话，刚才我们提到是说，其实它是各种的自然语言描述的这种条款，那我们就会看到是说，那既然是自然语言，那可能就会大家写的有五花八门的，他可能写成各种各样，并且他可能会出现在各种各样的地方，那比如说出现在这个单独的license文件中的，然后有这个写在代码的注释里面的，有写在这个依赖配置文件里面的，比如说右上方的这个，呃，我们可以看到说它的这个license的这个。

名称他写的是阿帕奇，但是他的这个幺却给的是M，这样的话，你你你其实也没法分别说，那他到底是哪一个许可证呢？但是好的事情是说，呃，SPDX在持续的推进这个许可证的标准化，那他们呢，其实现在已经定义了400多个常见的许可证，比如说这个许可证的全称，然后它的短的标识符，然后它的这个长文本短文本的描述，并且我们看到说已经有一些开源的项目已经在使用这种，呃，他们推荐的这种短的标识符，会把它写在代码的注释里面，这样的话能够很大程度上去提升这个机器识别的效果。

那第三部分呢，就是对于企业来说，要怎么去做这些风险的治理，要怎么去解决这些问题，那要解决问题，其实大家，呃，经常可能会面临的一个问题是说，呃，可能有人会问你说，哎，你这个东西到底怎么去评价，怎么评价你做的好坏，你如果打分的话，你是做到了几分，然后你怎么去对标，那谷歌提出的这个算法框架呢，其实是在做类似这样的事情。那他们首先呢，是从软件的开发，然后到制品的这个使用的环节，各个环节整个链条上，他们做了威胁建模，然后做了相应的这种呃评价的标准，然后打出了相应的这个呃一级到四级的这样的一个分数，那这里面比如说你的这个代码需要至少有两个人的，那你才能够够得着这个四级的这个标准。

那就是他们的一个评价的机制，然后是说，呃，关于说。我们怎么去评价一个开源组件的安全性，我们怎么去选择说我到底应该用哪个安全，哪个开源组件，那谷歌也提出了这个安全积分卡的这个模型，那它其实是也是有一系列的这种，呃，可以量化，可以去衡量，可以观测的这些客观的指标，然后去决定说你这个组件它是八分还是十分的一个安全性。那我们看到说还有一家瑞典的公司，那他们也是呃在做类似的一些事情，那他们是呃应该是爬了上2800多万个开源项目的这些数据，然后呢，他从以下的这几个维度，就是贡献，贡献者的一个能力，流行度，然后它的安全性去给企业去提供说呃作为一个组件选型的一个参考。

然后是说关于这个修漏洞的问题，漏洞要不要修，漏洞怎么去修，那大家肯定会想到是说啊有这么多的漏洞，那我如果呃，像刚才提到的是说如果全都要修，有的用户可能说他他几百个，他几百个漏洞，几百上千个漏洞，他怎么他也修不完，他也不想修，那可能就是这个放弃治疗了，那怎么去决定说我到底要不要修呢？那其实。大家很自然会想到是说，呃，首先需要根据这个漏洞的危害，比如说这个漏洞是能够执行系统命令，还是说它只能够弹个窗，那他的这个优先级肯定是不一样的，然后还有是说，那这个漏洞到底是不是真的对我有影响的，如果我只是引入了这个意外，但是并没有使用到它，我可能没有真实的调用，那是不是不受影响，然后这个漏，这个漏洞到底，呃，现在是能不能利用，呃外面有没有一些攻击的工具，然后它的利用成本到底是什么样的，高不高，然后有什么样的利用条件等等的这些因素呢，其实会决定了这个我们去做漏洞处置的优先级，那这些数据其实就依赖说你必须要有一个资料非常丰富，相对来说比较完备的漏洞知识库作为支撑，然后我们才能去做更好的决策。

那漏洞怎么修，我们认为核心其实是要和整个研发的工具链去做集成，去降低研发同学的一个修复的成本，那比如说在组件引入的环节，那NPM的audit其实就在做这样的事情啊，你在下载有风险的这个组件的时候，它会做相应的提示，然后呢是在这个开发的环节，在开发的环节如果我们能够识别出来，那这时候修改的成本是会更低的。那跟代码库的结合呢，我们能够实现这种增量全量代码的这些快速的检测，那跟这个构建部署环节的一些结合呢，能够去阻阻止我们有问题的这些项目，有问题的这些组件发布到线上的环境。

那所以基于这样的一些理念，一些想法，我们去做了一些实践，我们做了一款开源的工具，那大家在get up上搜motor security或者是motorsc都能够找到我们，那在右边的话呢，是我们的一个使用界面的一个截图，可以看到我们的整个工具其实是呃比较简，使用起来是比较简单的，那这个呢，它包括一个检测的客户端，那这个客户端其实它就做的是呃两件事情，一个是说解析你的这些直接依赖，间接依赖，然后呢，并且把这些呃这些依赖的信息提交给服务端，然后呢，我们在服务端我们有一个控制台呢，可以看到说整个检测的这些结果。

那同时呢，我们还开源了一个这个IDE的插件，那在比如说的这些插件市场，可以搜索下载到我们这个插件，那插件它的一个好处呢，是说他能帮助开发者在开发过程中更早的去发现问题，解决问题啊，比如说我们会有像呃一键修复这样的功能，能够更低成本的去呃在早期早期去解决问题。那它的一个实现机制大概是什么样的？我们这个呃，不管是客户端还是这个ID的插件，实际上它识别出来的都是这个呃意外的信息，也就是像组件名，然后版本这些相对来说和自己的代码没有那么多关系的这种依赖的信息，然后只有这些意赖的信息会提交到服务端，那在我们的服务端呢，会和我们的漏洞的知识库进行联动，然后分析得到一个呃检测的结果。

那这是大概的一个交互的逻辑释义。那这时候可能会有同学问说，那你作为一家商业公司，为什么要去做开源这样的事情，那我们这个开源产品的所有的是说我们希望帮助每一个开发者都能够更安全的去使用开源代码，那对于我们来说，嗯，做开源的一些好处啊。第一呢，是说。刚才提到其实很重要的一点是说这样的检测工具，它需要和非常多的这种工具链进行集成，那么它其实呃这样的这样的事情呢，我们希望是说我们可以和社区一块来共同去建设，它能够社区的一些力量也能够帮助我们去做快速的迭代，那每天现在其实也都会有很多的这些开发者的用户在使用我们的产品，在使用我们的这个开源的工具，那也都会给我们提很多的这些问题，给我们提一些有用的建议。

那第二呢是说呃，在开源之后，其实会有更多的人，更多的开发者会关注到我们的这个工具，关注到我们的产品，那会有更多的用户去使用它，那对于我们来说，其实我们就能够获得一个更大的影响力，那第三呢，其实对于开源，对于我们来说，开源其实也是在增加我们的这个透明度，那其实对于用户，对于客户来说，也会对我们更加有这个呃好感，更加有这个呃信任度。所以总结一下，呃，我们今天聊了谈了这些关于软件供应链安全，那整体来说呢，呃，整个现状其实是处在一个风险比较高，然后不管是从这个攻击者的角度，还是从这个呃国家监管的程度呃层面，其实他的关注度都比较高，那一个这个好的解决方案呢，它其实是需要完善的工具链的支持，以加上丰富的像组件啊，漏洞啊这样的知识数据才能够实现的。那么我我们看到说，不管是组件还是漏洞，其他都在走向标准化，在未来可能这样的事情，它的他的他会做的非常标准化，但是呢，现实到未来其实还有很长的一段距离是需要走的，那我们在接下来的一段时间，可能类似的一些风险的事件还会继续发生。

那最后呢，其实是像其他安全领域一样，在软件供应链安全这个领域，其实也没有任何的一个解决方案能够解决所有的问题，那在当前我们仍然需要做大量的非常细致的琐碎的工作，才能取得一个比较好的效果。

那我今天的分享主要是这些，谢谢大家。嗯，感谢欧阳老师，然后我们在呃分享直播的过程中，也看到有一些朋友在提了一些问题，呃我们现在想请杨文老师来做一下解答，然后在这中间如果其他的同学也还有问题的话，也欢迎在我们的评论区留言。呃第一个问题是有一位网友问呃供应链呃安全问题是好像是最近两年才密集出现的，从solo事件开始，呃最近两年密集的会有一些呃现象级的事件爆发，他想问为什么外部发生了什么新的变量会导致这种呃供应链攻击的事件不断的升级，然后他没有指定哪位老师来回答，所以我想请两位老师都来分享一下自己的看法。嗯，我这边先提一下我的一个想法，当然可能不是非常直接明确的回答，因为我们刚才讲到在一八年的时候，还没有这样一个应链安全的出来，然后我们当时是了一个期个的攻防挑战战黑客思路，那么它是不是恶化了这样的一个攻方的形式，那么这一块其实我们是想，呃，这样一个所谓的攻击思的提出，他并不是说启发了这样一些人，他只不过是把这样一个威胁的形式更多的。

摆到台面上来，让大家都意识到这样一个问题的，呃，成因和它的严重性，呃，刚才我们也都提到说这个威胁，呃实际上最大的威胁不是来源于那些我们已经看到的，然后影响面非常大的问题，比如说我们之前看到这个noe。

他实际上在出来之后，马上就被开源社区的人发现、上报并且回告。但是更重要的是那些我们完全看不到，感知不到的问题，那比如说是不是会有一些开源领域被某一些势力所操控的，那么他们是不是已经有一些恶意的代码，非常隐蔽的，隐藏的，那么我们实际上想通过这样的一个攻防的研究来启发出来人们对这些事件的分析，所以这其实不算是一个非常直接的回答，但是我给出的一个观点是，呃，我们同时在做的背对背的攻击和防御两个方面分别的研究和建设，实际上应该肯定不是这个问题领域最近爆发的原因，这是我的观点。嗯，其实我我也谈一下我的理解，就在刚才的话，其实就我在一开始也提到，就是说呃，大的背景是呃，比如说有有机构统计是说从一五年到一九年，整个开源代码的一个使用的占比是翻了一倍，也就是说到今天其实你一个项目里面有大概80%的代码，并不是你写的啊，是这些呃开源软件的代码，所以对于这个攻击者来说，他去找这些开源开源代码的漏洞，它的这个性价比也是更高的，因为它一一打能打一大片，对，然后你其实我们越来越多的这个代码都是在写一些业务逻辑，对，然后但所以我们会看到说现在很多的问题，很多的严重的问题，其实是由这80%的这些开源代码导致的。

嗯，好的，感谢两位老师，刚刚王老师在他的回复里面提到了note IPC供应链投毒的事件，刚好有一位网友也想问，呃，怎么看待这个俄乌战争背景下这种类型的供应链投毒攻击，以及我们对这类问题有没有合适的解决方案？呃，我注意到欧阳老师在他的分享中有比较大的篇幅是专门讲投毒的，所以这个问题我想请欧阳老师来解答一下。

好的好的就是嗯从从这个现象来看呢，其实嗯对于企业来说，对于企业来说其实要解决说实话在现在还是比较难的，但是我们有期望解决的，我认为这个有期望解决的其实是在这个，呃从从这个整个生态来看，就是six这个项目，也说我刚才提到的是说，比如说我们去推进了像像NPM这种，呃报管理器，那如果他都做了这样的签名校验，那相对来说投毒的这个成本就会高很多，也没有那么多人去敢投毒了，因为他可能投毒一次，然后他就会被钉在这个耻辱柱上了啊。

嗯，好的老师对这个问题有补充看法吗？嗯，简单提一下补充，就是因为我之前也曾经有一段时间去做这个云主机上面的恶意代码恶样本的检测，呃，BC这型链毒是种恶，那么它的实现实际上是有非常明显的意图，虽然这种意图它是通过贝斯罗四编码的形式进行隐藏，但是他做编码这个行为本身是符合这种恶意代码的啊，典型特征的，所以对于这样一些特征，实际上是我们可以去做一些建设啊，那这样一些特征我们也可以去做这样一些相应的专家知识库的建设，在我们的比如静态扫描当中去有意志的发现内容明显易于这个项目本身代码风格的东西，但是更多的是我们可能对于这样一些没有这种显著的有意识的隐藏行为的会议代码的提交，那么这些的话，我们希望后续能够有一些。

呃，包括我们现在也正在建设的就是这样一些尝试，对代码意图进行推断，比如说它是否与这个代码相相关的文有明显的一个呃，低耦合度，那么它的实现的目的是不是符合特征的一个行为特征，那么这些是我们想正在长时期解决的。好的，感谢。呃，有一位网友问，呃，在解决软件供应链安全威胁问题里，有哪些值得学习的优秀案例和方案，然后这个刚刚应该是有哪一位老师专门分享过，这个是是否能再提炼一下？刚刚是欧阳老师做过系统的盘点嘛。对，我这边大概呃有提过，但是可能我我这里没有系统的去讲。

嗯，实际上我我认为啊，我我我谈一下我的理解，就是我们现在看到的很多的这些方案，其实是由谷歌提出的，比如说像to，然像这个sofa这样A的这样的框架，然后包括说这个安全积分卡。那其实我我认为是说，如果我们要去做业界的对标的话，那其实可以重点看一下谷歌它是怎么做的，那它其实它很核心的一个做法是说。他是希望说在整个软件供应链上能够做相应的这种零信任的机制，那他其实就会说他要强化在每一个环节的签名校验，他希望说各个环节是不可信的，呃，他有等等的一些呃自动化的工具，然后有一些呃框架，有一些模型去做相应的支持。

大概是这样。嗯，好的，呃，另外有个网友软件应链安全面临的主要挑战有哪些？这个想请那个王老师来解答一下。呃，这一块其实我们刚才在开讲的过程当中已经谈到很多洋洋洒洒的，包括我们欧阳老师这边，其实已经对于我们现在所熟知的已知的各种微信形式都覆盖到了，那么这一块其实我们还是想提，呃，就是两点需要再重复一下，一个就认为最主要的威胁，或者说最具威胁性的这样一些攻击，都是来自于我们所没有关注到的环节，呃，所以不能够说我们做什么样的安全的建设就已经足够对这样的攻击有和非常，比如说一定程度可度量的防御性能。呃，从另外一个角度来讲，我们从机器方面来考虑，虽然有这样各种各样的问题，但是我们当已经有一种攻击形式出现的时候，它肯定会有大量的跟风者去做相应的仿制，比如说在2015年的时候，我们当时。

团队是做了一个啊。Pthon的PPI的包投毒，就是说他的那种靠名字去进行碰瓷的这样一个呃尝试，并且这个基本上是在业界的第一个尝试，而且也成功的收集到了一堆手机，当然在之后我们对这样的案例去做了公开，而在这个事件之后，我们看到大量的比如说Python的包，以及其他各种的SDK的SDK的包，以及包括我们现在看到这个容器镜像都大量的存在这种碰瓷式的呃，一个投毒污染，那么对于这样的一个问题，实际上是一个呃。

类型成功移植，但是他在不同领域有不同表现形式的案量案件，那么有这样的意识在的话，我们作为安全团队去介入到我们的呃开发运维实践当中，就可以有意识的把它作为一种需要考虑的短板进行考虑，直接去对于这种已经和。可以考虑到一些可收敛的问题，做对应的能力建设，等于就是说我们要对可收敛的问题保证可收敛，那么这个是我的看法。好的，感谢王老师，有一位朋友呃特地提到了AI写代码的一些问题，他也连续有几个问题，分别是怎么看AI自动写代码，以及AI写代码是不是能减少呃代码漏斗或者投毒事件的发生，以及我们是不是能在AI写代码上做一些事情去规范，制定一些规范，减少类似事情的发生。

这个两位老师谁可能比较了解一些？嗯，这个我们可能社备上是有非常多的话语权，因为可能确实经验不足，但是我们作为安全的从业者的话，之前也都是接触过一些类似的概念，如时应是所出概念去尝漏洞，或说根据一些洞模，如果发的话，自动从开源生态里去找到能够修复这个漏洞的代码片段。把它进行相应的一个加工和缝合，写到这样一个项目里面，但是这样一个概念提出当时具有很强的爆炸性，最终却不了了之，因为它在这个特定领域里面实际上是有些问题的，有很多呃，技术上的挑战，毕竟比如说修复漏洞这个事情，它是需要结合语义漏洞，语杂么修复，那么写码多的形态是以一种比如说类似于这种自动驾驶，那么自动驾驶技术本身的发展到现在可能没有办法保证十全十美，所以它仍然是一种和自动辅助驾驶的形式去。

呈现，那么现在我们看到一些啊，辅助写代码的方案，也以一种就是说插件会进行智能的提示这样的方法去实现啊，所以认我认为可能在这方面面临的已知的威胁倒不够大，但是可能针对AI这个领域的话，我们在安全研究领域也都知道会面临一些业务的问题，比如说对于这种AI模型本身的投渡，它都是一些呃有过很深入研究的事件，那比如说模型本身可以让他去产生一定的倾斜，然后让他对他去做有意识的误导，那么这一块的话，可能也是后面我们也要在下来之后去进行讨论，比如说他现在的发展是不是已经呃足够快，那么安全是不是要跟上，那么这一块也是感谢咱们网友提出的这个观点。

嗯，好的，就是如果有呃本期大没有解决完的问题，大家可以扫描二维码加入我们的群，然后后续做进一步沟通。嗯，下面一个问题是问墨菲安全的欧阳老师，呃，这位网友想知道咱们墨菲安全是不是已经有一些商业客户的案例，以及尤其是在金融领域有没有案例？呃，它还有第二个问题就是，呃，我们的产品会在客户端提供提取源代码吗？怎么保障数据的保密性？

嗯嗯。第一个问题，关于这个商业客户案例的话，呃是有的，但是我认为可能这个场合不太适合去去交流这个事情，然后这个我觉得可以私下去交流，然后呢，第二个问题是关于这个产品的这个保密性，是不是会涉及到说我我我拿走你的代码这个事情。这个事情的话呢，首先呃，我我会讲两部分的逻辑啊，一个是说我们这个开源工具，开源工具呢，它其实你可以看到我们的这个源码是公开的，你可以去看这个源码没有关系，然后那它的逻辑其实说是说它只提取了这些依赖的信息，并不会把你的这个呃代码去上传，然后呢，那在我们的商业化的版本里面，其实它的逻辑也是类似的，就客户用户的代码，其实它也都不会传到我们的这个服务端，对。

然后我们传的其实只有这些相对来说和和客户的这些自己写的这种代码没有那么多联系的这种依赖信息。嗯，好的，感谢欧阳老师的解答，然后那我们来到最后一个问题吧，这个应该也是所有人呃都很关心的一个问题，就是作为甲方企业要怎么样去构建自身的供应链安全能力，大概要解决哪些关键环节的问题，嗯，这个详情两位老师都发表一下看法，就是对于企业有哪一些安全方面的建议。嗯，这个我那我那我先谈一下我的理解，就是这个问题其实其实问的还是还是挺大的，就是这个可能不是说，呃，它是一个非常简单的方案，然后呢，那核心来说，我认为可能要解决，解决的其实就是。

就是我在我在材料里面提到的这个三大挑战的问题，就是第一呢是说啊，你得你得知道说你用到了哪些供应链，那你整个企业里面，你你这么多的项目，你都用到了什么样的这些供应链，然后你你的这个资产情况是什么样，用到了哪些的这种开源组件，开源软件，第二呢，是说你的这些资产里面，它有什么样的这个风险，比如说哪些有漏洞的，然后呢，哪些可能是存在一些被投毒的风险的，然后你的用到的这些，呃，项目里面它用到的这个开源许可证是什么样的，这个其实就像是说你去这个，呃就就跟看病有点像，就是你你去你去化验，然后去问诊，去治疗的这么个过程，然后第三步呢，才是说好，你你在知道了你有什么样的问题之后，你去决策，说那我核心要解决。

解决什么样的问题，然后呢，再考虑是说那我通过什么样的机制去去解决，比如说那我可能需要推一些，呃。推推一些这种相应的安全能力的建设等等的一些事情，那它核心其实是我提到的这三点，我认为。好的老师，有有补充的看法吗？嗯，这块的话，我可能因为我们本身其实就是互联网厂商，我们自己作为甲方，我们提下我们作为甲方的安全团队在这里面起到作用，我们认为甲方的安全它主要是三个角色，一个就是我们去做安全管控和安全治理的这种安全部问同学，那么他们肯定是要负责说我们最终的所有安全机制，包括我们刚才讲到我们行业的这些公司，他们所提供这些解决方案。去收敛我们特定可收敛问题的时候，怎么去落地到我们的呃，整个开发实践里面，这是一方面，再一方面是这种安全攻防或者是蓝军团队，那么他们可能就是需要有意识把我们所提到这种软件供应链的具体威胁和供应形式落实到我们真实的这种日常演练里面，再有就是我们作为一个安全研究或者说前沿研究团队，我们有责任去更多的去披露各种信分攻击形式，然后去发现我们所谓比如说企业的实践，或者说整个生态里面最薄弱的短板环节，然后我们去一方面做这样的一个呃热点的分析，另外一方面我们也需要更多的把精力放在防守方能力的建设，防御能力的建设，那比如说我们现在的这些能力，比如说包括S是否足解决我们所披露出来这些问题，不足的话，他需要做什么样定，那么能就有。

要去做技术的预言和这种原型方案的孵化，当然更进一步的我们讲说作为啊甲方来讲，我们是能够充分去做这样的一些建设，但是也还是回到我们一开始演讲的最后一个问题，说这个东西本质上是一个生态的问题，依赖于我们自己意见的话，肯定是有自己的一个啊知识的限制，再一方面其实它也是我们只是单打独斗，不利于整个生态去完成解决这个问题，所以我们可能把一些我们自己的实践，最终也是希望能够反哺到整个生态里面来，保证说这个问题的根本解决，这个是我这边的一个看法，谢谢。

嗯，好的好的，感谢两位老师的分享，今天也学到了很多东西，给我们带来了很多新鲜的一些观点和新鲜的呃，信息量，那么我们今天的直播内容到这里就结束了，然后稍后我们导播会把带有二维码的画面在直播间停留几分钟，然后大家如果想要进交流的话，可以加我们的群来进一步探讨，然后今天就感谢大家的时间了。

哦，我们直播到这里结束了。