SCA在软件供应链安全中的落地实践原创

各位腾讯产业互联网学堂腾讯安全视频号的朋友，大家晚上好，欢迎大家来到腾讯安全的技术公开课啊。今天晚上我们的主题是sca，也就是软件成分分析的应用落地实践。sca不是一个很新鲜的内容，但是因为最近两年高发的一些供应链安全事件而重新受到业内的重视。呃，相信大家都听过一些比较知名的供应链攻击的事件，包括说从2020年年末开始的solar winds，呃到去年的solana q，以及现象级轰动一时的look for Jack，其实最近也有一个spring boos在业内也引起了巨大的反响，我们可以看到供应链攻击事件其实是呈现出一个高频发生的一个状态。呃，去年年底也有一个独立调研机构叫sona type的一个研究机构发布了一项2021年软件供应链的状况报告，这个报告就显示开源软件的供需都在剧烈的增长，那相应的开源的供期也暴涨了650%。

这个数据其实是非常惊人的，那在开源共建日益盛行的今天，开源安全威胁已经成为企业组织无法回避的话题，企业非常紧迫的需要提升它自己在开源软件治理方面的能力，所以在这个背景下，Sca它作为一种跨开发语言的应用程序技术，在当下就有了很大的用武之地。那面对越来越严重的开源安全状况，企业怎么样去进行有效的安全管理？那今天我们就请到了腾讯安全科恩实验室的高级研究员方小亮，呃，就上述话题来做一个分享，小亮将会以sa技术的落地实践为主题，结合我们科恩安全实验室在二进制SSA领域的成果班RYAI的一些实践经验，介绍sa的算法思数据存储与流转服务结构。

从一个开发者的角度阐述企业级的SSC能力是如何构建的，那在小亮分享完之后，我们大概会有一个15分左右的呃，15分钟左右的答疑时间，所以大家在看直播的同时，如果有关于这个的问题想要交流的话，可以随时在我们的产业互联网学堂的评论区，在我们视频号的评论区来留言，我们会在分享结束之后请小亮来解答。呃，大家也可以扫描屏幕右下角的二维码，加入我们的后续的交流群，嗯，今天大家是来听小亮的分享了，那我就不耽误大家时间了，把时间交给小亮，有请。嗯，好的行，谢谢，呃，大家好，我是来自腾讯安全科恩实验室的小亮，然后我今天主要是想分享一下这个SC在软件应链安全当中的落地跟实践，然后内容的话，总体会分成四个大部分，呃，第一部分是简要说一下这个SC的含义跟用途是什么，然后第二部分跟第三部分是本次的重点。

呃，第二部分主要会介绍sa业务的一些嗯特点，它主要是一个强算法加驱动这样一个业务，那第三个部分就是介绍一下科恩内部是如何对这个sa业务落地的，那么它落地当中的一些实践设计和实现是大概是怎样的，然后最后一个部分的话会介绍一下，呃，AI这个平台，主要是科恩会通过这个平台对外输出的这个sca的能力，那首先。故事可能要从第一个这个CV号说起，如果是一个这个这个安全从业者或者说Java开发者的话，可能对这个CV号呃并不陌生，因为呃，Log界这个零的事件，呃发生其实并没有过去多久，相信大家其实还多少还都记得log界其实是在Java的生态当中，非常非常基础的，应用也非常广泛的一个日志的库，比如说像这里提到的像electric search spring，包括像hard这些都会利用呃，Logj进行，呃。

这个日志的，呃，存储啊，日志的输出，然后用去去进行进一步的分析。那呃，前段时间lock建这个零队爆出之后，这些开源组件是呃第一时间可能对这个漏洞进行了更新，但是还有非常多企业内部的也是利用log界，依赖于log界这样的这个业务，那怎么进一步的进行这个分析的，并且能知道呃受到这个log界这个零跌的影响需要更新呢？那么这背后的这样一样一个技术呢，我们就称之作这个SC，那究竟什么是SC呢？这里嗯，大概说一下它的全称，嗯，叫做software composition analysis，其实就是取的前前那个首字母的缩写嘛。然后，呃。它直译过来的话，其实是叫软件成分分析，但是我这里加了个额外的关键词，叫做开源，其实呃，通常意义上的SC分析会针对开源的成分进行分析，当然了，B园的这个项目其实也可以用同样的思路去做，但只是我们更多的会说sa分析，其实针对开源成分的分析，这个其实是会经常被忽略的一点。呃，在做这个演讲之前，其实我找了很多资料，想去尝试查一个sa的官方的或者说比较严谨的定义，但其实各家说的都不太一样，但总体上来说，Lca是包含这么几个关键词的，它是一个。

自动化的过程，它面向的分析的对象是一个软件。然后他想尝试找出这个软件的依赖，特别是这个软件当中有哪些open source software，也就是oss开源的成分是什么。前面这四个关键词大体上是总结了SC的一些定义，但通常意义上后面还会跟上一句话到两句话会说SC可以帮助查找出一些风险。一些安全或者vulnerability，还有有可能是查找出一些license，就是许可证的问题。

Sa的定义一般会包含这些内容，可以看到的是这个后续的风险、安全，这些其实是紧跟着SC前面定义来的，也就是说SCSC分析其实是要配合一些下游的任务，才可以发挥出非常大的价值。那我们来看一下一个SC系统的示意图大概是什么样子的？呃，如果把系统的看作是一个黑盒的话，那么它的输入就是一个文件，或者更宽泛的说，它是一个软件，那么经过这个sa系统它会输出。一个这个依赖的开源软件的组件和版本。比如说前面提到的这个log，那假如这个sa系统输出，Sa系统输入的是一个一个Java里面的架包，那么这个架包的输出当中，它会告诉你，OK，这个架包里可能会包含logg2.15.0这个版本，那根据这个log j，呃，0DAY的影响会判断出它是受到那个影响的，所以它需要通知用户，用户知道这个结果之后说，呃，需要升级这个价报当中的log的依赖。

通过这种方法的话，能够发挥出SC更大的价值，那其中Mo这个是可以列为是CVE识别的这样一个后续的任务，还有其他的，比如说license的识别，这个可能会，呃，涉及到软件的合规性审查，比如说你依赖了一个商业的软件，依赖了一个GPLV2的这样一个版本，一个一个呃，开源的oss，那作为一个商业软件来说，你就有可能会遇到法律的风险。所以说license的识别也是一个后续的任务，除此之外可能还有别的，比如说辅助漏洞挖掘，辅助这个或者是进一步的威胁情报，那么总的来说，其实就是SZ会要配合下游任务来进行进一步的分析。呃，宏观的想讲，刚刚那个sa大概是这个样子，那么我们可以呃感性的体验一下sa具体是什么样子的啊，这里我觉得是B上面的一张这个截图，可以看到是这里有一个文件，就是open CV，呃，Visualation这个文件，它很明显是一个这个application SQ，也就是个elf的文件，那么这个文件它可能依赖的是这些。

开源的组件和版本，比如说它会依赖open CV，那么它的版本是，呃，4.3.0，嗯，比如说它会依赖这个zip的文件，它的版本对应的是V1.2.11，那么这就是一个SC最基础也是最核心的输入和输出。呃，我们这里还要再讲一下关于这个二进制的SC分析和源码的RSC分析，因为二进制的SC分析我们称为叫BSC，就是binary sc，其实会比源码的要更加困难一点，那左边这里列了一个业务场景的图，我这里写的是这个点O文件最后生成点L的，如果说把这个点O换成点C的话，那可能就是一个源码分析的场景。

我们来先来看一下这个二进制的分析场景大概是什么样的。比如说一家企业，他写了一些自己的基础的核心的业务点C文件，然后会编译生成一个点O，那么它有一些供应商呢，也会供应，就是做一些交付物，这个交付物可能是呃一些一堆内部文件，那么最终这些内部文件加上这个靠点，然会链接生成一个最终的可执行文件，那企业需要评估这个可执行文件最终它是不是比如说包含某些高危的CVE，它是不是有法律风险。是不是受到一些投毒的影响，还还有就比如说呃，供应商当中某一些，呃软件的这个加密的库版本太低了，那这样也有可能受到这个攻击，那么它要推动供应商更新的重要组件的这些版本，所以在二进制的情况下。供应商如果不告诉你，那么你最终其实是不知道它里面是有哪些呃，依赖的软件的，所以说。

在这种情况下，我们就需要sa分析，如果把这里的点O文件换成点C文件，其实对应的就是源码级别的sa分析，那如果是点O1堆交付，然后再最后生成这个A点二，那这种情况下就是就是二进制级别的分析，那这两者之间其实难度是差异是比较大的，对于源码分析来说，它有很多可以利用的信息，比如说它有编译系统的构建文件，对应C的话可能就是啊make file或者CIC，那Java的话可能就像gra，像像ma文这些依赖文件会有，除此之外还有一些变量的类型信息，比如说你这个变量是int型、string型，还是个结构体，那还有一些代码的结构，这些源码当中其实都可以有，都可以用来辅助做一些sa分析，但是对应的二进制里面，其实就是没有的。那相反二进制里面遇到的一些困难点。其实源码当中可能也不会遇到，比如说你同样一份点C文件是可以编译成多种可执性的文件格式的，有PE的，有L的，有麦克的，那这个在源码级别上是不会遇到的，那同一种文件格式也会有多架构的，多架构的情况。然后还有一种就是在源码在编译的过程当中，可能会开某些优化选项，那么这优化选项也会对最终的二进制分析造成一定的困扰。

嗯，科恩这边因为对于这个二进制这一块积累比较多，然后呃，也是主要想解决这个进制分析比较难的问题，所以后续的话，主要这些算法和数据都是围绕着这个二进制的分析来持续进行的。呃，在介绍后续的业务逻辑之前，其实要讲一下这个算法本身，那算法其实SC的算法依赖呃的一个核心的点，我们这里取了一个叫做相似性搜索的特性，也可能有别的技术，也可以做sa分析，但这里呃要介绍的是一种叫做函数相似性搜索，什么是函数相似性搜索？简单来说就是给定一个函数，从已有的数据库当中查数跟这个函数最相近的K函数。

这种就是呃，函数相函数相似性搜索的这样一个基本的概念，那具体的话，科恩之前有发过两篇论文，然后具体的一些这个深度学习的算法，核心的逻辑呢，我在这里就不多说了，有有兴趣的同学可以去看这两篇论文的详细内容，那科恩之前公众的话也有对这两篇论文进行过解读，有兴趣的可以去翻看一下，我这里不深入介绍，只是大概会提一下这个函数相似性搜索，具体的就是基本的原理，工作原理大概是什么样的。他大概是比如说用户有一个B进来之后，通过这个反编译等等特征工程吧，拿到这个bary当中的一些函数，这个函数当中可能有很多的特征，很多的信息可以利用，比如说函数里有立记数，有字符串，有符号，那还有常用的就是伪代码，还有就是CFG，就是控制流图，这个也比较常用，那你可以取这其中的一个或者多个特征。

进行后续的分析。然后这里呢，主要是要介绍一种叫做伪代，就是利用伪代码来进行后续分析的这样一种技术，那当拿到这个伪代码之后，会经过这个深度学习的算法，就是比如说NLP啊，GN等等等等，经过这个模型，这个模型的主要目的是把伪代码其实就是个字符串，把这个字符串变成一个叫做inbing的东西，这个是生动学习算法里面一个专有名词，它其实就是一个长度就是N维的向量，就是float类型的数组，可以这么理解。那得到这个向量之后，去查询一个叫做相似性向量的相似性搜索服务的东西。它可以查到跟这个向量最相近的。N个哦，K个。K个函数是什么样的？所以说相似性搜索的基本的逻辑大概是这样，从从binary得到N个函数，然后函数里面选取一些特征，然后再到inbdings，然后再去做相似性的查找，最后再找出个top k的函数，所以说会从一个函数再到top k函数，大概是这么个逻辑。

那基于这个函数相似性搜索SC的算法思路其实就是这个样子的，就是利用这个编译后的B里边的一些函数特征啊，去和源代码当中的一些函数特征进行对比，进行相似性搜索，然后搜索出结果之后，再根据这个函数，再根据这个搜索出的top k结果，识别出最有可能的这个oss和版本。基本的数据过程大概就是这样，就是一个经过特征工程查到N个或者得到这个N个函数，这个函数是伪代码函数。就是它的string伪代码，那么对应其中一个函数呢，它会去先变成就是先向量化得到一个N为向量，然后这个向量呢，会去查询一个叫做向量相似性搜索服务的东西，然后会查出来这个。这个服务背后是呃，一个含有海量源码的数据库，这个量级非常大。那么查到这个，呃，一个函数呢，会查会查到top k，原代码匹配的就是最相似的函数，所以说一个班里面的N个函数会查到N乘top k源码函数，对这些函数进行进一步的分析，就知道这个最有可能，比如说它依赖离偏NG的1.0版本，依赖Z的2.0版本等等等等等。

这中间一个最重要的过程就是这个叫做向量相似性搜索服务的东西。它背后的这个海量的源码数据库是非常重要的，而且这个量级非常的大，因为sca提示它的目的是要查找出这个软件所依赖的开源的组件吗？设想一下，如果这个数据库里假设假设一个bary，它真实情况下真的依赖了zip这个组件，但是这个数据库里没有Z里的任何信息。那么无论如何查找，最终的结果当中也不会有zip这个结果，因为数据库的依赖，数据库里就没有这个东西。所以说SSA的其中一个重要的这个任务或者说特点，就是要把这个源码数据库做的尽可能大，尽可能全。

才有可能找到更多的这个依赖版本。依赖的库。那么这个源码的数据库这个量级大到什么级别呢？可以大概用这样一个等式来判断。基本上就是开源库数量乘以tag数量乘以函数数量，得到最后的数据量级，那这个怎么理解呢？因为SC是要这个知道一个软件它依赖的依赖的哪个开源库的哪个tag，所以这两个是必然的因素，就是呃。这个呃，源码当中有哪些开源库，然后每个开源库的开课数量，这两个因素是一定会出现在这个假设里的。那又因为我们这个sa的算法是它的基本单位，它的操作单位是一个叫做函数的东西，所以需要把源码当中的所有tag下的所有文件当中的所有函数全部提取出来，它才是一个基础的单位，那么这三个因子的乘积才是最后的数据量级。

目前的话，科恩这边选用的是这个1.2万个常用的，呃，CC加加的开源仓库那。这个量级的开源库数量，最后能达到的函数的量级是10亿级别的，也就是说是有10亿条函数，并且这个每个函数还要附属带着它的，它属于哪个rele，属于哪个tag，总体的数据的大小能够达到TB的级别，所以说这个量级非常非常大。那总结一下这个IC业务的特点，就是属于强算法加数据驱动这样一个业务，因为数据的总量非常大，刚刚也提到这CC加加目前1.2万个，已经达到TB级别了，那如果未来要加入其他语言编译处的binary，比如说go编译处的binary，比如说ru编译处的binary，那么整整体的数据量会势必会更大。那第二个部分就是这个这么大的数据量是要在不同团队之间进行流转的，因为数据团队负责管理这个数据本身，那算法团队研究啊，调试啊也是需要这个数据的，那当他们发现这个数据可能需要更新，需要需要修正，需要清洗的时候呢，又会对数据进行修正，这个修正最后是要落到研发团队进行生产入库的。

所以说这一部分就会浏览到研发团队，而且更头疼一点，更头疼的一个问题是生产环境当中几乎是没有冷数据的，全部都是热点数据，因为压根不知道一个输入的bary，它有可能依赖哪些开源库，所以这11个函数当中哪一条数据都有可能被命中。所以说没有办法在整体上一定要做到冷热，冷热存储这样一个过程，基本上全部是热点数据。第三个部分就是数据的这个完整性，因为这个数据量实在是太大了。而且数据源在持续的更新，今天可能这个，呃，这个软件它打了T，明天肯定有新的，又出现了一个新的这个版本，呃，然后有新的这个库增加，所以说这个数据源也在不断的更新，那么这样大的数据如何在不同团队之间保证是完整的，大家用的都是同一份数据，出了问题也在同一版本的数据上查。

这个完整性也是非常重要的。那第四个点的话就是算法核心了，SSC绝对是一个以算法为核心的业务，我们基本上是基于现有的给定的算法来做一些线上的存储设计啊，工程优化。基本上是这样的一个一个逻辑。那针对这样大的数据量，我们其实在比较长时间的这个实践过程当中，其实形成了这样一套，呃，数据的流程吧，可以姑且称之为数据工程，就不知道是不是合适这么做，但是姑且称之为这个数据工程嘛。呃，基本上的思路就是说有了源码之后，可能入到这个呃数据库里，这这一部分是由这个数据团队来进行维护的，那么。呃，有一条定期的流水线，这个流水线会把数据库当中的一些数据啊，会丢到另外两个存储ES当中。然后为了有，为了让不不同的团队在调试这个数据的过程当中有这个统一的标准，我们会给这个流水线，也就这把数据打一个版本号，这个版本号是以日期为单位的，比如说今天假如说4月20号，那就是第一个这个版本就是20220420这样一个版本，那么这个版本的数据分别会入到两个存储的ES里面去。

从物理上将算法团队使用的数据和研发团队使用的数据隔离开，这样一来，算法对于数据的修正、调试，呃，研究等等都不会影响到这个。呃，研发团队，那么当研发团队拿到这版数据之后，他首先会经过一个测试环境的，这个测试环境的主要目的就是要验证这个数据的正确性或者数据的完整性。然后只有通过了这个指标之后，才允许走到真正的生产环境里去，那这个指标可能有很多啊，我这里列了几个，比如说你rap的数量，有算法层面的什么召回率啊，准确率啊，F1的值啊等等这些，所以通过这个指标之后，才认为这个数据是是完整的，是好的。

那比如说生产环境的数据可能是0320这个版本，那呃，有了新的数据之后，会更新到0420这个版本，可能运行一段时间之后，会发现有一些bad case，有一些数据需要更新等等等等等，那么生产环境当中遇到的一些问题会最终反馈到算法这边，那算法团队经过一系列的修复，把这些对数据啊，对代码的改正。会归总到一个仓库当中，这个仓库会作为下一轮迭代的一个依赖项。那这样一来，算法团队就把对于数据的修正通过这样反馈的方式。呃，应用到了下一轮迭代当中，就让一轮一轮的不断的进行，所以说会不断的提高这个指标，不断的提高生产数据的质量，通过这种方式来进行不断的迭代。所以说刚刚这个这个数，呃，数据的流转的过程介绍完之后，下一步就是这个过程，呃呃，运行完成就是。

这个过程能够比较好的，呃，让三个团队就是数据团队，算法团队和呃研发团队进行比较好的数据的管理啊，数据的交流，那这样一来这个问题能够比较得到，能够得到比较妥善的解决，那有了这个基础之后，下一步就是实现这个算法。呃，算法的话其实会分为就是两个大部分，呃，算法输入的输出是比较清晰的，算法内部的结构其实可以看成这样一种结构，就是这是SC的算法，是围绕着那个基于函数相似性搜索的一套深度学习的算法。然后这个算法呢，有一些这个数据的依赖，他在算法执，算法在执行的过程当中，可能需要某些数据，然后他会向数据进行请求，然后数据呢，再反过头来把这个请求下，呃，搜索的结果呢，再返还给算法，然后算法进一步的执行，就是这样一轮一轮又一轮这样不断的执行，最终输出一个ICU的结果，所以这个算法和数据之间呢，其实是可以通过一个抽象接口。

分离开来的。那么这个接口如果以的形式来表示的话，可能大概就是这样的。嗯，我定义一个叫做match的接口，那么它的输入是这个B得到的一个伪代码，那么它的输出呢，是这个伪代码最相似的top k。这个搜索的结果，这个结果里包含这个源代码，可能这个源代码是什么，包含这个源代码属于哪个re下的哪个tag，所以说通过这个抽象接口就可以很好的分离出算法跟数据，也能更好的帮助这个研发团队进行这个真实的实现。那么整体的算法结构大概是这样的话，下一步就只有呃两个部分需要实现，一个就是实现算法。第二个就是呃，处理好这个数据的存储问题，然后实现这个接口。那么实现算法上的话，算法本身，因为这里不会不会过多的去介绍那个深度学习的算法，主要还是想讲一下这个算法实现的这样一种方式吧，就是。呃，我们是选择翻译还是选择封装。

这两种的话，其实是一个见仁见智的问题，就是如果你是选择翻译算法的话，那可能会获得一系列的这个好处或者说收益。但是会有这个两点损耗，就是可能你的准确性保证比较难，然后如果算法升级之后，你后续的对齐成本比较高。然后另外一部分就是如果是选择封装算法的话，也是一样的，就是你可能会获得两点的收益，但是会丢掉四点的，就这四点的成本。其实这两种的话，呃，目前我们实践下来其实都有走过，最开始走的是3亿算法这条，那后续逐渐发展起来看，发现五和六这两点的成本实在是太大了，就是它远远超出了我们获得的收益。然后再后来就是通过由翻译翻译算法这个过程转向了封装算法，所以我个人觉得其实这两者之间并没有什么明确的优劣，或者说一边倒的哪个更好，哪个更坏，没有没有这样的关系，更多的是取决于呃业务的场景这样一个考量。

所以说算法的实现大概是这么样一个过程。然后第二部分就是存储了，存储的实现基本上是分成两块，一块是数据的入库的过程，另一块数据的出库过程。数据的入库就是说如何把这个。数据库，这个开源的，含有含有海量开源数据的这样一个数据库。呃，存储数据库构建起来。呃，基本上的流程大概是这个样，就是拿到一堆原码文件之后，这个原码文件可能不断的提取函数啊，增量更新到这个ES里，然后后面会接着一个自动的流水线，这个流水线呢会呃拉取ES，比如说这个0420这个版本之前的所有数据拉取这个数据会自动导入到一个。向量的相似性搜索服务当中，开源的产品当中是一个比较知名的向量，向量相似性搜索的这个这个呃服务了，然后你当然也可以用用别的去替代也没问题，由于这个呃Mars里面存的主要会是呃的信息，就是向量本身的信息，那么这个向量属于哪些？

呃，哪些rele哪些tag啊，然后呃，这个信息其实是呃相当于这个向量对应的原信息嘛，那这个原信息也是势必是要存下来的，所以说在在这个向量相似性搜索服务旁边一般会配着一个呃额外的信息存储，我这里写的是value，它你可以用PG啊，MYSQL其实都可以。然后数据库的呃，构建的过程大概是这么一个逻辑，然后第二部分就是数据怎么出库了，也就是怎么用这个数据，这个还是之前那个那个流水线那个那条那个呃过程。就是一个用户的B经过特征工程查到N个函数，N个函数会得到N个向量，然后每一个向量呢，会先去M里查最相似的N个向量是什么。

然后这些N个向量回来之后，再去查到这这些呃候选的向量对应的是哪些rele，哪些tag，然后把这个原信息拿出来，最终就会得到了N乘以top k函数。因为呃一个B里含有N个原代码，N个伪代码函数，那每一个伪代码函数会查询到top k对应的源代码，所以最终会得到N乘以top k源代码。然后对这个信息进行进一步的分析。聚合之后。就会得到最可能比如说这个bary依赖1.0啊，Z2.0啊，还有等等等等其他的一些开源的库，所以说嗯。数据库总体上会是这两个大部分。呃，总体上来说，SC是一个比较庞大的后端系统，它有可能呃存储大小，可能甚至TB及以上级别的这个数据存储大小，然后很多的数据呢，都是呃这点数据基本上如果做做冷热，冷热存储的话，可能还要考虑一下，然后基本上是没有冷数据的，然后除了除此之外呢，还有一些相似性搜索的业务要求，比如说你海量的inbding的存储跟版本管理啊，还有这个向量相似性搜索能力的提供啊，平行扩容啊等等等等等。

就是这些存储要求，因为量是实在是太大了，所以我们这边实践下来的话，感觉是一般一个比较小的单机系统，或者小型的这个分布式存储是满足不了，满足不了这样的业务需要的。我们这边。基本上就是使用的是依赖的云上各类的基础设施，基础服务去做一个支撑，因为数据的存储量实在是太大了。所以说SC的业务基本上是这样一个结构，就是bary进来，输入到SC系统，然后呢可能去调用一个SC这个算法的服务，这个算法最终也会布在这个K8S po上，可能这个依照一些HP的策略进行处理，然后如果这个算法需要数据，那么到就会请求这个云服务里边的各种各样的服务，然后得到一些信息，然后这个算法就不停的跑，不停的跑，不停跑，最终会输出一个的结果。

总体上的业务基本上就是这样一个结构。那sa的落地其实大体上会是这么多，就是算法加数据的这个，呃，介绍大概会是这么多，然后这边点一些经验教训吧。呃，前两点的话，看上去有一些这个万金有一些老生常谈啊，就是团队密切协作，频繁沟通，然后面向接口编程，其实能够真正把把这个协作沟通这些能够做到位，其实对于这个业务的落地其实是有非常大的帮助的。所以说还是要强调，还是要要做好这两点吧，然后第第三点的话就是一个数据的规范化，因为有一些数据可能来自于不同的原，有一些是不同源码平台的，还有一些呢，可能不同发行版之间也会差，也会有差异。

还有呢，就是有一些比较早的软件呢，它会通过一些FTP或者HTP的站点去发布这个zip包，这种也是需要管理的。另外一个部分就是术语的规范化，比如说你是管它叫rile还是tag，还是说库和版本，那么他们之间又有什么对应的关系，这些其实在真正落地的过程，落地的过程当中都是要理清楚的，因为术语和原一旦规范之后，其实是能够促进三个团队之间这个沟通和协作的流畅性。那第四点的话就是数据的完整性，这一点也在之前多次强调过，就是因为这个数据的存储量非常非常的大，一旦不同的团队之间数据使用的不一样，那一旦出了问题，排查起来就会非常困难。所以说这个数据的完整性还是非常重要的，一定要用使用各种各样的办法来保证这个数据的完整性。然后最后一个点的话，就是算法交付的这个验收的过程，可能不同的算法和研发团队，他们这个协作的模式可能有些不一样吧，呃，我我这边得到的一些就是个实践过程当中的一些，呃。

经验就是说，呃，因为算法在研究的过程当中，可能他不会特别关心这个算法的性能，这个算法的依赖性能好不好，这个依赖清不清晰这些问题，但是在落地的过程当中，其实是这些点都是必不可少的。那么尽早的介入算法的交付，发现这些潜在的性能问题，潜在的输入输入跟依赖的问题。输入输出跟依赖的问题，这些能够帮助呃这个业务更好的落地，能够提前预知一些风险，预留一些充分的时间给业务去做这个方案的调研。总体的话就是有这么几点比较，就是我感觉值得分享的一些经验教训吧，就分享给大家。啊，最后的话就是提一下这个科恩出品的那个班瑞亚这个平台啊，就是我我感觉它不止它其实不止拥有SC了，但SC是一个它比较比较强劲，也比较亮点的一个功能。

呃，除此之外，其实还有很多其他的功能的，比如说这个解包能力也非常强。然后也支持多种文件格式的文件分析，这种就是有一些其他的功能，大家感兴趣的话可以去把玩一下，就是网址的话就是8.cn。呃，我们后续的话也会持续的推进这个sa分析能力的，就是一些增强的分析能力吧，就是估计在呃后续这段时间会持续推出基于这个AI的一些分析，大家后面的话可以呃，期待关注一下。那最后的话就是再看一下这个，呃，这个整体的一个结构吧，就是比如说这些这是这个文件，这文件的这个256，然后这些文件的基础信息，然后最重点的其实就是这个composition这个页面它。告诉了这个就说明了这个文件的开源的版本，呃，开源的库是什么，然后对应的版本是什么，可能还有一些summary，然后这个版本对应的源代码可能是在什么地方都给你列出来了，所以总体的话，这个这个IC的结果还是比较清晰的。

嗯，好的行，那我今天主要的分享大概就是这么多，感谢大家的聆听，然后下面是QA，看看大家有没有什么问题。嗯，什么，我看一下。什么是翻译算法和封装算法？这里我大概介绍一下背景吧，就是说。

这个算法呢，就是呃，一般是这么个工作流程吧，就是算呃算法团队呢，会依照，比如说我们这SC这边，那么他会依照这个业务逻辑去呃设计实现一些算法，有可能是深度学习的，有可能是呃这个一些经典的算法，然后一般像深度学习的呢，他们可能就基本上只会呃，大多数情况下都会用Python去洗。然后业务逻辑这边呢，就是呃，研发团队这边呢，通常真正的生产使用的语言都不是排粉。所以说中间会经历这样一个过程，那么有两个选择。第一个选择就是。我们要么把Python翻译成，比如说我们用的多的就是go，我们把Python翻译成这个勾浪的语言。第二种选择呢，就是我在Python上面直接对它的算法进行一层包装，封装成一个这个HTTP的服务，或者说GP的服务，我就只用写那一层GC的那个外部的逻辑就行了，算法的核心其实是不会动的。

所以说研发在拿到算法之后，是面临这样两个选择。所以说这就是呃，翻译算法跟封装算法的这个这个意思吧。呃，我想知道你们这个搜索的准确性如何，因为看的结果最终实际上是提供一些相似组件的结果。嗯，不是不是这个意思，就是是的，就最终其实是。等一下相似组件。嗯。我有点没太get到这个相似组件是指什么意思，呃，我不知道能不能还切回那个。嗯。这边还能看到那个PPT吗？

我大概说一下吧，可能切不到那个PPT上面。呃，我们这边的话是会得到最终的，比如说它它它那个召回率可能就是或者说匹配度吧，就是比如说live p nng，呃，V1.0版本它的匹配是95%，然后V2.0版本可能是百，呃，或者说那个live派会是到94%，然后每一个库和版本它有一个匹配的程度，其实最后是不会要人力判断的结果的，我们最终比如说取一个阈值，比如说90%以上的，或者95%以上的，就认为是它真实依赖的结果，基本上是靠这个，可以说一部分是靠这个阈值来来判断最终的结果。呃，源码平台的数据是指源码生成的bin文件码，还是指源代码，是指源代码？

呃，源码平台的数据是指源代码，因为它要存储整体原，呃原就是开源的软件的源代码，然后进一步解析分析。所以说这个原盘源码平台的数据是指源代码。呃，误报误报率高嘛，需要人工介入嘛，这个更多的是，呃，算法层面上的一个。结果吧，我具体的数字我可能记不太清了，但这个误报率，误报率我可能我也我也记不太清，我觉得后续要不这个加到群里面，然后由这个算法的同学来进一步的说明吧，但是我们是不需要人工介入的，这一点是确定的。嗯，请问in的性能要求有没有？量化的数据，这个是指呃。哦，我知道你的问题可能是想，可能你是想问embedding，就是向量查询的时候的性能要求吧，我我猜可能是这个意思，这个的话，其实量化的数据我觉得是是这么考虑的，就是要根据业务本身的QPS来判来判断，比如说一个B假设平均它有。

2万个函数，一个bary有2万个函数，每个函数会生成一个in bedding，也就是2万个inbing，那么单个bary，它的查询的请求量也就是2万。所以说。然后那个相似性搜索服务呢，会比如说你出TOP10的inbedding，呃，查到TOP10的相似，所以说最终会是2万乘以十，也就是20万的结果。这个是按单个班来算的，如果说这个平台要求你的QPS，也就是说我换句话说吧，就是假设每分钟要分析，呃，比如说2000个binary，那么请求量就应该是拿2000乘以刚才的20万。

所以说这个数据是根据请求的QPS来判断的。我感觉我这边好像也没有办法提供一个非常量化的数据。我感觉我不知道这个是不是能回答你的问题。呃，想问一下性能问题，看起来性能需要还是很大的，大概的性能。指标这个跟刚才可能类似吧，跟刚才那个背Ding的问题，我感觉比较类似吧。其实就是根据QPS，根据QPS来算吧。呃，目前效果能达到什么程度，可以商业化了吗？这个问题是这样，就是8AI呢，是科恩对外推的一个，对外推出的一个一个免费的平台，然后有SC能力的试出，然后我们也会有这个商业的继是。呃，在云上的一个SaaS化的服务。所以说呃，是有这个商业化的产品的，只是不在AI上，如果需要的话，可以那个联系一下这个小助手，然后如果有商业合作的话，可以呃沟通一下。

嗯。应该真的用到了机器学习来学习二进制的信息吗？还是依赖于二进制中的字符串信息，呃。我想一下啊。我。可能不是语义信息，我猜可能不是语义信息，这个具体的话可能还是要算法同学来说会更准确一些，呃，但我理解的话其实是呃，用到了，比如说这个函数相似性搜索的话，是用到了伪代码这个信息的，然后当然你也可以选择一些像刚刚也提到的，像CFG，像这个字符串，像符号其实都可以，所以我觉得可能不仅仅是二进制的，就是不局限于二进制的语义信息吧，可能其他的可用信息都可以选择，只是看这个算法的思路，算法的策略是怎么样的吧。

嗯，一个。函数在多个版本中都存在。哦，这个问题还挺多的，嗯，一个函数在多个版本中都存在那。那一个函数在多多个版本中存在，就是把那就是把那个接口改掉就好了，就是说我明白你的意思，就是一个函数如果在多个版本上都存在的话，那么它的搜索的结果其实就是这个函数，呃的额外的信息就出现在多个rap多个ta下，其实它那个辅助的呃，额外的信息就是一个数组了。就不是单个的呃，Le tag了，就是我我知道是那个，可能想问的是那个，比如说那个go接口的那个，那呃那个定义吧，就是它是一个source code的，然后它后面有那个rele和tag，是一个单个的string，如果说是多个版本都存在的话，那么那个接口就可以改成呃，一个数组的形式，我那个就是一个可以说是个释义吧，就是你说的这个多个版本都存在，的确是存在的，呃。

就是一个函数在多版本中存在，这种情况的确是有的。然后就是把数据的存储和接口稍微做一下修改就好了。呃，然后代码加壳后能处理吗？呃，目前的话VI是支持。嗯。应该是我忘了是不是已经支持脱壳了，但是脱壳的话其实也分了，因为加壳壳的话，不同的文件格式其实都呃还蛮多的。所以说不同的壳可能要需要不同的这个方案去脱了，脱掉壳之后才能进一步的分析吧，但是目前是呃，可以支持upx。我觉得是可以支持UX的。嗯，有可能，我不知道是不是已经公开了，反正如果如果目前这个公网的班点CN上没有，就是U的话，应该也快了，就是我们会逐步推出来的，反正目前我可以确定的是可以脱upx的壳，其他的课目前还还不太行。

嗯，有没有考虑过把一套算法用在源码上，对的对的对的，呃，技术原理的确是共通的，所以说呃，我们科恩这边也有团队一直在研究去呃源码层面的sa分析，其实他们的原理是比较相似的。这个你说的的确没错。请问版本的识别和函数图嵌入的具体关系是什么呢？怎样通过函数的相似度？判断版本啊，这个问题我我看一下。请问版本的识别和函数图和函数是什么关系呢？怎么通过函数的相似度来判断版本呢？

嗯，我想一下啊。函数的相似度。哦，我明白你的意思了，呃，这个逻辑是这样的，就是拿到一个伪代码之后，先变成向量。啊，先变成embedding，就是你说的那个函数的嵌入，然后得到embedding之后去相似性搜索，然后搜出来的是跟这个。跟这个函数最相似的K的函数。然后这K函数，K函数其实是源码函数了，那这源码函数会有一些额外的信息，比如说它呃带着呃，它是属于哪一个rile，哪一个tag，或属于哪几个rile，哪几个tag，然后后续的话是通过一个这个就是分析，换句话说就是可能一个简单的策略就是分析这里边它最可这个出现次数最多的re是什么。这也是一种策略，还有可能是有别的一些聚合的策略，这个目前的话是呃，没有对外公开的，所以说这个聚合的策略是呃，目前不太好说吧。

总之就是经过查到top相似函数之后，再。呃，进一步的分析去，因为他有他已经有了源码的信息了，所以说可以通过一些策略去判断它属于哪个库和版本。A，后续有开源计划吗？目前还没确定。对。请问有多个版本，请问多个版本共有的函数如何处理？这个跟刚才那个比较类似吧，就是一个函数出现在多个库和版本上，其实就是把数据存储那一块的。呃，稍微改一下，可能我写的是单个，就是示意图写的有点太简单，就是一个函数出现在单个呃，Re，单个版本下，那它的确有可能出现在多个版本，那么这种情况下就是把那个呃函数的。呃，这个信息呃附带的就是Meta那个信息都呃都存下来，就是有多个呃出现在多个rele多个T下，这些信息都存就好了。其实。

和IDA flirt产出的结果有显著的对比效果，这个我感觉得问，嗯，算法，那算法团队那边有没有，呃，一些这个数据处理吧，他们那边可能会有后续的方案，呃，把这个效果。呃，公布出来吧。嗯，行吧，感觉好像。问题差不多了，那呃，我们这边的QA要不就先到这吧，时间关系的话，后边有新的问题的话，我们可以到这个群聊里进一步的交流吧。好，那主持人我这边就先这样好的，感谢小亮宝贵的时间，小亮今天还在上海，还在隔离哦，嗯，那个我们也为他加油，为上海加油，然后今天大家的提问也非常的专业，感谢大家在周三晚上抽出时间来参加我们的活动，那我看到还有一些问题应该还没有回答完，如果大家还想要进一步交流的话，可以扫描我们的二维码加群，然后后续的一些问题我们会在群里作答，那今天就先。

呃，先到这里了，那就请那个小亮可以退出那个直播间了，好的，拜拜，谢谢大家。