也希望我的分享能够对大家今天下午停了这么长的时间能有一些收获和价值但是其实我讨论这个话题会有一点点在这个业内其实比较尴尬因为安全一直是一个较好 但不较做 大家都觉得很重要但可能很多团队还不够重视的一个话题 一个基础方向然后我现在所在的公司WeRound Azure其实也是在做这种软件供应链安全的产品但是是在给我们的容器服务去做这个软件供应链安全但是我做的这个东西正好也是开源项目所以并不是一个商业的产品 所以任何用户都可以去用但我今天这个分享倒不是说要推荐大家去用我们开源的这个项目主要还是想跟大家探讨一些在安全领域一些有意思的话题其实我这两天在逛这个麦麦的时候也看到一个比较有意思的说法是一个新闻就是在国内某互联网巨头公司他们整个安全部门被干掉了然后下面就有人评论说说这个安全团队在公司没有安全漏洞事故发生的时候觉得安全团队没什么用然后发生了安全漏洞事故发生了这种风险的泄漏对吧 又觉得安全团队还是没什么用安全团队可能在这个公司内它的定位可能就确实在国内特别是比较尴尬但其实据我在微软跟国外的一些客户跟国外的一些合作伙伴打交道过程中其实发现国外的这些对安全国外的特别是大的金融保险公司对安全的重视是非常非常高的而且美国现在也是有这种头号的行政命令网络安全法去要求在这个软件供应链安全有对应的措施然后我等会还会邀请我的另一位同事然后他是container地社区的matern在KNN社区有非常丰富的贡献和研发的经验他会去分享一下最近在container地社区比较热议的在这种wrong time 维度的这些新的供应链安全的方案OK 然后我的目录呢主要是包括四个话题前面会去讨论一下现在软件供应链安全的一些案例和挑战然后再会去分享一下在CNCF这个生态里面有哪些比较有价值的开源原生供应链的一些产品和开源的方案以及现在业内的标准的框架然后第三个我会去快速demo一下我们现在在做的一个开源项目第四个就是会有我的同事副委给大家去分享一下现在container地在正在去推进和落实的一个新的方案首先第一个就是我可以简单去介绍一下软件供应链的安全 它的一个理念因为国内这个东西还是比较新我在国内听到这个软件供应链安全提这个东西的人大部分还是一些安全机构的一些专业安全机构的人以及这个新同院啊这些标准组织其实从中端用户这边提到这个供应链安全其实非常少所以简单科普一下这个软件供应链安全本质上来讲跟我们的传统的制造行业我们传统的这个生产行业的这种物理的供应链安全物理的这种供应链没有太大的区别还是从这个原材料的生产加工到运输然后再到这个销售这种消费对吧然后在这个软件里御呢大家知道可能前期这个物料的这个软件代码你不可能从零去写第一行代码那在写一个软件的时候我们可能要去用到各种各样的第三方的依赖需要在这个原代码构建的时候引入一些第三方的开源项目我们都希望去站在巨人的肩膀上去缩好一个产品那在用到第三方依赖的时候可能会遇到一些这个第三方组建的这些开源项目的漏洞这个是不可预见的比如说前两年很热门的这个LOCAL FORGE的这个事件对吧然后再到构建传书和分发部署其实都跟我们传统的这个工艺链是非常非常相似的所以其实从本质上来讲它跟我们这种日常生活中的工艺链是没有太大区别的那我们可以看几个例子我大家可能知道就是在这个原码的构建它叫做这个组建的构建以及这个网络传书其实在每一个环节在我们这个软件生命周期的每一个环节都可能会引入一些这种第三方的这个依赖然后这个依赖呢可能会带来一些漏洞或者是一些CVE那这些问题发生在各个环节其实在业内也有各种各样的这个这种安全风险的新闻爆出来并且一爆出来都是这种核弹级别的影响对整个行业都会有影响比如说在最近的这个4月份OpenAI它就有一次这个安全漏洞的事件造成整个OpenAI的这个CHBT的Service换换了大概六七个小时其实它影响面还是非常大的然后它根本的原因是因为OpenAI它底层依赖的一个Redis Python的一个一个Library 一个库里面是有一个安全漏洞然后呢引发它用CHBT的用户A用户可以看到B用户的这个聊天记录这个缓存里面存在一些泄漏的问题所以当时OpenAI就紧急修复了这个Redis Python的安全漏洞然后打了一个Patch升级到了最新的版本然后把这个问题给修复掉了但是它面临的问题就是它的这个服务当机了七个多小时所以这个安全漏洞它平时没有事的时候大家都不会去关注它但它一旦出了事情其实对整个业务对整个行业的影响是非常非常严重的这是一个来自新思科技在2022年和2023年的一个报告其实可以看到最显眼的两个数据就是84%的这个扫描的样本代码库中至少会包含一个漏洞那48%接近一半的这个样本库可能会包含高威的软件的漏洞然后其实刚我提到在美国已经有这种行政命令在21年美国白宫它是颁布了这个行政命令要求这些企业在生产在开发和发行你的这个软件的时候去卖你的软件的时候你是必须要戴上对应的这些软件供应链安全的一些证明来证明你的软件是安全的比如说像SBOM软件物料清单或者是数字签名然后我接下来会去快速介绍一下在CNCF这个生态已经有的那些比较知名的和一些比较好用的开源项目也是我在最近这一年多去调研到的一些好用的项目首先先讲两个框架两个框架是我在业内去做这个供应链安全发现两个比较在业内比较广为流行和采纳的一个两个框架首先第一个我先讲右边的这个SELSA它是在2021年Google率先推出来的一个供应链安全的一个级别评估的一套标准然后它现在其实在华为在国内的一些大的公司包括在国外很多这些大的开源项目其实都在用这个SELSA来评估自己的这个软件供应链安全它其实是从软件的生产然后打包编译最后到这个消费它都有一套很完整的等级去评估你的这个软件是属于哪一个等级然后左边是微软在去年开源和贡献给OpenSSF开源安全软件基金会的一套框架然后它里面也有非常详细的这些标准的这个实践来供大家去评估自己的软件供应链包括用户在消费这不是安全但我这个分享不会着重去过这两个框架因为里面内容非常多如果说你在帮自己的企业去定义你的安全模型和风险模型的时候可以去看一看这两个框架然后这个是在SELSA的这个landscape里面它有一个专门的板块叫安全与合规那在这个板块呢它立了很多开源项目对吧其实我们就用重点关注一下它第一排目前相对来说比较成熟的这些项目比如说它在这个已经毕业的和服务化的这几个项目像这个OPA这个策略引擎它一般可以用来去作为这种开放的策略去定义你的软件哪些软件可以被部署哪些软件不能被部署然后可以去定义一些合规的策略然后像这个Kevano其实跟OPA是有点竞争的关系它也是一种开放的策略引擎然后呢Felcone它注重在这个Round Time运行时的这种安全然后最右边那个Notary它最早是Dorker公司开源的然后现在是我们微软和AWS在一起去迭代的这个容器数字进向签名的一个开源项目也是我们今天稍后会去重点介绍的一个开源项目然后其他的这些厂商和开源项目也非常多其实可以说明这个领域现在其实在国外在这个全球其实关注度还是比较高的百花齐放然后这个我是整理了一个清单是把一些目前业内比较流行的特别是在美国那边在海外市场是比较说欢迎的一些开源项目把它整理到了一起包括进向签名容器进向的分发和制品的管理然后软件物料清单的生辰还有这个软件来源变更还有这个漏洞扫描还包括刚刚提到这个策略代理的开源项目以及KBS集群验证引擎以及运行事安全每个领域都会有对应的开源项目但它也会意味着你要花很多时间去研究这些开源项目因为它相对来说方案比较多然后其实心血比较散那其实我今天重点会介绍就是在确保软件供应链安全或者说在KBS上去确保容器供应链安全有一个很重要的点就是你要确保你生产的软件没有被其他人没有被黑客篡改过这是一个去确保你的软件分发一致性的一个很重要的技术就是数字签名技术然后数字签名技术它其实会依赖一些像这种数字签名的工具其实也会依赖到这种数字签名的证书那除了数字签名其实还有一些方案可以去确保你软件分发的一致性和软件分发的安全比如说这个软件物料清单它可以显示你的软件有哪些构成的组成成分还有比如说你的这个软件的扫描比如说像这个Trivi是比较知名的做漏洞扫描的这种工具其实国内有很多SCA的厂商去做这种漏洞依赖扫描的这些产品然后准入签名的控制也是我们等会儿会去demo的一个方向会去告诉大家去定义一些有效的这些准入策略来帮助你在KBS上决定哪些软件 哪些容器经向可以被部署哪些不能被部署它最终的目的就是说能够帮助企业去避免这些风险软件被部署到我们的KBS集群我们的生产环境里面然后这个是一个简单的一个图这个图其实就是显示了我们在工业链安全的软件分发生产然后再到最终的部署它的一个流程但其实它里面最终的四要素就是一般在这个分发你的经向的时候会有四个东西会去依附到你的容器经向上面第一个就是这个漏洞扫描的报告然后第二个呢是我们的经向签名第三个就是软件物料清单证明你的这个软件有哪些原材料组成有哪些依赖组成第四个就是你的软件来源变更的证明你的软件是由谁生产的然后是由谁发行的这些信息也都是需要被在这个经向的部署和分发当中是需要去提供给用户的然后其实在刚刚有杨艾玲老师他提到这个OCSback其实在这个OCSback最近也有一些新的进展有一个叫Reference API的东西现在在OCS最新的版本里面有出现然后这个Reference API呢它的一个出现就让现在的这些容器经向仓库比如说像Harbor像阿里云的这个Content Registry还有一些各个厂商的容器经向仓库它就变得不再是只为存储容器经向而服务了它可以存储非容器经向比如说像Harm Chart像WebAssembly的这个Module然后还比如说像一些供应链安全的这些这些文件像这个容器经向签名啊还有S-Bone啊其实他们可能是一些Jason文件它不是标准的这个OCI的经向然后还比如说像这个你的漏洞扫描的报告它可能就是一个这个就是文本文件PXT文件但是它都可以随着你在让用户去拉取让用户去消费的时候一并地在容器当中去看到你的这些这些供应链安全的制品并且你不需要把这些内容打包到你的容器的容器经向的文件系统里面其实你通过这样的一个这种塑图的结构可以很清楚地看到他们之间的这个依赖关系也可以看到每一个这个经向下面挂了哪些供应链安全的制品然后其实我观察到现在有很多开源项目特别是CNCF生态有很多开源项目已经在实施这一套方案了它会要求你在去安装这个开源项目的时候会去让用户去验证这些东西比如说让用户去验证SBOM让用户去验证你是这个漏洞安全的扫描报告去验证这个Signature这个经向签名来确保这个开源Metainer发布的这个项目确实是来自于这个社区生产的然后它没有被第三方的这些黑客或者是一些第三方的这些这些攻击者植入一些不健康的或者是一些攻击的代码像这个Argo CDFlex CD还有Helm, Continuity还有殖民的Kubernetes都会有这样的要求然后Notary现在这个项目是刚刚提到是Viran和AWS两个名厂商在一起带来开源项目然后之前Dorker也有很长时间在参与然后这个是我们项目的一个官网它也是在CNCFIncubating的一个开源项目如果大家感兴趣的话可以去这个官网上看一看对应的实验互动环境互动教程以及我们的视频教程然后我们也提供了一个Notation的CLI的工具它能够提供像这个证书的生成签名密奥的生成以及签名和验证的一些基础功能它有一个非常好用的这个CLI的工具可以在命令行里面去用我稍后也会demo如果有时间的话然后讲了这么多理论我觉得大家可能觉得还是听得非常的干巴巴的我觉得还是需要去demo一下我特别喜欢去用一些比较酷炫的或者说比较有用户长期的一些demo能够去证明能够去向大家去展示这个项目的一些价值然后回到用户的场景去解决一些用户实际的问题那我接下来演示的这个场景会去从这种在KBS进项部署之前然后从最开始开发者去生产去打包一个进项去编一个进项到最终部署这样的一个端道端的流程我们要去做这种供应链安全的保障要有哪些流程然后假设在最左上角假设我们在某科技银行有一个研发工程师他叫小李他负责去生长他们公司的进项但是他们公司的老板说他们必须要给他们所有的进项要加上一些供应链安全的这些文件确保他们的进项让他们用户去部署的时候没有被人篡改所以在原有的技术上他们是需要通过一些工具一些手段去深沉这些供应链安全的文件比如说这个S-Bone比如说这个数字签名还比如说刚刚提到这个漏洞扫描的文件你要确保你的东西是真实的有效的 是安全的那你的用户才可以去验证和部署发行的进项在KBIOS上都是以这种进项的方式去部署多了一部的步骤相比以前多了的步骤就是说现在必须要去通过这些东西加到这个容器进项上那我们其实有个工具叫ORUS也是我们团队贡献给CNCF的一个项目它其实就能够把把这些非进项的制品给它依附到容器的进项上面然后在容器进项商库里面也可以很容易的被发现和下载那最终它这些进项的这些供应链安全的制品打包好以后最终推送到容器进项商库比如说Huber比如说JFCR 多个HUB那用户在部署的时候它去拉这个进项它就可以一并地把那些供应链安全的文件给拉下来包括这个进项一起然后谈到这个在部署的环节部署的环节比如说另外一家公司是某科技银行的客户那这家公司它可能是一个保险公司那保险公司他们的DevOps公司是需要把他们这个金融科技银行这个小礼生产的这个软件这个进项要把它布到他们的生产环境然后最终变成一个App让他们的这个保险公司的员工去用那它就要去验证这个进项是不是真实的是不是安全的是不是没有被人篡改过对吧那它这个DevOps公司它去验证的时候它就要去看这些上传到这个进项上面的这些S-Bone这些落洞扫描这些进项上的这些信息是不是真实的那也就意味着它需要去做一个验证的步骤去验证它的这个合规性那验证这个东西谁来做呢就由这个Rudify我们团队在开源的另外一个项目Rudify这个验证框架来去跟OPA Policy这个开放策略引擎做一个结合它可以去定义一些策略来让这个组织允许某些东西某些进项可以被部署某些进项不能被部署比如说你签名过的进项可以被部署你有这个GPL的这些GPL的这些软件license的进项不可以不可以被部署包括这些依赖也不可以被部署那你这个落洞扫描这个落洞报告率在80%以下的这些软件不能被部署那都可以通过这个OPA Policy结合这个Rudify这两个东西在最终的部署环节做一个这个所谓员吧来帮助集群做一个检测这是这个端端端的流程那我接下来会有一个简单的demo去演示一下看能不能播放一下OK我这里在播放可能字体比较小我这里是假设我要去对我已经上传到容器进项仓库的一个进项做一个签名我这里有一个nanomolite的一个仓库然后我呢已经把一个进项上传上去了它的这个tag是V我现在要对这个进项做一个签名把我的这个数字签名的这个文件给它依附上去那我们就要用到刚刚提到那个notation这个小工具CIG给它做一个签名首先我们用notation的这个list的名令看到这个进项上是没有任何的签名对吧然后呢我们用notation sign这个名令去对它进行一个签名签名完以后理论上应该是会有一个signature的文件一个进项签名的文件给附加到这个进项上面并且能够被查询出来我们现在已经签名我现在先生成一个用于签名用的一个测试的这种x509的key和cert一个证书然后我在签名的时候可以去指定对应的这个进项的地址就是刚刚我们这个GSCR上的一个进项签名完成以后它应该会提示我们成功签名然后我们可以看到它返回的这个地址就是我们刚刚签名完的这个进项那我们去再用这个notation list的命令去看一看这个上面是不是有对应的签名生成这个签名的信息上面其实可以看到对应的信息是谁签名了这个进项然后谁做了哪些修改然后这个进项这个证书的发行方式谁这就好比你去看这个网站的https的证书跟证书一样对ok 这个签名的弹幕很简单然后我接下来会去验证一下这个验证呢就是在作为这个devops工生师或者作为这个用户端它去消费你的这个进项的时候它要去拉你的这个进项那它要去保这个进项的拉取是拉了一个一个真实的没有被人篡改过的一个进项那它去拉取的时候它可能用到这个dorker或者是用这个cubicato的run命令去做拉取和部署对吧那我们还是针对刚刚我们已经做了签名的那个进项来做一个验证首先我们去验证就是这个notation list命令可以验证出来我们刚刚确实是已经把一个这个signature结尾的一个文件给它依附到那个CHCR上的那个进项了那我们通过这个notationinspect命令可以去看到这个进项签名上这个对应的证书的信息看到是谁发行了这个这个signature然后看到它对应的这些share value的值去确保去对比你生产方的这个share value的值跟你消费方这个进项是同一个进项没有被人篡改那接下来如果我们确认确实是没有被人篡改我们可以去部署这个进项了对吧我们起了一个miniCube的k8s集群然后在这个miniCube上我们已经提前部署好了刚刚提到的那个radify的验证框架然后我们直接去部署对应的这个policy对应的这个策略准入策略控制然后部署完以后我们再去部署刚刚已经签名过的那个进项从chrcr这个github的进项部署的时候你会发现它确实是可以被创建出来的那我们可以用一个反例去看一看如果说一个进项没有被签名我们设置一个策略它没有被签名的进项不可以被部署那可以看到我们去run另外一个进项它是不能被去成功部署的它应该是被这个验证失败被拒绝掉了可以看到另外的一个进项然后我们还可以去验证就是去部署一个进项它的这个签名的时候用到这个证书和key是已经过期了的用到这个keysigningkey是已经过期了的那我们也可以从这个验证的时候去做一个过滤做一个这种拒绝的一个申请让它最终不要被部署到k8s上然后我这边的一个介绍就到这里着重去介绍了数字签名在确保软件软件供应链安全特别是在容器这个分发着这个方向上去做这种一致性真实性和有效性的一个保障其实数字签名只是其中的一种方式它不能完全的确保你的软件进向是安全的它可能还需要去结合像sBone像骆动扫描和这个软件进向的来源像provenance attestation我不知道这个中文名叫什么其实有这样一套的一个流程去限制确保你的进向的安全那其实除了在这种kubernetes在部署的时候它通过这种webhook的方式这种automation webhook的方式去验证你的安全和做这种部署的限制和准入控制的时候这种webhook是一种方案那其实还有一种方案是下沉到节点层面甚至是到这个节点的round time层面去做一些限制那这个可能就更加的安全并且性能会更加友好更加优化所以我们会邀请到continuity社区的maternal副委来给大家去详细介绍一下现在continuity在容去节点层面的一些安全的方案的研究大家再坚持一会吧这样就是刚刚提到的一些开门产品就是说像那个notary还有opah它其实都基于APS server的admission webhook来做了其实它从集群入口的角度来看的话其实它其实是比较合理的因为你port在创建的时候我需要检验它的进向是否是ok的但是现在遇到两个场景它可能会不太适用第一种就是说当你的集群规模非常大的时候你会有很多创建port的需求如果说你的webhook的实力比较少因为它像那种进向签名它其实需要比较多的需要比较多的cpu的资源所以说你需要回护一个高可用的一个版本将会给集群管理者它带来比较多的负担然后第二点就是说当你的kby集群想要提供一个多住户的一个服务的话比如说你不同住户的port能跑来同一个节点上那么就是它的网络平面是不会通的因为你的webhook是作为一个你的vendor方你的数据平面想要访问住户的机场仓库可能你需要private link这样的产品才能把两个网络平面给联通起来所以说基于这两个场景就是说我们会考虑把这个教育流程下放到下放到节点上来这样的话会有一个好处当你的port创建出来之后掉入器会把它分发到不同的节点上这样它本身就做了一个复杂均衡第二点就是你在节点上就要下进项了所以它天然就可以使用节点的网络访问访问它的那个它的那个特性来访问注入它自己的机场仓库所以说基于这两点我们就由data.dog的同事他就在可能许多社区提供了一个方案就是说他希望在下进项的时候能有一个类似于Admission WebHook这样的一个能力我们先看看下进项的时候我们会做什么事首先当你拿到一个当你拿到一个进项名字的时候我去下他的时候我需要去解析他就我也确认他的进项名是OK的我要把它解析成一个唯一的哈细子因为你的进项名如果说是用那种进项名加tag的形式的话它可以用户可以仿佛去推它这样的话就是它的哈细子是不断的变化了所以我第一步要把这个进项名给解析成一个唯一的哈细子然后再下来它然后再解析到我的那个文人系统里面去然后现在它的方案就是说我希望在解析完之后能有一个检测点这个检测点它的它的交运方式跟微博户其实它是比较像只不过它是用那种二进制的拉起二进制的形式来做就它跟那个CNI有点像就CNI是用来就是初始化破了的网络资源所以说当肯尼蒂解析完这个进项的时候可以说拿到它的哈细子之后它就可以把的进项名以及哈细子传给这些插件然后这插件可以去访问进行仓库甚至去说根据那个软件物料清单来访问它是否使用了一些一些高威的依赖对 但是现在可以看到就是说它其实针对于这个进项教育的开发者来了就是它其实不是面对于我终当用户了所以说也想趁这个机会跟大家说一下说如何做一个进项教育的工具下面我会demo一个场景就是说因为现在GO支持的是1.19跟1.20所以说我想做一个效果就是说所有使用低于GO 1.19的进项我都会把它给回血掉那么做这么一个事情其实需要定义好一个件事就是说你的物料清单是长什么样的然后你的物料清单你存在哪因为我对于插件而言它只知道进项名而已那我怎么通过这进项名跟它的哈基斯能找到我相应的物料清单那么对首先我的物料清单就非常简单就是它的清单就是我的这个进项使用什么样的什么样的Go版本那么我存在哪呢就刚刚其实朋友也他也提到了就是说现在OCI在去年发布了一个新的API就是OCI Reference它可以很轻易地把针对现有的进项添加上一些额外的描述信息比如说这个NATNAT Monitor这个进项它有签名的信息它有它的物料清单的信息然后物料清单它自己的一些签名的信息其实你可以通过这个API可以针对现有的进项来为它添加上一些额外的信息而在这个演示里面我做了非常简单就是我的类型就是KCD-2023然后它的内容就是一个一个Go的版本而已那相应我们看一下对 帮我点这个应该不是对 方大列吧对 首先我针对EDCD 3.4.213.4.24把它的Go版本就给下来现在可以看到它是1.17然后我用AURUSAttach上去Attach非常非常直白就像他说他把这个额外信息贴上去了AURUS对你可以看到其实通过Attach的命令它可以把我刚刚的Go版本的信息添加到这个3.4.24上去然后我现在再check它是不是添加上了对 用AURUS那个对 你可以看到就是这个进行箱下面有一个附属的信息然后它附属的信息的那个寻找地址在这然后我用AURUS POO可以把它再下来对 可以看到就是它它实际上就是它实际上就是我刚传的那个字对然后有了这些物料清单之后像是说你可以根据这个进行名在这个进行仓库里面找到它的相应的描述之后我们就可以定义它的那个消费端了对 接下来对 然后这个就是今天的主体了吧就是可能在这边只要你的二进制你就用share你就用share实现还是你用pattern实现了基本都OK你能接收这两个参数就好了一个是进行名一个是进行的哈一个进行的哈期值然后我这个程序就是用share来写了它做的这件事情就是说拿到这个进行名之后我用AURUS Discovery来看说你是否携带了我的描述信息如果你没有携带的话那说明你可能不是不是用go写了所以我会放行如果你你携带了这个信息之后我会去把它给下下来然后用那个支付算匹配如果你是购一零一九或购一零二零的那我就会说我prove如果你不是那我会告诉你说你应该去升级然后有了这个程序之后你只要放到一个指定的位置可能地它会它会能识别然后我们看下那个我们看下效果吧然后这个效果这样子我会起两个pod然后这两个pod都是EDCD然后第一个就是它用的是它第一个版本就是3.4.24它用的是go 1.17然后3.5.9它用的是go 1.19理论上来说3.4.24这个应该会应该会失败的对 我们可以看到它已经下来挂了我们来看一下就我们来用对 用ebench来看一下对 可以看到就是它会告诉你说ok 你的镜像你的镜像版本比好就是你使用的go版本比好低然后就是说你得去升级了对 所以说就是说其实它做的事情跟微博互合做的一样只不过是跟大家稍微展示一下如果说你想自己开发自己所要的那种镜像教育的教育的功能的话可以按照这种方式做然后现在这个方案其实已经在在上个月的Kennedy的会议上其实已经其实已经只不过是现在它的code还在旅游中我相信很快就会和平的主线上应该会在年底发布Kennedy 2.0然后因为Kennedy它只是唯一的CI的实现所以说我们也会考虑推到像CIO或者是像什么CIO就CI都可加的一个项目上对如果感兴趣的同学的话可以去看看下面这个链接对 下面这个链接然后我的我的我的分享这么多好 谢谢大家感谢两位讲师的这个精彩分享大家有什么问题吗有两个问题想问一下卓老师就是S-Boom清单的这一块是否会完全去信任工艺商提供的S-Boom会不会自己去用这个软件成本分析S-C去做一次二次确认可以自己去做二次确认而且现在其实也有很多这种开源的这些S-A的工具因为你如果完全相信工艺商给你提供的这个S-Boom其实也就意味着你其实把你的这个信任的边界你的信任这个模型是放在第三方的这些厂商的是我是比较建议说你自己在做一次二次验证特别是在部署之前去验证你的这个S-Boom是不是跟你预期的是一样的对吧而且你也可以自己再去申请一个S-Boom现在其实有很多这种S-Boom的申请工具比如说像那个SIFTDorker的那个S-Boom是基于SIFT做的然后微软也有一个开源的叫Microsoft S-Boom然后第二个问题是您提了漏洞扫描报告对吧对但是漏扫的这个问题其实是存在威胁发现之后的情况还有就是因为这个测试手法的问题能保持它这个问题实际并没有发现但是就是说可能我们产品交付了一段时间以后这个暴露面才出现就是从供应链的这个角度上有没有什么比较好的方法尽可能地面这种情况或者说当问题出现了以后我们去真的去应急的时候供应链这边有没有什么好的方案去解决这个问题对 我觉得这是一个蛮好的问题我觉得现在业内可能也都在面临这个痛点就是这种主动式的防御 对吧因为很多问题都是在报出来以后然后大家去寻找方案其实这种补救措施还包括一些主动式的防御我觉得可能是大家在寻找的一个方向吧我这边目前还没有看到一些很好的方案说能够在漏洞在被扫描之前就能够就是在影响具体的这个软件的生产环境之前就能够极早的被发现然后被拒绝在名外我觉得现在其实好像还没有那种非常非常智能的这种方案但大家只能说通过这些扫描通过这个依赖分析的报告去尽可能确保你的这个漏洞是比如说你的高位漏洞是在百分之多少比例以下它能够允许被部署的我们现在看到的方案更多是在这个准入策略控制这一款做一些Policy这些策略的影形的一些教验然后确保这些软件就是在被部署之前能够被尽早的被发现然后以这种主动式的防御的一个一种思路吧去应对这种安全的风险特别是这种依赖引起的这些漏洞我会一起去探讨一下谢谢董老师大家还有什么问题吗我想请问一下就是关于镜像的漏洞扫描这一块其实扫描漏洞的话其实我们有很多的工具开源的包括哈伯尔自带的一些漏扫的工具但是我们往往会发现就是扫描漏洞的数量会非常庞大可能会几千成千上万个这种但是其中扫描漏洞可能百分之七十八十都没有Policy或是都没有再也利用的这种情况所以说所有的漏洞都去推修的话可能修复的成本又会比较高那么我们该就是在推修这方面该怎么去取舍该怎么去筛选那些必要去推修的漏洞据我了解现在国内有很多大的公司他们其实是有专门的这种研究团队的然后他们有自己的这种漏洞的数据库然后他们会有一个列表就是说哪些漏洞它的这个等级是在高威还是中级还是这个低风险级所以我觉得可能它这个标准还不一样每个企业会有它自己的一套这种漏洞风险的管理等级然后据我了解最近那个开放原子基金会现在国内在很多场上在搞一个联盟就是这种供应链的漏洞检测分析的一个联盟就是国内一些大厂像华为 腾讯 阿里这些大厂都在参与他们的一些安全研究实验室在想做一个国内这种一个标准的一个共享的一个漏洞的这种库像奇安信也是据我了解可能未来我觉得在国内它可能会有一个统一的这个漏洞等级的数据库能够让大家去做一个参考因为确实你扫出了一大堆一个个去修 对吧再修的合年合月如果说国内未来有一个这种统一的数据库它能够检测到一些安全等级然后安一些等级给出一些那种补救方案修复方案我觉得那可能会比较合适因为这个我觉得还是一个眼睛当中的一个方案但是趋势是这个样子大家还有问题吗资源 你就是可能在第1个可能第2.0这个说是通过那个二进制脚本对所以到时候这个二进制脚本可能就是提供一个标准的功能要求只要满足这些功能要求我可以实现我自己的二进制脚本可能以一行参数的形式写到可能第的写通参数里面然后这样一个形式是这样就是是需要把这个插件放到一个指定的位置上就跟CR一样对这种形式只要能满足比如说我的可能用其他方式验我这样能验就可以对 是的好的 好的好 谢谢大家还有吗我有两个问题想问一下就是如果在打包的时候我去用这个镜像Furam了好几次这个时候如果通过continental记忆去查着我的话是不是很浪费时间我们就是你说是说去查他的语言吗还是什么就是软件清单就是说我基于一个镜像我去Furam了好多次这个时候去匹配当前这个软件清单的时候就会很耗时这个时候如果你去弄这个镜像的时候就需要等待很久对这样的就是说这取决于你你怎么去做的事情因为很多时候现在其实是鼓励你在编译镜像的时候就是只放一个二点子就是说你尽可能少少去少去依赖其他的因为这样的话就是说你依赖其他的依赖其他的镜像其实说你修复起来可能也不太好修确实是说你如果说你说依赖了每个镜像它都有独立的这个描述可能吵起来确实是会比较麻烦但是现在其实现在OCI现在没有一个特别好的标准说我能够知道一个镜像它基于是哪一个哈基子的来源它不知道它只知道说我是从哪个地方下下来了它没法去找这个源其实或者说你这个源可能是存在其他的镜像其他的镜像仓库上它不一定能在这个镜像仓库上能找到所以说如果说想要坐龙江话建议是把所有的这个镜像所依赖的所有的镜像它的一些转间清单全合并成一个然后踢掉上去对 就是如果你运行的时候肯定是全量拉下来的这个时候它的镜像分层的层就很很多你需要一层一层去找它的转间清单对可能你刚刚提到的是这个就是就是说它其实它其实正在下载的时候其实我并不需要去把所有的层全拉下来我可能只需要接到这个镜像铭就好了然后你可以把所有的镜像都跟这个镜像铭做个保护定我就不需要一层一层下了就是一个镜像里面它有很多的层每个层它会有一个镜像铭如果就是说刚才说它如果从我们的好几层如果我的这个漏洞就在最后一层这个时候你去找的时候就对 我明白你说的就是说所以这个方法我建议只能说是把它合并成一个就把你依赖的镜像全合并成一个清单就是这样的话你就不用把它找了你就只要找一个就行了不知道解释清楚没有就说比如说你的你固定出来是A镜像对吧A镜依赖的B镜像那么我在解析过程中我不会再去解析B了那我会把B的清单合并到A上面去我绑到A上面就好了这样的话你就不需要往下走要做一层全量的拉去去下载当前的软件去是吧对这个如果就是说你一个主机上如果它有很多的大镜像这个时候就会造成就是你时间等待会很久这块是不是有会有优化对 会有就像加速加速是这一程但是我觉得这块的话加速我觉得如果说你的物料清单多化那应该确实需要等一等我觉得也没办法它的它的重细器很多这块如果没有优化的话会后去大镜像的话肯定还是对是现在其实很多很多快速软件包括很多的那些镜像为了避免有CVE其实它镜像为把它这个软件所依赖的包放进去它可能镜像只有一两层不会有那么多层当然就是像什么像现在GPU相关的镜像可能会成绩可能会比较多一些但是但是如果说对于一些在线的服务的话很多时候只是有一两层而已就是现在的推荐的推荐的方式是这样的但是我觉得这真的时间的时候可能很多开发者可能会拿其他的镜像过来编啊编啊可能它的成绩会越来越多但是我其实个人其实不太推荐这样做了因为成绩多化其实管理起来也比较麻烦我看到这个可能在那之前它是做了旧的之后的操作就是说我在旧的之前的时候原代码的操作是没有那是吧供给链就少了一层原代码的剪辑对 这个只是消费短这个只是说我消费短但是我就是说你刚刚说的那种我毕了这段时间就说我CICCICD我需要做的事情那个是说我产生的但这里的话只是说我做一个就可能地现在我不知道有没有理解清楚你的那个问题就是说现在其实构建镜像其实就是一个跑容器它只不过是跑容器过程中把这个容器产生的内容给耽误下来把它变成一个镜像但是可能地其实它也可以做只不过是现在没有去做这个设计就是现在没有做bude之前的检测是直接做了bude之后的检测就是我跑起来之后对 我需要跑的时候我就用了对 就是不能在它发生的时候开始我bude的时候然后直接去检测检测 让它就是不会出现在我bude后再去拦接一次我觉得你这个问题像刚刚第一个同事问的 就是说如果说我bude的时候它没有错比如说它没有问题但是它跑了跑的时候发现它有漏洞了其实现在这个问题确实没有解那我觉得你这个问题反好就是说我觉得可以往像什么Doc B1那边去推说我在我选择我构建的时候我能不能说去判断一下它有没有这样的问题对 就是现在揣尾的还支持文件检测就是FS你可以扫一下它的原码是不是存在这些问题对 是的