亮点回顾：白盒检测类工具在腾讯内部开发安全最佳实践原创

各位线上的朋友们大家好，欢迎参加腾讯云企业创新在线学堂系列课程，我是本次会议的主持人Lisa。腾讯云企业创新在线学堂是围绕企业业务需求，聚焦在数据管理、AI安全、办公协同等8大数字化需求场景推出的系列课程，携手腾讯云创新驱动无限可能，共同开启企业成长新篇章。随着Solo ws g等现象级安全事件频发，供应链安全进入了公众视野，那在软件应用生命周期里，修复漏洞的成本随着发现漏洞阶段的进程成几何增长。传统的漏洞方法通常只能在业务系统开发完成之后才能入，这导致了漏洞的修复成本高昂，甚至很多漏洞在安全事件发生后才会被发现及修正。

本次课程将帮助企业规避开发阶段以及第三方供应链，引入了安全威胁，分享腾讯公司多年沉淀的自身安全实践经验，助力企业在开发、运维全阶段实现应用软件安全质量提升，从源头降低安全风险。好了，那首先就有请我们今天的第一位分享嘉宾，腾讯安全科恩实验室开发安全高级产品经理陈思恩。陈老师负责腾讯安全科恩实验室S产品的产品运营与商业化工作，在产品输出与客户痛点挖掘上有丰富的经验。今天陈老师的分享主题是软件成分分析的风险挑战与方案实践，有请。呃哈，线上的各位企业老师大家好啊，我是来自腾讯安全科恩实验室，呃，开发安全团队的产品经理陈思恩，那今天呢，非常荣幸啊，有这个机会给各位线上的企业老师做一下，我们腾讯安全就是在软件分析这块的一个呃解决方案吧，以及呢相关的一些核心能力的介绍，那话不多说，那后续呢，我就开始我的正式的一个相关的一个分享。

呃，然后今天的分享呢，主要会从四个方面去进行分享，那后续呢，其实还有一个产品演示的环节。那先简单介绍一下自己吧，就是我主要是呃，腾讯安全科室这块的IC产品的产品经理，主要负责的是我们这边的一个产品化相关的一些工作，那在这一呢，也是跟很多的企业有过一些接触，所以在一些产品输出啊，包括一些上会有一些丰富的经验，那今天要讲的第一块呢，主要是我们在软件供应安全建设当中的一些必要性。那其实这一块其实大家应该或多或少都比较熟悉了，就是因为软件供应链安全，我们从呃很多年前就开始讲这个东西了，那其实他主要的一个呃点的话，其实更多的就集中在我们说像漏洞啊，像一些组件的风险这一块，那它的一个大概的一个概念，就是像我们从软件供链安全发展洞察报告里面，呃摘下来的这样的一句话，就是它其实主要就指的是我们在软件的一些呃需求设计啊，包括像开发测试以及到后续的运营，那这个各个过程当中，这里面可能会涉及到一些编码工具，还有一些呃交付相关的一些总和，那这些呢，都属于软件供应链安全建设的一些范畴。

那其实软件功能安全里面还会涉及到一些，比如说像泄密啊，勒索，像木马，像一些劫持这样一些安全风险，那企业或多或少也会采用一些啊，不管是IC的工具，或者说其他的些工具也好，那都去解决这样的一些软件安全的一些点在这个里面，但是会有一个根本性问，就是我们采用了这些工具之后，有没有呃从就是最根本上解去解决整个的一个安全风险的，那其实这个是存疑的，那其实软件功能安全整个的一个从行业上来看的话，它也是逐渐的受到国家的这样一个重视，特别是二一年的时候发生的像阿帕吉街这样一个漏洞之后，那其实行业包括国家整个层面也存台了很多一些监管些政策，在这个里面，包括最近金融行业可能出具比较多的一些呃，风险的管控的政策和手段是比较多的，然后呃，从腾讯这一块的一个互网这样的一个经验来看的话，就是啊，因为腾讯之前我们是一直是作为攻击队嘛，然后也会有一些防守队在这个里面去呃扮演相关的一些角色，那其实我们分析下来就是整个的一个软件功能安全。

趋势的话，在攻防演练这一块，更多的就是会有60%的这样的一个事件案例，都和软件供安全有关，并且呢，呃和开源组件的一些风险，这些挑战，这个里面的一些呃管控的手段，那也是国家级的共同演练当中top的这样一个攻击法，所以其实可以去看到整个软件供能安全，它其实是呈现的一个比较紧迫，然后以及呢，有一定的建设的一个标性，以及很大的价值在这个里面的，所以呢，呃，那后续其实介绍的就是我们对软件供应链这一块的一个呃安全的一个解读，那因为软件供应链其实我们分享的它其实是有多个的一些呃方向的，那IC呢，就是今天要讲的这个，它其实是软件当中的一个重要的一个指方向。

那也是软件供链，呃，安全当中一个重要的一个支撑工具，那什么是IC呢？就是我们说软件分析，就是它肯定是针对于软件，那这个软件就会包括像智研软件和第三方的开源组件，那第三方的一些呃外购的一些制品，那这个里面会涉及到一些第三方的开源组件，那其实会有很多企业要不是已经建设了相关的一些，比如说软件成分析能力，要么呢，就是没有相关的一些能力，但是我们又需要去知道，比如说外购的制品当中可能会包含一些，呃软件的一些资产，我们需要去知道这些信息，因为这些信息它会关联到开源组件的一些漏洞信息，那这里面可能会涉及到一些引进的漏洞，包括我们像国内的国国内外的三大漏洞库嘛，像呃NVDCDCD，那这些漏洞，我们的软件产品当中包不包含这样的一些漏洞风险，那这些呢，都是我们需要去知道的，包括现在很多企业呢，呃都在去做这的一些信创替换，那我相信呃现场的各位老师呢，就是呃应该也会有一些企业去做这样的一些呃信创替换相关的一些呃建。

所以在这个里面。但其实信状替换也会用到很多这些第三方开源组件，那在这个里面信创替换的软件就真的是安全的嘛，这个也要打上一个问号，所以也是需要有IC这样的一个能力去帮助我们去发现其中所存在的一些安全风险的。然后这个呢，是我们在软件供应链的一些风险的一些相关的一些呃风险案例吧，就我们收集了一些，那这里最知名的可能就是21年啊，大家比较熟知的像阿尔法这样的一个漏洞，那这个漏洞其实就是一个影响面和危害非常广泛的一个漏洞，也被称为是一个核弹这个漏洞，那其他就就不过多的去赘述了，其实最近发生的事件，就比如说像呃24年3月的时候，那大家应该比较熟的，就像开源压缩工具出来的这样一个漏洞，那以及呢，近期最近的就是像七月份的时候，像发生的open s sh这样的一个远程代码执行的漏洞，那这些呢，都是影响面和危害非常广泛的这样一个开源现漏洞，所以也是呃，需要我们企业去加以关注和一些呃，一些实践，在这个里面去帮助我们去定位到我们哪些软件资产用到了这些开源组件。

那除了开源组件本身所包含的一些啊漏洞风险之外，那我其实我们也建议就是对于开源组件的许可证风险也需要去进行关注，那比如说像二一年的时候，就像抖音就上线了这款产品，那其实为什么说上线不久之后，它的一个呃下载页面就会删除了，那其实最主要原因就是因为它里面违反使用的呃这样的一个G票L的这样一个许可证，那这个许可证呢，就是它是一个强传联性的许可证，它就会要求如果说我们企业的软件里面包含了这样一个许可证的一个license的一个分发情况的话，那我所有的一些，呃，就是我里面要用到一些代码，包括已经打包好的一个制，或者说软件都需要去进行开源，那这个对于商业软件来说是不可能去做到的，所以就只能面临一个违规侵权的一个风险，那采用科恩的这款产品呢，可以帮助我们去更好的去发现就是。在软件当中所包含的第三方组件，以及相关的一些license合规的一些信息，帮助我们法务团队去规避掉本该去呃，没有必要的这样一个风险吧。

然后这个呢，是我们和国内公安三所合作共建的这样的一个行业的一些标准，我们把呃也叫做软件分析系统件技术要求与测试评价方法，那这个里面其实就涉及到的有开源组件这一块，有四大的一些风险挑战，比如说像漏洞风险这一块，那这一块我们更多的需要去关注的，呃像是漏洞信息的明细啊，包括像漏洞可察性，那漏洞可察性这个概念呢，其实也是现在对于漏洞收敛，包括风险定位一个很重要的一个概念，那它的一个大概意思呢，我会在后续进行详细的一个介绍，那除此之外呢，还比如说像投资风险，就比如说我们研发人员去其他的上去拉一些有代码的包，那在这个里面可能就会为一些呃，恶意的攻击者去植入一些有后门的代码，那这样的话，我们再去拉这个包的时候，就会给我们整个的一个软件资产带来很大的一个风险。那除此之外还有像开源许可证的风险，还有像供应连续性的风险，那什么是供应连续性的风险呢？就比如说啊，我们用我们企业里面的软件里面，或者说制品里面用到了很多第三方的一些呃工工具包，那这个里面如果说开发社区没有去去进行维护了，那比如说长达两年三年都没有去进行个维护了，那他就会面临一个组件停止维护的一个风险，包括这里面可能会涉及到一些。

啊，像许可证发生变更啊，或者说license发生一些变更的一些行为，那这些呢，都是供应连续性息，呃连续性上所会涉及到一些风险，那除了开源组件本身所面临一些挑战之外，那我们对于自主可控上也会有些要求，比如说现在大家大家都在做一个国产化的一些替换嘛，包括性状一些支持，那呃嗯，那这里面去去其实去要求的就是我们需要去做到核心能力的，呃，自研以及核心数据可控，以及呢像国环些支持，那在这块科能产品都是有很强的一个适别和支持能力，那其实我们也了解到一些友商，它其实很多时候他们一些核心能力并不是自研的，可能会采用一些开源的一些呃能力，然后在这个基础之上去做这些加工，那这个的话，其实没办法去做到整体的一个核心数据和核心能力的一个自研和可控。

然后第二块我想去分享呢，就是我们企业在开源组建治理上存在一些痛点，因为刚才其实讲到了很多一些风险案例啊，包括一些行业政策，一些监管上的一些要求，那其实企业在呃开源组件治理上其实也会存在很多痛点，就是难以去下手，那这些主要会涉及到哪些方面呢？就比如说呃，我们说有缺乏I力体系的一设，就可能会建设其中的一块，比如说只设，但是没有去建设些制整个的一个一些安全主义的能力，或说呃正在建设当中，那这像我们在和客户去进行沟通的时候，发现经常会有企业，呃就是会有涉及到这些方面的点吧，就是缺乏整个的一个规划，或者说缺乏相关的一些能力，一些建设。那第二块呢，是。呃，缺乏整个的一个开源风险的一个风险治理的一个能力，因为像发生了阿法这样漏洞，包括像7月发生的这样一个open的这样一个，那如何通一些方式去快速的去到我整个软件资产当中，有没有去用到这样的一些，呃开源组以及呢，就是用到了之后，我如何通过一些方式去发现这样的一些潜在的一些风险，就给到我们企业的研发人员去进行修复呢？那这些呢，都是开源风险预警上所会涉及到的一些点，那以及呢，就是现在会有很多企业去通过一些外包采购，或者说外采的一些制品，那那这个里面就会涉及到一些制品的准入方面的一些人力些建设，比如呃，现在就银行业就要求我们在啊企业在进行一些呃外制品的时候，必须要识别到里面的，呃，必须要拿到其中的一些呃一些清单，因为这个里面会帮助我们的一些银行，包括一些监管企业能够去知道我所采用的这个产品当中，它的一些软件资产是什么样子的，那如果说在发生一些漏洞的行为，我可以快速的去知。

啊，到底是哪个供应商里面提供了哪些制品所包含这样的一个有呃微有风险的这样一个开源组件。

那除了缺乏能力的一些建设之外，那么在一些呃建设的痛点上，比如说可能会有些IC的能力没有全覆盖，可能只有原码或者说制品，或者说呢，受限于采购的一些呃有商的产品，那可能会有一些分分析能力受限的一些点，在这个里面也能导致整个IC能力没有全覆盖，或者说覆盖的不是呃很很好的能够解决呃企业里面存在的一些问题，那第二呢，就是呃我们说最近就是很多企业都在去建设IC这样一个能力，那建设完之后会采用一些工具，那工具其实会分析出很多的一些呃，像风险啊，像漏洞的一些点在这个里面，那如何去针对组件去针对漏洞去进行修复呢？那这个里面也会存在很多一些点去做，那呃，很多工具给到企业这边之后，那企业直接就傻眼了，因为不知道如何去进行修复，因为这个里面会涉及到很多的一些啊组件和一些漏洞风险在这个里面，那如何给到企业这样一个建议，帮助企业去收敛风险的，那这个也是我们去重点去考虑一些点，包括像整个的一个S报一个台账的一个风险运营。

那我们需要去建立企业级的这样一该form啊，如何去进行收集，那如何去针对不同的维度去进行收集，以及呢，发现风险之后如何的去快速去定位，那这些呢，都是企业在开源呃组治理上会存在的一些痛点的一点，所以总结来看，企业在开源组治理上会存在一些呃像能力建设缺乏，检测覆盖不足，以及呢，像风险修复困难，还有运营等一些痛点。呃，然后这个是我们科恩就是整个的一个，就是围绕着我们现在围绕着AI算法，围绕着知识库，以及围绕着我们整个的一个安全运营的一个体系能力所打造的，在IC分析这一块，我们内部的一个核心的一个优势能力，那这在这一块我们像我们的一个业内领先的一个能力，就是我们的二进制以及代码级的片段的这样一个分析能力，那这里面就覆盖了像啊制品的扫描，像源码，呃，代码片段的这样一个扫描，那二进制呢，一直是我们科恩的一个独有的一个优势，因为我们科恩之前也是一直做啊三楼测试漏洞挖掘请假的，所以对于二进制这一块研究是有很长的一段历史的，包括在这里面也取得过很多一些成绩，像我们发表的很多的论文专利，已经被国内外的一些，呃，知名的一些像一些学者啊，一些研究机构所引用，包括我们内部的这样一个科文的这样安全算法能力已经开源了，也已经受到了大家广泛的一个关注和引用，那除了二进制的这样一个核心的一个扫描能力之外呢，就是我们对于通用能力语言的覆盖，那也可以做到一个很好的一个支持，比如说除了覆盖啊。

市面上常见的语言还包括像一些小众语言，包括像现在适配现在的一些鸿蒙WS语言，包括鸿蒙的一些工程的能力，目前都可以去做了一些配。呃，那除了这样的一个扫描分析能力的是领先之外呢，那在于组件的数据这一块，更多的就是我们说针对漏洞数据，针对组件数据，针对整个的一个许可证数据，那可能这一块也都是有一个全面的一个收集，因为我们在呃三大数据库的收集的基础上，也会基于我们腾讯内部的这样一个漏洞库数据，我们也会接入腾讯内的这样一个漏洞知识情报，所以对于整个的一个数据的一个收集的一个量级覆盖程度，基本上可以做到一个行业很领先的这样的一个程呃程度。

那漏洞可查性呢，这里呃可以去带一下漏洞可查性，我们说它会分为呃两个维度，一个是存在性，一个触发性，那存在性呢，就是我们会去定位到这个漏洞，去根据它的些代码去定位到这个漏洞，它在我们真实的发现当中的一个代码的片段在什么地方，那漏洞触发现呢，就可以帮助我们去更好的去，呃基于一些漏洞调用链的一些分析去判断这个漏洞，它的一个起始函数和重点函数，帮助我们更好的去呃给研发人员去定位到这个漏洞，它具体风险在什么位置，以及后续修复的话，可以修复哪些代码片段啊，从而去更快速的去帮助他收敛风险，那安全运营体系呢，更多就是我们整个的一个呃平台是已经接入到到了腾讯内部的这样的一个资源体系当中，那每天呢都会有呃，就是呃上T级别的样一个源码和制品在这个里面去进行扫描，所以我们有有时有时候也会经常去遇到一些企业客户会问，就是我们的产品有没有去给自己内部人员去进行使用，因为从客户的角度来说就是如果说你的产品没有给内部人员去进行使用，那其实就。

不是一个成熟的产品，那刚好的这个产品呢，是我们在内部是已经有了高度的一个集成，包括我们和内部的像科南京，还有像智研这样的一些平台，都已经做了一些一一系列的一些集成，然后包括呃，对这些工单系统啊，都已经有了相关的一些集成，您内部已经在大规模的去进行适配和扫描。呃，然后第三块就是我们企业在开源治理上的一个就是相关的一些实践，那在这一块就是，呃，首先要讲的就是我们T软件分析这样的一个安全解决的一个方案，那这个方案的话，我们说从基础的分析上来说，它其实主要包括了，呃，其实对于更很多企来说，其实主要包括两个两两个维度吧，一个是源码，一个是制IC，然后系统系统审计这一块更多就是我们在和一些企业交流后发现有些企业它会呃，针对他自己内部的一些服务器，就是已经找不到源码包，或者说制理包就已经运行了很多年了，那如果说企业对这一块有一些安全扫描的需求，那就可以通过我们系统审计的这样一个模块，去发现其中存在的一些开源风险，以及呢，系统的一些机械安全的一些风险，那在这个里面更多的是我们之前针对车企的一些用户，那现在也慢慢的去覆盖到像金融啊，像一些呃，像医疗等一些呃，相关的一些客户都在去用这样的一些能力。

那除了基础的分析，再往上一层的话，就是相关的一些，呃，数据分析，我们说在这个里面会涉及到开源组件知识库，那组件的知识库的一个量级和质量的话，是很重要的一个层面啊，我们客人在这一块是对接的整个腾讯内部的这样一个漏洞知识库，所以对于整个的数据和量级和质量是很有保障的，那再上就是整个的一个平台的一个管理，就是围绕着像管理以及整个的一个，呃，像建立黑白名单呀，像一些缺陷管理相关的一些呃，团队管理，人员管理，在这个平台里面都可以去做到一个相应的。那在这一块其实就不进行过多介绍了，在这一块其实主要是一个开源组件风险的一个识别逻辑，那这个里面更多就是我们如何去发现其中的组件，那组件版本以及相关漏洞，那更多的是我们过多种识别能力一个组合，比如说像呃，对于组件的分析的话，我们更多会通过像源码，语法片段，静态包管理器，动态包管理器以及相关的一些特征去进行分析，更精准的匹配到这个组件之后，然后我们再去基基于一些版本的一些特征，从而去分析出这个组件它所对应到的一个版本信息，然后再去基于组件和组件版本，我们再基于我们的漏洞知识库以及漏洞相关一些特征分析，从而去匹配到这个版本里面所包含的一些相关的一些漏洞，再给到我们企业关于整体的就是这个原码包或者说制品包的一个S的一个清单的一个情况，包括里面会涉及到的一些抗源风险。

那这个方案总的里面，其实我们总结下来，企业在开源治理这一块，其实更多的集中在这四个场景，那第一个其实更多的就是在呃开发技术场景，那这里面就会涉及到，比如说呃，在代码编写阶段，那这里面更多就是源码I，那比如说到了编译集成的，或者说到制频入库了，这阶段的扫描更多的是通过制品进行扫描，那我们产品是可以做到一个全生命周期的一个集成和管控。那第个场景呢，就是我们说到的，呃，像供应商的一些外采的场景的一些准入，那在这个里面就会涉及软件准入方面，就我需要去知道供应商给我提供过来的一个品包，它里面所包含的软件资产。那第三块呢，就是一个整个的一个安全台账的一个运营，就我们说如果再发生了一些安全风险，或者说我们基于现有的这样一个安全台账，我们如何去进行一些运营，那第四个呢，就是我们最近正在跟各个企业去推的，就是这样的一个推，呃，组建治理就叫退休优化这个场景，就是我们通过一些工具扫描出来很多一些风险之后，我们如何通过一些方式。

通过一些平台管理的手段，去更好的去帮助研发和安全运营人员去呃运营这个风险，或者说叫治理这个风险，以及呢，就是呃整个的一个呃，帮助他去收敛整个的一个安全风险的基础上，去帮他减轻一些工作量，就帮他去定义哪些组件应该去进行修复，哪些漏洞里面去进行修复，那这样的话，我们企业就可以节省出很多的时间和精力去做重要的事情。

那这一块更多就是我们针对每个场景的一个详细的一个呃描述吧，就是比如说在开发接入场景这一块，更多的就是一个整个的一个软件开发全生命周期，就是SDL，我们说就是针对码，对于制阶，那比如我们可通过件的方集，通过代码仓库，像像编译，比如说我们些都有深度集，对于制库的话，也可过库的，通过我们件A方式，通过C方式。那在软件准入场景的话，更多的是通过，就是像包，像服务器在进入到我们企业之前，我们需要去对它进行一个准入，那准入要进行扫描，就是IC的这一块的一个扫描，我们需要去发现其中所的组件的一些啊清单信息，需要去风险，那有了风险之后再去基于这个风险去下发这个治理的一些呃方案，给到下面的供应商整改之后，再给到我们企业这边去进行扫描，那如果通过的话，这个制品才能够去进行入库。

然后这个场景的话，更多就是我们和很多业交流下来，很多企业会采用了一个方式就是呃有了这样的一个S开账之后，就去进行一个退优化，那其实在腾讯的这样一个经验来看的话，如果说只采用这两种方式的话，其实很难去，呃运营或者说管理整个的一个开源组建，治理一个呃风险，那我们通过内部的一个经验发现，我们更推荐的方式是通过像IC的工具，呃有了这样该form台账之后，我们需要去知道这个工具它的一个风险的一个，呃扫描能力是怎么样子的，以及我整个的一个啊软件或者说制品，它里面的一个风险是怎么样子的，所以会有一个风险评估的这样的一个，呃中间的一个过程在这个里面，就比如说以漏洞为例，我们扫描出在一些漏洞之后，我需要去看一下我这个软件的漏洞的情况是怎么样子的，以及呢，这个工具所检出的一个漏洞风险是怎么样子的，有了这个评估之后，我们再去上线一些管控的一些审核手段，比如说现在很多企业会做的。

呃，质量的卡点，或者说呃流水线的一些红线，或者说相关的一些管控的一些黑白名单的一些，呃设置，那在这个里面都是一些管控的相关的手段，那有了管控手段之后呢，我们再去进行推优化，对通过这样一个运营方式的一个呃流转不断的去运营的话，就会是一个比较合理，比较完整，比较全面的这样开源组件治理的这样一个方式。然后第4块想去介绍的是呃，企业的一个实践相关的一些案例，就是我们之前合作过的一些企业的一些案例吧，那这一块是我们在金融这一块，那这一块更多就是呃，他们企业里面的一些诉求就是呃需要通过一些自动化的安全工具来进行制品的安全管控，那这这个里面就对接的我们腾讯内部的这样一个客平台，通过自动化的去触发，然后去检测其中所包含的一些开源的一些风险。然后在测试里面更多是通过一些像系统审计啊，像一些固件的一些扫描，更多的通过二进制的一些检测的一些场景，去帮助他们去更好的去发现其中所包含的一些看病风险，包括可能会涉及到一些系统的一些线的一些安全审计的一些问题。

然后供应链管控的话，更多的就是通过一些啊漏洞啊，一些相关的检测，帮助企业去建立整个的一个S的一个清单，帮助他们去识别到啊整个企业里面所包含的软件清单，以及相关的一些多风险，帮助他们去建立整个的一个管控的一个体系。然后在政府这一块，其实更多的就是关注的就是我们需要去建立整个的一个安全运营体系，包括呃开发安全管控的一个体系的一个建设，以及在这个里面把整个流流程去进行跑通，跑通了之后呢，去帮助他们去发现一些风险，有了风险之后呢，再帮助他们上线一些安全运营的一些手段，帮助他们去更好的去管控整个的一个风险。然后第5块我觉得是需要去做一个产品的一个演示，因为光通过一个PPT介绍，可能大家还是呃以去呃对这个有一个很直的一个认，所以在这一块我会有接下来会进行一个产品演示的一个环节。

呃，然后这个呢，就是我们线上的就是一个SARS化的类似于sa萨，呃，SAS化的一个体验的一个环境，那这个环境里面就是我们整个平台的一个能力，在这个里面去进行集成，那这个里面刚开始进来呢，它其实是一个概览的一个界面，那这里面里面就会包含了就是我们整个的一个团队数，当前项目数及相关的一些安全审计，安审计和漏洞审计相关的一些概览的情况，所以基本上是一个比较基本的一个概览情况，可以大致的去进行查看，那比较核心的是在项目管理这一块，那在这一块进入之后呢，我们可以去，呃，切换一些团队啊，或者说新建一些相关的一些分析项目，就是我们整个是以团队维度，呃，通过团队，通过项目，再通过具体的分析项去建立这样的一个三层次的一个关系，帮助我们更好的去匹配整个研发的一个体系，呃就比如说呃讲一个刚才讲到的一个原发呃的漏洞可达性这样的一个案例，为呃介绍吧，就点进来之后呢，可以看到我们之前分析好的这样的一个项目，那其实关于IC的一个开源组件的一个生产清单，报这一块更多的就可以去看到我们针对这个源码包检测出。

进来之后，它里面所涉及到的一些开源组件的一些风险的一些情况。比如说这样的一个组的一个资产的一个单于组的一个，我们采用是P，并没有使用整个的一个呃标准的一个定吧，就是我们多的用P样定位帮一的识别定，就是这个码品的它的一个唯一性的一个情况，以及呢就相关的一些检测一些来源的方式，那在这里都有详细的一些呃展示，包括目前我们最近在呃大在推的就是整个的一个组件的一个标签，包括漏洞的标签，就是我们这里会帮助企业去打上一个呃建议修复的一个相关的一些标签的方式，那在这样的话就可以帮助企业更好的去收敛整个风险呃收敛整个风险呃让企业知道哪些组件应该强烈建议去进行修复，那这样的话，就不用他们人工的去进行一个个排查。

那比如说随便点开一个组件为例啊，在这个里面的详细的组件相关的信息，包括如果要对这个组件去进行修复的话，我们有推荐版本，无漏洞版本，还有相关最新的版本，以及呢，这个组件所关联到的一些文件相关信息，或者说呃，通过一些代码片段的扫描能力的话，也可以去看到这个组件就是它所引用到的第三方开源代码的一个对比的一个情况，比如说在这个里面，他那个PP是61%的这样情况，那超过50%的基本上可以判断为这是一个研发抄写过来代码，或者说直接是引用过来的这样的一个代码片段，可以帮助我们去更好的去定位到整个的一个风险引用的一个情况。你到这个组件，它所关联到一些license，或者说相关的一些漏洞信息，以及这个组件它本身，或说向上的一个相关的一些依赖的相关情况，那都可以在这里面有一个很好的一个展示。呃，那除了组建的一些风险情况之外，我们说那更多的一些，大家比较关注的就是漏洞这一块，那这里就找一个关于漏洞可察性的这样一个情况。

那点开这个漏洞之后呢，更多的我们可以去看到这个漏洞的一个基本的信息。包括这个漏洞的一个相关的一些修复的相关的一些信息，如果说我们想要去针对这个漏洞去进行修复的话，那这个漏洞它里面所关联到的一些补丁信息，包括解决方案的都可以在这里面去进行详细的查看，那以及呢，这个漏洞关联到组件啊，以及像一些漏洞的评分CS信息，然后就是这个刚才讲到的这样的漏洞可达性，那漏洞可达性呢，我们这里会划分两个维度，一个是漏洞存在性，然后还有一个是啊漏洞的一个触发性啊，漏洞存在性呢，更多就是我们会去基于呃，之前修复的一些派的一些代码的去匹配到，那我们所引用到的这样一个组件里面，它有没有去引用这样一个漏洞的这个代码片段，那如果说有引用的这样的一个大片段，我们就会给他打上一个啊漏洞存在性上的这样的一个标签，就帮助我们研发人员去定位到这样的一个漏洞存在的一个位置，那既然存在了，那下一步要做的就是那这个漏洞它是否是能够被触发的，所以我们下一步要去做的就是一个触发性的一个验证，那在这个里面，我们会基于一些漏洞调用链的一些分。

的呃手段和方式，从而去判断整个漏洞代码的一个调用的一个情况，比如说在这个里面漏洞代码被呃调用了，那这个时候它会影响到我真实的一个业务的情况了，那这个时候就会给他打上一个漏洞触发的一个表现。所以通过这个漏洞存在型和漏洞出发现，那就可以给安全的运营人员和整个研发的人员一个管控的一个手段，因为这样的话，运营人员就可以有这样的一个方式去告诉研发人员通过何种方式去进行修复，那研发人员就知道，呃，通过这种方式就可以知道在哪些的位置是有代码的，呃，是有漏洞的代码的，从而进去进行快速的收合修复。呃，以及呢，就是最近在推的，就是会有一个漏洞标签的这样的一个呃功能，就比如说我们会有一些POC叉B，还有重点关注的一些标签，那这些标签的话，基本上也是我们如果说要去啊对漏洞去进行修复的话，那们去需要重点去关注的，那基本上通过我们科内部的一个事件进来看的话，如果要去针对逐建漏洞去进行修复的话，我们首先去关注呢，其实是一个漏洞可达性，就比如说呃筛选一些可触发的一些漏洞相关情况，那呃有了可触发漏洞之修复完之后呢，是最先级去进行修复的，然后再去修复一些，比如说PC叉重，还有利用这些漏洞打上标的漏洞，那这些漏洞都是有具有高危风险的，那这些修复完之后呢，还可以，然后再去基予一些漏洞的一些方向等级去进行筛选，然后再去筛选这样一些啊，修复这样的一些漏洞，那其实这样的一个方式其实还是比较繁琐对吧，所以呢，我们对于组件这一块，其实更推荐的一个方式就是组的啊，比如说以作用组件为例，其实更多的有推整个的一个组件的一个升级，那这样的话。

就可以呃，批量的去修复一些漏洞，这样的话就比较方便了，那这里会更多结合的就是我们的一个组件标签。然对license风险这一块，更多的就是我们会去呃看这个项目分license以及和这个项目里面所有license，呃，就是每个组件里面所包含的license它们的一个兼容性的一个对比情况，以及每一个license的一个风险的一个情况，在这里面都会有详细的一个介绍，比如说随便点开license，呃，这个license它的一些呃相关的一些详细信息，以及呢，这个license它的约束条件，比如说要求什么，禁止什么，允许什么，以及相关license的全文都可以识别和扫描出来。

那在关联组件这一块就可以看到这个license，呃，哪些组件用到这个license，以及呢，关联到哪些文件，以及相关license有没有发生一些，呃，串改的一些行为，那在这里面都可以帮助我们的法务团队去更好的去研判整个license的一个风险情况。那这这一块呢，其实更多就是IC软分析这一块，那除了去做软件分析，我们说我们还可以做到像一些敏感信息的一些审查，比如说我们可以去针对一些啊全量的IP，全量的URL，还有像一些呃ul密码呀，还有像密钥对象呀，还有像一些敏感邮箱，那敏感邮箱这个其实也很有帮助，就是在互网期间，其实发生一个比较多的就是社工，呃邮箱的一个调鱼攻击啊，其实像之前的工行，工行其实好像就是呃邮件的一个泄密相关的一些方式去嗯造成的一个安全的一个风险，那这个呢，就可以帮助我们的企业的研发和一些运营人员去帮助我们更好的去呃判断和定位到就是哪些文件里面去用到了这样的一个敏感的一个呃邮箱，然后去从而去针对性的去进行理。

那除了一些敏感信息审计，我们对于呃这样相关的一些风险审计，比如说还会识别呃一些像license的串改啊的串改啊，包括投毒的一些组件相关一能力这一块的一个介绍，然后这一块那除了分析能力，然后还有的个平台管控，因为我们想去做一个O的一个平台，所以对于后续的一呃介绍的话，就平台整个的一个管控能力了，就比如说呃现在企业会嗯比较多关注的像建立企业界和黑白名单，那就可以在组员管控里面去新建一些啊黑白名单的一些数据，那这样在分析的候就可以去呃关联到这样一个分析啊关联到的分析之候，就可以帮助我们去更好的去看一下哪些命中的黑名单，哪些命中的白名单，那如果说想不仅仅想去针对组建维度去设置黑白名单的话，那也可以通过。

这样的一个分析审核策略，我们可以去针对组件，针对漏洞，针对呃license，以及呢，像针对甚至去基于一些安全审计的规则，那在这里面就比较细了，可以针对具体的某一个呃安全的审计项，去建立一些黑名单管控的手段，从多个维度，多个角度，这样的方式帮助我们去更灵活的去设置整个的一个安全管控的一个分析审核策略。那在知识库这一块，更多的就是这个是我们腾讯内部去维护的这样一个漏洞，知识库组件知识库那更多的就我们可以去呃针对一些呃相关情况去进行筛选，比如说呃筛选这样的情况之后，它有一个这样一的标签，那这个其实就是一个停止维护的一个标签，这个就是我们会判断它是一个供应连续性的一个风险，就是组建呃已经有很长时间没有去进行更新了，那这个组件已经会给他打上一个停止维护的标签，那这样研发人员对于这个组件的一个版本就不建议去进行使用了。

包括针对漏洞搜索，针对license进行搜索，那目前上线了一个就是我们会针对代码片段去进行搜索，就比如说我们研发人员在使用的呃代码助索去呃写一些代码的时候，想去知道这个代码他可能会和哪个呃开源组件最相似的，那需要万一会可能会涉及到一些呃风险合规的一些问题嘛，所以这里面会有上线的这样一个功能，帮助我们去判断我们呃写的代码的会关联到哪一个呃开源的一些组件信息。那报这一块更多的就是一个台账信息，那这个台账的话，我等会在数据看板里面也是整个的一个台账，详细的一个信息，那后续的话，其实更多就是整个平台管控能力，然后包括一个集成管理的一个手段，那平台里面是集成的像基能、集能LA这样的源码库，还有进账库来比小三制品库这样的一些方式，那其实更推荐的方式会通过一些A方式。

呃，因为时间有限，我就快速去过一下啊，就是然后这一个是一个数据看板的一个能力，在这个里面，其实数据看板这个里面是其实呢，是我们腾讯内部的一个实践的一些经验，那比如说我们说退，我们刚才想到的就是我们想要去更好的去帮助企业去进行退休治理优化，那我就以这样的一个组件为例，就以这样一个大家常见的这样一个压缩上的一个组件为例，啊，去带大家看一下腾讯内部在组的一个实践的一个经验，就可以去看到这一块。呃，这个内部这个组件在腾讯内部的话，就是我们近28天使用的一个top时的排名的一个情况，以及呢，每一个版本它的一个随着时间变化而言，它的一个趋势变化情况，那这里就不过多介绍了，重点去讲一下这个组件版本热力图，那就可以看到这个组件呢，就是他在腾讯内部我们呃对于这个组件的一个修复的一个热力图的一个情况是怎么样子的，可以看到近一年而言，它的每一个版本的一个使用情况，那颜色越深呢，表示我们对这个组件的使用的成，呃使用的一个频次是越多的，那如果说我们企业想去针对某一个具体的组件去进行修复，那刚好想去去知道业界呃最佳的一个实践方案，或者说大厂都在去用的这样的一个，呃，组件是什么，就可以通过这种方式去进行筛选和查看，因为腾讯内部几万面研发，那么我们针对某一个具体的组件的一个推优修复的话，基本上可以算作是业界的一个最佳实践，所以可以去给到企业关于组件修复上的这样的一个选型上的一个参考，那这个呢，是组件版本的一个趋势上的一个分析，然后这个高组件呢，就可以帮助我们企业。

产企业级的一个黑白名单，就比如说我们去外采一些制品的时候，呃，我们企业已经维护了这样一个清单之后，就可以通过把这些高热的呃组件去建立一个白名单，那一些不常用的一些很低频的一些啊组件信息呢，或呃就可以或者说一些漏洞的信息呢，就给他建立一黑名单，那这样的话，制品信息在进来的时候，就通过这样一些方式去进行扫描，那如果说命中的这样一个高热的组件呢，基本上可以群里没有什么问题啊，大家可以直接进来，那如果说有一些黑名单，或者说呃不怎么使用一些组件呢，就可以重点的去进行关注。

啊，以前呢，就是这些，呃，这些图啊表啊都是可以，呃都是可以导出来的，那如果说我们企业想去给以领导汇报啊，或者说呃，去汇报整体的一个企业的一个使用情况呢，都可以通过这些表和图的方式去更直观的去给领导去进行介绍，然后更多的就不进行介绍了，然后主要会有一个S报的一个高级分析，那在这一块其实更多的我想强调的就是，如果说我们再发生的像阿尔法吉劳破这样的一个漏洞的话，其实就可以通过这种方式去定位到就是哪一个哪一个团队，哪一个项目，哪一个分析项，然后在什么时间去用到的这样的一个核弹级的个漏洞，那样的话就可以速去帮我们去定位和收整个的一个风险，那这个呢，是我们的高级，那我们现在呢，是可以做到以团队项目分析项，那甚至呢，通过像漏洞的呃维度，像组的维度，甚至以擎呢相关的一些license呃分析的一些维度，可以针对呃这些不同的维度圈去做到一个自定义化的一个筛选，所以可以很方便的去帮助我们企业去呃自定义的去进行筛选一些相关项。

在汇报啊，在一些风险的筛选查看都会都会有很大的一些帮助啊，包括如果说企业有些自定的需求，也可以通过编辑表盘，然后传一些数据，然后可以自定义的去搭建整个的一个数据看板，所以呃是非常有用的这样的一个功能吧。然后呃，以上呢，就是我今天大概去分享的一个内容，因为后面还有一个呃，要去分享，所以这一块的话，我这边的分享到此结束，然后感谢大家。感谢也感谢我们陈老师带来的精彩分享，那我们线上如有疑问的同学也请您在问答区留言，讲师会在问答环节为大家答疑解惑。好了，那下面呢就有请我们今天的第二位分享嘉宾，腾讯云开发安全高级工程师林蔡勇。林老师负责腾讯云X产品研发，从零打造X代码分析引擎，在企业源码安全运营方面有丰富的经验，欢迎林老师给我们带来创新的s sat产品与最佳实践主题分享，有请。

啊啊，大家好，我是腾讯云插切壳研发工程师林蔡勇。呃，本次分享呢，主要是想向大家介绍一下我们自研的新一代SARS产品叉切，以及我们在腾讯内部是如何落地的。希望能对大家在开发安全建设方面呢，提供一些小小的帮助和参考。呃，在座的各位可能有的人对S并不了解，所以今天第一部分内容我先向大家介绍一下。我们为什么需要。呃，有专家说缺陷是天生的，漏洞是必然的。他这么说的依据是什么呢？就是数据显示，程序员每写1000行代码，就会出现一个逻辑性缺陷。

一个或多个逻辑性缺陷的组合，最终将会导致一个安全漏洞。这样呢，随着大家业务的应用不断丰富，业务复杂度越来越高，代码中的安全漏洞的话只会越来越多。呃，这是一方面，另一方面的话，国家安全法规在这一方面也是要求大家对应用安全漏洞的进行治理。像啊网络安全法等，保2.0在这方面都有明确的规定。而我们的SS工具呢，正好能够有效的发现源码中隐藏的安全漏洞，是行业内建设啊安全开发的一个主流工具之一。那到底是什么呢？S, 呃，从字面上，它是静态应用安全测试英文的首字母缩写。SS本身在定义上它是一个程序，通过分析应用的源代码，能够找出其中隐藏的安全漏洞。那市面上比较常见的SAS产品，像除了叉之外，有forty five、新代脑这些。

当然也有开源的SS工具，像could就是get up, 开源的S深受安全研究者的喜爱。那S能做什么呢？SS能够检测外B应用中主要的安全漏洞类型，像大家比较熟知的命令注入SQL注入叉叉ESS叉SS。不安全的反序列化，这些漏洞呢，都在他的知识范围内。相比其他的应用安全测试工具，主要是指对dust和A这两个工具来说，它具有覆盖度高，检出率更高，其施成本呢更低，没有应用侵入性，支持大规模扫描占的优势。那SS因为它只分析应用的源代码，所以它能够在研发阶段就可以发挥作用，这就大大降低了漏洞的修复成本。所以如果大家要建设de set UPS体系的话，是一个必不可少的工具。

那我们说叉切是新一代的S，我们为什么要打造新一代的S？这是因为传统的SAS产品五保高，速度慢，在实际的落地过程中呢，效果并不是很好啊，研发同学在使用传统S可能遇到的一些问题啊，也有一些开发，也有些研发，他比较极端，他说这个工具一点用都没有，建议下线。上周A项目被白帽子报告了一个漏洞，但是工具呢，只搞了一堆误报，真正的问题又没有找出来。呃，这些都是传统SS在实际落地的过程中经常遇到的问题。呃，总的来说。有几方面误报高速度慢，问题描述不清，报告的问题太多，而检出能力呢，又不是很行。那插切可作为新一代的萨斯克，表现又如何呢？沙切克致力于检测web应用中的实锤漏洞，在各个核心指标上相比传统的SS具有明显的优势。

呃，从误报率和扫描速度这两个指标来看，切的误报率呢，可以控制在10%以内，远低于竞品，而扫描速度能够达到每秒5000行，是同类产品的10倍以上。除了这两个量化的指标，我们在自动推理能力和可扩展性上也表现出明显的优势。那么我们是怎么做到的呢？啊，我将其总结为四个最重要的方面。首先，我认为我们采用了更加实用的程序分析技术，通过全局模拟执行算法，更准确的把握代码细节，实现了更强的、更适合于web漏洞检测的自动推理能力。其次呢，我们通过认知的革新，推翻了传统SaaS对漏洞和误报的错误定义，并且以低误报为第一设计原则来设计我们的分析策略。

带着我们通过设算法设计和工程的优化，实现了分析速度的啊极致性。最后我们首创性的使用过程式语言来编写自定义规则，通过hook我们的推理过程呢，可以实现非常强大的扩展性。在这四个方面，我认为自动推理能力是最重要的。因为自动推理能力是SS的基石，是影响工具精准率和召回率的一个决定性因素。工具在自动推理阶段犯下的错误是很难通过上层的策略来弥补的。那大家常常忽略底层的分析能力，在上层做一些漏报的策略，这是一些无谓的努力啊，因此往往呢，陷入一种双重困境。就是说当它降低误报的时候，就会导致更多的漏报，降低漏报呢，可能就会导致更多的误报。那传统的SS往往采用具有成熟理论体系支撑的程序分析技术，像大家比较熟悉的控制流分析、数据流分析、指针分析、抽象解释、切片分析等等，这类技术一般是通过对程序进行抽象。

通过对抽象模型的啊把握，间接的去理解程序行为，他们理论上具有完备的证明和精致的算法。那受主流SARS的影响，我们在啊设计插切的时候，理应也应该选择这类技术，但是我们偏偏选择了模拟执行，因为我们发现从实用主义的角度出发，模拟执行更加适合web漏洞检测的场景。那模拟执行技术是什么呢？简单来说，就是通过模拟程序运行过程来分析程序的行为。举一个例子啊，一个真实的web应用，它在启动的时候，首先他会注册各个API对应的处理函数，当他在接收到用户的请求的时候，他就会根据请求的URL路径呢，找到一个对应的API函数。

啊，通过调用这个API函数实现业务逻辑的处理，最终返回数据。模拟执行就是对这个过程的一个模拟。查切首先会解析，然后代码得到AST，在AST基础上呢，去提取应用程序中所有的API函数。模拟执行的时候是不会有真实的请求的，所以我们就需要通过构造HTP请求来模拟调用这些API函数来执行。当然所有的API函数的代码逻辑都跑完之后呢，他切可能就会输出这个过程中所发现的漏洞。OK, 那模拟执行技术的优势是什么呢？我们发现模拟执行技术能够非常容易且自然的理解啊程序中复杂的一些语言特性，对程序的一些代码细节也有更准确的把握。通过优化插切可达到了与啊传统SS类似的推理能力，包括理解语句的顺序、分支控制语句以及复杂的函数调用全局变量等等。

以及字段、敏感过程、跨文件，这些也是非常自然能够实现的。那最重要的是通过模拟执行呢，还实现了一些传统萨很难去支持的特性，比如说叉可以支持具体值的推理，可以支持一些动态的复杂特性的支持。呃，典型的像Java里面的反射之类的一些特性呢，啊，查切也能够支持的非常好，这往往是一些传统萨没办法去做的一些事情。OK, 有了这种推理能力的基础之后，我们首先来解决啊，传统SAS最重要的一个问题就是它的误报问题。这里我展示了啊某S报告的问题结果，我们可以看重点看一下其中高亮的部分，像一些创建string对象变量和方法，同名循环中拼接的字符串，忽略返回值。

像一些未使用的值啊，字段方法未处理的错误，以及一些空的代码块之类的问题。那么我们从名字上其实就能看出，这些问题其实很难独立的造成实际的安全漏洞。那。也可以想象，为什么开发就不愿意去修复这样的问题。呃，那回过头来问，为什么传统要报告这样的漏洞呢？根本原因是他们对漏洞的过于宽泛的定义，他们将漏洞定义为由于编码错误导致的安全缺陷。一般的web漏洞都可以。呃，归属于输入验证和表示的一个问题，以及安全特性这两个类别，这是我们可以理解的。但是传统SaaS工具报告最多的问题类型确实像API滥用啊，错误代码量分装等类型的问题，也就是左边这个问题列表里面体现的那样。

啊，我认为从实用主义出发，传统对漏洞的定义是不准确的，因为他们报告的问题从结果上。在实际过程中是很难推动开发去修复的。那我的主张是漏洞，定义应该是这样，SARS工具应该只报告。能实际被攻击者利用、开发、认可并愿意修复的安全问题。由此，我们明确误报的定义以及误报率的计算公式。这里值得一提的就是在呃实验室环境下呢，因为样本样本的漏洞是已知的，因此可以通过啊报告的问题数减去漏洞数得到误报，进而得出误报率，那么在实际的运营过程中，其实啊企业项目里面的漏洞数未知的，那这个时候我们就可以通过近似的算法去计算误报率啊。

就是以开发忽略的问题数作为误报，那分母呢，就是忽略和已修复之后。基于这个新的定义，我们去拿5个啊有漏洞的实际项目，重新评估某S传统的SS的工具误报率。结果表明呢，这个SS。它的误报率高达85%，这个数字看起来很夸张，是符合我们的直观感受的，这也从侧面证明了我们对漏洞的定义是准确的。那叉切的设计目标呢？是指报告实谁的漏洞，因此我们采用了非常严格的污点分析策略。所谓污点策略，简单来说就是判断恶意攻击者能够篡改哪些数据。通过5点分析呢工具能够识别出代码中的web安全漏洞。传统它为了提高召回率，往往采用非常宽松的污点策略啊，具体体表现在他们把污点来源定义为所有的应用外部数据。

啊，向HTP请求。环境变量、命令行参数。这些。但实际上呢，攻击者很难篡改出了HTP请求以外的其他数据，这也是传统SaaS出现误报的重要原因。举例来说啊，外部攻击者几乎不可能篡改web服务器上的环境变量，除非已经有其他的安全漏洞了。类似的问题也出现在污点传播策略上，当函数是，当函数是未知的时候，传统SAS呢倾向于传播污点，也就是说当它的参数是污点的时候。就认为它的返回值也是5点，这往往呢也会带来非常多的误报。呃，基于这个观察，以及我们以低误报为第一原则，我们调整了污污点的一个策略。呃，首先插这个，认为污点只能来自于HTP请求，第二，只有明确定义的污点函数才能传播污点。啊，值得一提的其他策略是，我们认为污点必须是字符串类型的变量，因此，当变量类型被推理为整型或浮点型之类的类型时，我们就不认为它是污点了。

另外，我们通过直推理可以有效的降低误报率，比如说当工具即将报告一个SS或者是任意UUR跳转的漏洞的时候啊，我们的插线可会进一步的判断恶意攻击者是否能够控制URL的域名部分。从而进一步的降低误报率。那除了误包之外，速度也是传统只为大家诟病的问题，前面提到叉切的速度是竞品的10倍以上，我们是如何实现的呢？这个问题其实很难简单的回答，因此我们呃，笼统的从技术方案和工程优化两方面简单的简单的分析一下。在整体方案上呢，传统一般是三阶段的，第一阶段解析代码得到中间表示，第二阶段呢，做程序分析，通过抽象模型去理解程序的行为，那这个阶段输出一般是代码的啊，属性图或者是程序的属性数据库。

在第3阶段呢，工具根据规则去进行污点追踪和模式匹配，最终得到呃漏洞结果。在这3个阶段中，程序分析和模。模式匹配的耗时是最为可观的。模式匹配可以看成在巨大的图中做一个可达性分析，类似于对图的深度优先搜索、广度优先搜索。因此匹配的复杂度往往和规则的数量，规则的啊代码的模型。规模、复杂度成正比。而插切可从整体方案上来看，是两阶段的。区别在于插切的污点追踪和模式匹配是内嵌于啊模拟执行过程的，更具体而言，就是在模拟执行的过程中按需的进行污点追踪和模式匹配。因此在叉切的方案中，既没有全局的程序数据表示，也没有复杂的一个搜索过程。

因此，从理论上叉的方案是可以做到比较低的分析开销的。当然啊，在实际落地的过程，实际实现的过程中，也需要投入大量的工程优化工作。呃，工程优化也是决定工具分析速度的重要原因，这里举一个啊，语法解析阶段的速度优化的例子，我们自研了一个专用的语法解析器，来实现更快的解析速度。那这个解析器的特点是支持啊十几种语言，各语言它是统一接口和结构的。另外它是无需编译的。因此它的使用成本非常低的。另外，它的技术是用p pging的技术，所以它能够通过解析代码直接生成AST。另外，它可以支持多版本语言语法的一个混合模模模糊与解析。等等。通过这样子的一个工程优化，我们也是可以去提升我们的分析速度。

啊，讲完误报速度呢，我们再来说说可扩展性啊，我认为可扩展性是最被大家低估的一个SS的特性的可扩展性我认为是非常重要的。一般来说，SS是不分析第三方库的，即使要分析呢，也是因为第三也因为第三方库过于复杂而无法准确的理解，缺乏第三方库的知识的话啊，S就无法准确理解使用了第三方库API的业务代码。那这是第一方面，另一方面呢？呃，不同企业之间它的技术站是差异非常大的，而且技术站是随着时间不断演进变化的，因此仅仅依靠萨厂商在出厂的时候就内置规则来适配是不现实的。呃，虽然传统SS一般都提供自定义规则来实现扩展，但普遍存在啊扩展困难的问题，我将其归纳为两个方面，一方面是不够强，一方面是不好用。

不够强，是因为他们的规则一般用于扩展刚刚所说的第三阶段。也就是用来提供更多的模式或定义误点信息。这样的问题在于，用户没有办法通过自定义规则去弥补推理过程中产生的偏差。另外，他们一般要求用户使用配置语言或者是声明式的语言去写规则。啊，这主要去主要是能够。处理一些预定义的场景，或者是逻辑性比较强的一些场景，但是这样子是很难处理程序中的一些代码细节的。而传统的SAS扩展不好用体现在多个方面，向它使用成本高、调试困难、文档不足、厂商支持不足这几个方面。那我们插切呢？把工具的可扩展性放在非常重要的位置，我们认我们设计了一套类似javascript的编程语言。

呃，用户呢？可以通过调用分析器的API去工具模拟执行的过程，从而实现推理能力的优化和漏洞模式的补充。另外，为了降低学习的和使用的成本，我们配套了专用的自定义规则playground playground是一个独立的一个在线应用，我们在其中集成了非常详细的参考手册以及丰富的案例库，支持啊大家实时的调试我们的规则，并查看啊分析的结果。最后，在售前售后的整个阶段，我们都是提供免费的呃，自定义规则的培训和答疑，帮助客户更高效、更准确的编写自定义规则。啊，这是插自定义规则playground的一个示意，它类似于一个本地的一个IDE。呃，页界面。那叉切可不仅仅是一个呃代码分析工具，它还是一个成熟的SaaS产品。

这是叉切可产品的架构示意图。插切可产品以插切平台为核心，在平台之上，用户可以体验到完整的代码分析功能，包括各类资源的管理，创建任务和和项目，进行代码分析，查看缺陷的结果啊审计或者是分享我们的结果，数据统计分析以及通知告警等等。那除此以外，插件可提供非常丰富的API和插件，能够很方便的与企业内各类现有的平台来进行对接，像develops平台、代码平台、身份认证系统、缺陷跟踪系统等等。在提供分析能力的呃引擎层，这里叉切可做了双引擎设计，其中叉切可就是前面所说的新一代的SAS查切可专注于web应用的漏洞是和dev boxs、流水线或者是大规模的治理，那作为补充，我们打造了一款对标传统SAS的规则匹配引擎，代号为叉breaker。

那叉GR的特点是语言覆盖度高，规则丰富，适合于呃，传统SaaS的一个替代的一个场景。那因为插线的产品功能完备，易于集成，漏洞分析能力强呢，也是通过了新通院的陈述对认证。大家可以在各一各种研发和运营的场景中去使用插切口产品，帮助企业有效的并且低成本的实现源码漏洞治理的目标。呃，最后一部分我讲一下他切可是如何在腾讯内部落地的。在腾讯内部呢，我们已经全面的落地了查并得，并且取得了非常亮眼的漏洞治理效果。根据我们的经验，全盘扫描和流水线门禁是两种最行之有效的落地方式。全盘扫描是指安全运营，运营部门发起，可以覆盖全公司的代码。

落地成本呢，相对是比较低的，那流水线门禁方式需要研发同学去配合，在日常的流水线上去配置插切扫描。这样子帮助业务在研发阶段就可以发现漏洞，降低漏洞修复成本。针对两种方式，我具体介绍一下落地过程中的一些啊建议。这是全盘扫描方案的一个简单示意，由安全同学发起全局的扫描，然后代码分析，平台呢从代码仓库拉取代码并调用插可进行分析，分析完成之后，平台将数据写入数据库，安全同学啊在其有必要的时候，通过查询得到业务漏洞信息，并通过已有的安全工单，平台呢通知开发进行修复。那当然最后最重要的环节就是开发去修复代码，把修复的代码提交到代码仓库里。在这个过程中，工具的误报可能是不可避免的，那如果开发同学不认可工具所报告的问题呢？开发同学也可以在工单系统上进行驳回，安全同学审核之后可以在的平台上进行简单的审计屏蔽，或者是编写自定义规则进行。

啊，针对性的适配，这样切可就不会在这个项目中报告同样同样的问题了。那针对能能启动的阶段，我们是有如下的建议，首先建议做一次工具误报率的摸底，做到心里有数，如果误报率过高的话，可以通过啊自定义规则去适配，在误报率满意之后，我们可以启动推，但这个时候们建议是做一些灰度的验证。比如说我们可以按漏洞类型进行分批的推，先处理比较有把握的漏洞。如果大家觉得通过工单系统来推动研发去修复过于强硬的话。呃，我们也有个建议，就是可以通过建立代码分的看板，通过评比和晾晒的方式提高大家的重视程度。

当然，漏洞的责任人判定也是非常重要的，这关系到漏洞推销的一个效率问题，因此大家需要根据自己公司的实际情况做仔细的啊判定逻辑设计。最后，在冷启动阶段要考虑的一个问题就是一般工单系统是有时效性的设计的，如果在开发修复漏洞的过程中需要帮助的话，最好我们是能够快速帮帮，快速响应去帮助的。因此，我们建议是设置一个专用的客服号，多人轮流值班。那么到了日常化运营的阶段，我们是有以下建议，日常化运营，我们可以设置每日扫描，针对当天活跃的代码仓库进行批量分析。那在这个阶段，安全部门可以整理一份安全SDK以及官方的修复建议，以便提升修的一个效率，当然对应的啊，我们工具也可以通，也可以对应着官方的修复建议去写。

对应的规则，从而去理解啊是如何修复的，这样可以大大的降低工具的误报率。最后，呃，工具的log务包运营，它应该是一个长期且重要的工作，核心是通过从各个渠道收集而来的log务报呢，去提炼规则，编写规则，去提升整体方案的一个有效性。啊，全盘扫描之外，流水线门禁也是行之有效的一个。呃，落地方案，一般来说，研发同学需要在日常构建的流水线上配置查。这样后续所有同学在这个项目中提交代码的，都会触发流水线去做安全检查，一旦有新增的安全漏洞，流水线门禁就会生效，阻断流水线继续执行。呃，只有开发进行了修复之后，流水线才能够进行，呃，正常的。

运行下去，那整个过程中是无需安全同学介入的，也完美的体现了setups的一个实践理念。针对流水线的门禁呢，我们建议安全同学可以联合质量的QA部门制定安全研发的一个规范，并且通过宣传和培训。让大家去试用。在项目初期，可以通过业务试点、树立标杆的方式，推动这个项目的一个更大范围的落地。另外，也可以在产品交付上线标准上增加对应的标准，对应的要求，比如说腾讯，腾讯云的产品交付是必须啊，要通过插切扫描的。必须提供一个切克的通过报告，那像全盘扫描一样，客服号也是非常重要的。包括像问题解释，修复建议，误报处理等等，也需要啊，有一个实时的一个响应。

OK, 以上就是今天分享的所有内容，谢谢大家。嗯，好的，感谢，感谢我们林老师带来的精彩分享，也再次谢谢我们今天两位老师精彩分享，那下面呢，我们就进入今天的课研的环节，我们有请两位老师啊来回答我们线上观众的问题，嗯，好了，那首先呢，我们来看第一个问题啊，观众朋友们问到如果有效的识别SCA，发现并且有啊，并且有必要修复的安全漏洞呢？那这个问题老师。嗯，好嘞，主持人，呃，这个问题呢，就是我在产品演示的时候，当时也提到了，就是我们在像漏洞可察性，包括像漏洞一些标签，就是我们其实也会去发现有些企业在检出一些漏洞之后，不知道如何去给漏洞去定级，就是一些修复的优优先级嘛，就我们也会去帮助企业去更好的去帮助他们去进行漏洞修会先级的一些定位，就我们，所以我们去做了像漏洞可达性，那在这个里面就会涉及到像漏洞的存在性啊，包括漏洞的触发性，那一般来说我们建议的方式是，如果说呃是有漏洞呃可达性的这个里面的一个触发性和存在性的话，那这个是最高优先级去进行修复的，那除此之外，先级去进行修复的方，就是我们会有这样的一个漏洞的一个标签，比如说像PC，还有我们打上一些重一个标签，那这些标呢，基本上也都是我们去根据一些漏洞的一些特征，包括一些呃，官方发布一些漏洞的情况，去打上这样一些标签的，那第三块需要去进行修复的话，就是我们会去。

针对这个漏洞，呃，因为它会有一些风险等级嘛，就比如说严重啊，高危啊，中微这样的一风险等级，所以我们一般会建议像高危和超微的这样漏洞是也是需要去进行修复的，然后剩下的一些漏洞的话，基本上就看企业这边的一个实际的一个人和经济的情况，因为剩下漏洞其实修复优先级就没有那么高，但是也建议去进行修复，但修复的优先级就会稍微低一点。

对，是这个样子。好的，谢谢。我们来看观众的第二个问题，在使用scan扫描的过程中，是自动根据开发语言的依赖包文件进行检查呢？还是需要先编译成功才能扫描？嗯呃，这个扫好的好的没问题，就是这个扫描的话，其实它其实是一个呃比较通用性的，其实它并不是说一定要需要去研发或者企业这边去做一定的手段去就呃才能够去进行扫描，就是因为我们其实分了两个大模块嘛，一个是源码，一个是制品，那源码的话更多的就是在代码编辑阶段去进行扫描的这样的一个方式，那制品的话就是已经打包好成的这样的一个制品，或者说你通过流水线构建的方式，就可以去引用这个插件啊，自动化的去进行扫描，所以它不用说你一定要去啊，编译成功之后才能去去进行扫描，它只不过是不同的阶段，因为我们有源码阶段和制阶段两种方式去进行扫描和集成。好的，感谢，嗯，下面一个问题，观众朋友问到SCA里面是否集成了IDE呢？

是I idea里面的，那包括呃，像我们的刚才平台集成里面，其实讲到平台也集成的一些扫描的方式，那这个的话更多是通过这个平台直接去进行操作，那其实我们跟一些客户交流下来，大家用的比较多的，更多的就是像一些插件的方式，比如说像集成的呃ID啊，包括像一些呃的一些平台啊，包括像加va蓝啊，像coding这样一些平台，或者呢，就是通过一些API的一些方式直接去呃这呃呃一些链接啊，包括一些的方式去连接到这个平台里面去进行分析，都是很方便的，所以在集成的扫描这一块，目前是没有任何的一些困难在这个里面。好的明来了，嗯，观众问到有没有和black dog对比过有哪一些优势呢？慈文老师，嗯，好嘞，就是black，其实这个呃就是了解应该都比较是就是一比较样的一个工，那为什么说我们要去做I，呃，我们这边也进行比对过相关的一些能力，那我们相比的话，那第一点就是我们的二进制的分析能力，包括像源码片段分析能力，这一块是要比black大要更有优势的，那源码呃，像二进制这一块，其实也是国内这一块大家会很关注一个能力，因为更多的会涉及到一些制品，包括像一些外采的一些三方软件，这里面其实更多的就是用到的就是二进制的一些能力，那在这一块我们是肯定要是要优于black的，那第二块呢，就是我想说的就是black这样的一个核心能力，核心引擎和核心数据，其实是你很难去有一个。

自己的这样一个管控手段的，那在当前的这样一个呃大背景之下，其实大家都在做这样一个国产化替换，包括整个的一个核心数据的一个可控，那所以呢，我们接下来也会有一些企业会去呃去莱大，就是国呃莱虽然用的好，但是因为毕竟它不是国产的，那国产的能力已经接近莱大，甚至在某一方面已经超越，所以完全可以通过一些产化的一些方式，就比如说我们这I就可以去替，去帮助去更好的去发现风，那第三块呢，就是更多的是涉及到其中的一些啊，我们说是数据啊，漏洞数据，那这一块更多是通过维护的，像N一些就是国外的这样一些漏洞库的一些数据在这个里面，那科恩这一块，我们不仅会收入国内外的一些知名的漏洞库数据，包括我们腾讯这边自己自身去维护的漏洞数据，我们都有对接，所以基本上我们的漏洞数据的话，呃，在国内肯定是最全面和数据质量最高效的，这样那放眼到国际上，基本上也能够去覆盖国呃国际。

上就知名的这样一些漏洞库数据，基本上数据这一块也是没有任何问题的，对，然后大概是这样的一个情况，包括还有一些细的呃情况，包括像我们对接到我们内部的这样一些平台，包括国产化系统，一些适配，那在这一块我们自呃自家的产品可能都是有更好的一些优势的。

好的，谢谢，嗯，观众朋友们问，呃，问到安全台账是怎么建立的，是否是人工建立的呢？子文老师。嗯，好的，安全台账的话，其实也是业非常关注的一个点，因为之前像发生漏洞，包括发生呃这样的一个open sh的源组风险漏洞之实，大家都比较，因为呃有点，第一点就是企要没有这个台账，没有台账实难去定位，如果说发生这个漏洞风险之后，我哪些呃团队哪些项目，哪些分析项去用到的这样一个主信息，那第二点呢，就是我有这样的一个台账，但是我很难去呃通过一些风险定位的方式去知道到底哪个同队去使用的，对为我们这样一个台账定义的一个方式，呃就是我们会通过软件，就是扫描完之后，它会自动的把这个台账去集成到S的这样一个管控的一个呃模块当中，就是你所有的分析商里，连生成的一些呃S台账信息都会自动化的去集到这个台账当中，相当于它不是一个人工的一个手段，那人工在这里面更多的方式是去维护这个S台账，包括我们会对这个S台账去进行呃定期的。

就比如说再发生了一些呃核弹这些漏洞，那么我们就会去快速的去响应，在这个里面去打上一些风险提示的标签，那这样的话就可以帮助我们人工快速的去定位到到底哪一个团队，哪个项目，哪个分析项去用到的这样的一个组件的可能会存在一些风险，嗯，好，谢谢主持人，谢谢啊慈老师的最后一个问题，请问license合规风险要怎么处理呢？嗯，好嘞，就是呃，License合规的话，其实会存在一个问题，因为有些企业也会经常去问到这一点嘛，就是更多的其实我们针对于lesson的合规，每一家企业，或者说每一家，嗯就是嗯，在这一块会有规范性的企业都会有一个自己的这样一个法务团队，就是在这一块更多的是我们IC工具做的就是帮助企业去检测出其中所包含的一些license，但具体如果说要针对这个license去进行处理的话，是需要企业这边自己的法团队或者说研发人员去进行自己去分析判断的，因为我们很难去给到你们这样的一个关于license合规的一个风险的一个处置建议。就比如。

说这个license里面，它要求你这个产品不能商业化，那其实我们就很难去知道你这个产品到底有没有商业化，只有你自己才清楚，我这个呃，就是这个呃，License要求的这个商业化我有没有满足，所以一般来说我们只会去分析这个license的一个呃风险情况，就给他打上一些监控性的标签，或者是license本身的一个就相关风险的标签，从而去给到你们法务团队一个相关的一些建议，在这个里面对对于license风险的一些处置的话，还是需要企业自身的法团队以及相关的研发运营人员综合去进行研判。嗯，以上是这个情况。好的，感谢感谢老师的精彩回答，那接下来我们看看观众的，呃，下面的问题是问到，呃，我如果使用叉check发现新的漏洞模式以后，如何定制的配置或者规则进行扫描去发现新模式的漏洞呢？这个问题请蔡勇老师来帮我们回答一下。

啊，好的，这个问题呢，他是说已经知道了漏洞的一个新的模式，那么我就假设这个模式的定义是准确的，而且是通用的，那么在这个基础之上，我们可以在我们配套的插自定义规则playground上去做啊调试在playground的左边呢，我们会有应用代码，右边是一个规则啊，我们可以通过实时的运行去看一下我们的规则是不是符合我们定义的。啊，我们的目标的看一下是不是也能够扫出我们符合这个模式的问题。然后一切都匹配，一切都调试完毕之后呢，我们可以在这个平台上去做配置生效，生效的话我们可以全局生效，也可以针对项目生效，是这样子的一个基本的过程。

好的，嗯，请问逻辑漏洞如何模拟执行呢？呃，逻辑这个问题我理解成逻辑漏洞我们是不是支持啊，那逻辑漏洞是不是支持，其实是这样的，因为我们对逻辑漏洞其实是没有一个通用的模式定义的，在行业内缺少这样一个定义，那大家说到逻辑漏洞其实都是针对特别啊。具体的情况下的某种逻辑的。逻辑的一个问题，那如果大家对于自己的生产环境有一个非常明确的漏洞模式，它是啊，属于逻辑漏洞的。因为它的模式是准确而且通用的，那就可以写规则，比如说啊，一种简单的逻辑漏洞，它是可以通过检查我的。呃，接口函数里面是不是调用了某某权限用的API，如果没有调用这个权限用的API呢？它就可能出现越权的问题。

类似这样的一个模式，如果是啊，可以通过我们的just tiny JS语言去写的话，就是可以实现的。好的啊，下一个问题，观众朋友们想了解叉叉的模拟执行就是符号执行流派吗？动态复杂语言特性支持是采用什么技术解决的？嗯，蔡老师。嗯。呃，符号执行据我据我理解呢，它是更严格的，它是更加路径敏感的一个，呃，实现算法目前的话它还不够成熟去用做生产环境的漏洞发现，那插切口的模拟执行更多是从实用主义出发去。去类似实现了一个语言的解释器这样子的方式去做的，那个语言的动态复杂特性是怎么支持的？那因为插切可实现的是一个语言的解释器，比如说Java，我们其实就完全像啊Java。

只要把虚拟机一样去实现了一个完整的解释器，那Python呢，也像c Python一样去实现了一个完整的Python解释器，那么既然官方的解释器能够去理解动态复杂特性，那么插可也通过啊模拟的方式也能够理解是这样一种情况。好嘞，我们看下面一个问题，叉的统一多语言语法解析器和安相比最大的区别是什么是？呃。像an tr或者是特，据我了解它的主要的设计目的，它可能并不是为了做像我们这样子的代码语义分析而设计的特别像去，它是为了我们的。

ID编辑的，就代码编辑器这样一个场景去设计的，所以它目的和我们插接可的语法解析器目的不一样，那我它的技术路线可能也是不一样的，据我了解，An tr和去它都采用自己向上的呃，解析技术，那叉切可使用的PEG passing的技术呢，它其实是自顶向下的。更容易去做调试和啊语法文法文件的一个扩展。因此技术的路线是不一样的，另外他们的直接产出也是不一样的，像叉切，可它是为了呃程序分析服务的，所以它直接生成T，那像an tr或呢，它生成的是啊pass或者说是CST，就是具体的语法数，它包含了更多的一些。嗯，像控制符号，左括号，右括号，逗号，分号这些在对于我们语义分析没有用的一些信息，那这是我想到的一些最大的区别吧。

好的，谢谢，那我们看看今天的最后一个问题啊，PEG passing啊，Tiny GS SST有什么相关技术原理的书籍可以推荐一下吗？蔡勇老师，呃，我逐个讲一下吧。呃，PG passzzon呢是我之前是读了那个Python之父，就那个极多，他写了一个系列的博客，就是讲Python是在3.8的时候引入了PG passing嘛，所以他因此写了一个博客介绍这个技术是怎么去用的，大家也可以去网上搜一下，就搜啊Python之pgzzon就能够找到。对应的一个博客，那JS的话其实就是一个简化的javascript语言，所以大家如果对javascript熟悉的话，是不需要学习的，那萨这一块，其实传统理论这一块我也不是特别的掌握的不是很熟练，那大家如果要推荐的话，那还是推荐南大的啊系列的软件分析教程吧。

就是这样。好的好的，非常感谢两位老师的啊精彩分享，那我们今天的问答环节就到这结束了啊，也再次感谢各位观众朋友们啊，对我们的参与和关注，时间过得非常快啊，我们的课程进入到了尾声，感谢两位老师，感谢所有的观众们，我们下次课程再见。