从RSA创新沙盒决赛产品ShiftLeft浅谈DevSecOps

一、背景

RSA大会将于3月4日在美国旧金山开幕，RSA创新沙盒决赛十强产品都是网络安全领域的创新者，同时也从一定程度上代表着国际网络安全各个细分领域的火爆程度。

从今年的十强产品看，数据安全、云计算安全连续多年上榜，持续火热，业务安全和DevSecOps崭露头角，这也意味着未来1-3年的安全创新方向。

十强产品中ShiftLeft聚焦于DevSecOps，DevSecOps虽说各有各的玩法，暂未形成大家公认的标准，但是基本上都是SAST,DAST等产品，当然也包括最近火起来的IAST和RASP，接下来一起看看ShiftLeft，聊聊DevSecOps。

二、ShiftLeft为何能进决赛

ShiftLeft有三款产品Inspect、Protect、Ocular。

ShiftLeft的主打产品无疑是ShiftLeft inspect，一款漏洞检测产品，inspect将SAST和IAST融合到一个产品里，跟DevOps工具链进行集成，作为上线前的漏洞检测方案。

2.1 SAST部分

传统的SAST类产品作为编码阶段的安全工具，其实很多国外知名的白盒厂商都为它们的产品配备了集成Jenkins和Gitlab的手段，但是在DevSecOps中一般难以有特别好的效果，主要受限于SAST类产品的误报率和检测时长。DevOps中很重要的一点就是“天下武功，唯快不破”，强调一体化，自动化与速度，Jenkins、Gitlab等DevOps工具链的集成从一定程度上解决了一体化和自动化的问题，但是问题终回归到SAST类产品的核心竞争力：检出率、误报率、检测速度上，这些决定了安全活动的周期，也决定DevSecOps能否很好的执行和落地。

我们先看看OWASP对SAST和DAST类产品在OWASP Benchmark的测试结果：

SAST类产品可以做到检出率高达85%，但同时误报率也有 52% ，误报也就意味着需要介入人工核查，而且众所周知，代码审计工作所需要的周期偏长，特别是从数百数千个漏洞中，找出误报，意味着每个漏洞都要审查，会极大的拖慢DevOps周期。那如果说开发同学不管是否误报全部修复，这样是否可行呢？这就牵扯到开发人员与安全人员配合的问题，本身可能大部分开发人员对安全工作存在少部分的抵触心理，认为是工作量的增加，如果修复方案简单还好说，如果某个漏洞的修复比较复杂，又被发现是误报，可能开发与安全的信任关系断裂，不利于后续安全工作的开展。

那ShiftLeft是如何解决上述难题的呢？答案是：强行解决！

先看ShiftLeft 自己发布的ShiftLeft inspect在OWASP Benchmark的测试结果：

检出率100%，误报率25%，最终得分75，几乎是第二名的两倍。（当然，结果是ShiftLeft自己发布的，也可能针对OWASP Benchmark做过特殊优化），这个得分可以很大程度上可以解决SAST在DevSecOps中难以应用的问题。

再谈到速度，用过白盒产品的同学应该都知道，传统SAST类产品检测速度偏慢，收到过客户的真实反馈，100w行代码足足检测了10个小时，这个时间在DevOps中是难以忍受的。ShiftLeft inspect根据官网放出的数据，50w行代码检测时间10分钟。有这两项优势，决定了ShiftLeft inspect的SAST模块在DevSecOps中足以站住脚。

ShiftLeft inspect是如何做的呢？这个涉及到SAST类产品的技术底层，ShiftLeft也很聪明，放数据别人可能觉得它在吹牛，所以也深浅有度的介绍了下用的底层原理，这里也给大家简单介绍下，这要从自动化代码审计的技术实践说起。

安全产品要做到独一无二，笔者认为粗略可分为两种壁垒：技术壁垒和客户壁垒，技术壁垒即使技术难度，技术创新和最终效果，客户壁垒从产品层来讲即是对客户需求的满足度，包括是否满足行业、客户的特点等。SAST类产品的技术门槛，在笔者看来应该是SAST、DAST、IAST中最高的，做好了拥有较高的技术壁垒，所以这也是为什么知名厂商的白盒产品贵的吓人，客户还不得不买。

很多没研究过白盒 工具 的同学对自动化代码审计的印象可能仅存在于采用正则匹配的方法，这是最好理解的，也是效果最差的，SAST类工具的技术实践大致可分为以下几种：

（1） 正则匹配：代表工具cobra，raptor；

（2） 基于语法树:代表工具p3c,fireline；

（3） java语言可基于class文件:代表工具findsecbugs；

（4） 基于控制流、数据流、函数调用关系等:市面上的商业级SAST类产品。

当然，效果是逐渐递增的，难度也是逐渐增大的，篇幅有限，这里简单介绍基于控制流和数据流的商业级产品的大致技术思路。

要实现还原代码的数据流、控制流和函数调用关系，需要将编译中的前端模块完全实现一遍，基于中间代码去还原数据流和控制流等，大致流程如下：

每个阶段的具体实现大家可自行查看编译原理相关的知识，这里不展开讲，其中词法分析和语法分析一般可以借鉴相应的开源工具可以完成，但是语义分析依赖于各种语言的语法，针对每种语言一般需要单独实现，不同的语言翻译成同一套规范的中间代码，根据翻译来的中间代码，符号表等来恢复数据流、控制流和函数调用关系等，然后根据这些流来确定污点传播过程，进而确认是否存在漏洞。

白盒类产品误报率高和耗时长的原因也跟这个复杂流程相关，各个安全厂商自己基于编译原理相关内容实现的代码分析模块，还原的数据流、控制流等难以做到100%准确，同时对100w行这种大量的代码分析，资源占用大，复杂度较高，数据流、控制流的构建过程自然就耗时长，导致了SAST类产品误报率高和耗时长这两个问题难以解决。

回到正题，ShiftLeft是如何解决这个问题？ShiftLeft inspect一直在强调CPG（代码属性图）这个概念。

CPG可以看做丰富版的AST（抽象语法树），利用了一个基于island grammar的，直接从源码抽取AST的分析器，抽取AST可以只做到语法分析步骤，执行速度很快，而通常耗时的部分是在中间代码和数据流、控制流还原等，然后对AST做针对漏洞检测所需特征的自定义优化来生成CPG，然后基于CPG去做漏洞检测。单纯的基于AST检测能力有限，关键点在于从AST到CPG的过程，决定了最终漏洞的检测效果，当然，ShiftLeft也没说,下图是CPG分析某段代码出来的结果：

基于CPG检测漏洞在可视化方面，除了调用过程，还可以展示出代码层次深度结构，ShiftLeft把可视化也做到不错，用3D展示出来。

ShiftLeft还专门为CPG的生成做了一个工具，ShiftLeft Ocular 一个命令行生成CPG的工具，用于代码查找，漏洞排查等等。

2.2 IAST部分

IAST是最近比较火的一个概念，IAST有着一些明显的优势，比如：近实时检测、误报率极低、可定位到代码行数、展示污点调用过程等等，非常适用于DevSecOps流程，ShiftLeft inspect中也包含了IAST部分。

其中的Microagent即是做IAST漏洞检测的模块，当然，ShiftLeft换了个名字，叫做SPR（运行时安全检测），本质上是一样的。

IAST其实还比较难做出差异性，都知道它的优点，产品中也会尽力体现污点调用过程，代码行数等不同于DAST的，偏代码层的信息，ShiftLeft inspect不仅仅有这些，而且看清楚了现在的安全热点，特地在数据安全部分下了功夫。

用NLP和ML相关的技术，通过IAST获取的数据传输流，执行点等，辨别哪些是敏感数据，对于敏感数据的一些打印、输出等操作进行告警，这个点比较有新意。

2.3 RASP模块

ShiftLeft protect是一款RASP类产品，一般做IAST的厂商都会做RASP，因为技术底层都差不多，稍微改一改就是另一个产品，ShiftLeft protect同样也把数据泄露的告警作为一个重要功能。

有些厂商在宣传中把RASP跟WAF对比，笔者认为这是比较不明智的，WAF发展到现在，在机器学习的加持下，误报率，检测率，对业务的影响度已经做的非常优秀，RASP虽然效果也不错，但对业务的影响个人认为要高于WAF。

ShiftLeft protect是怎么宣传RASP的呢？众所周知，很多企业在上线前进行漏洞检测，都要求解决高中危漏洞，在业务紧急上线的情况下，低危漏洞往往可以选择性的忽略，一般会经过评审，各个负责人签字等流程，DevSecOps因为强调速度，这种情况则更多，但是作为一个安全人员或者项目经理，忽略这些低危漏洞真的放心吗？攻击者可能不会通过这些低危漏洞来直接攻击业务，但是往往成为攻击链中的一环，获取某些敏感信息等，那RASP的作用就是在Ops阶段，继续针对性的保护那些被忽略的低危漏洞。

ShiftLeft protect对RASP在DevSecOps中的定义切中要害，而且跟DevSecOps十分契合！

综上，ShiftLeft入选RSA创新沙盒10强是在产品核心产品竞争力不输竞品的情况下，将SAST、IAST、RASP集成到DevOps工具链中，解决了SAST产品的痛点，创新的加入数据泄露检测，形成编码，测试，运行阶段的产品解决方案，得以入选RSA创新沙盒10强。

笔者所在的安全厂商默安科技，也在DevSecOps方面做了诸多努力和实践，其自主研发的雳鉴软件开发全流程安全框架的很多理念跟ShiftLeft不谋而合，通过SAST、IAST、DAST类产品与GIT、SVN、Jenkins等DevOps工具链集成，覆盖编码，测试，运维阶段，帮助客户形成完整的DevSecOps解决方案。