一、背景
2019年的RSA创新沙箱十强产品中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类工具的技术实践大致可分为以下几种：
正则匹配：代表工具cobra，raptor
基于语法树:代表工具p3c,fireline
java语言可基于class文件:代表工具findsecbugs
基于控制流、数据流、函数调用关系等:市面上的商业级SAST类产品
当然，效果是逐渐递增的，难度也是逐渐增大的，篇幅有限，这里简单介绍基于控制流和数据流的商业级产品的大致技术思路。
要实现还原代码的数据流、控制流和函数调用关系，需要将编译中的前端模块完全实现一遍，基于中间代码去还原数据流和控制流等，大致流程如下
每个阶段的具体实现大家可自行查看编译原理相关的知识，这里不展开讲，其中词法分析和语法分析一般可以借鉴相应的开源工具可以完成，但是语义分析依赖于各种语言的语法，针对每种语言一般需要单独实现，不同的语言翻译成同一套规范的中间代码，根据翻译来的中间代码，符号表等来恢复数据流、控制流和函数调用关系等，然后根据这些流来确定污点传播过程，进而确认是否存在漏洞。
白盒类产品误报率高和耗时长的原因也跟这个复杂流程相关，各个安全厂商自己基于编译原理相关内容实现的代码分析模块，还原的数据流、控制流等难以做到100%准确，同时对100w行这种大量的代码分析，资源占用大，复杂度较高，数据流、控制流的构建过程自然就耗时长，导致了SAST类产品误报率高和耗时长这两个问题难以解决。
回到正题，ShiftLeft是如何解决这个问题？ShiftLeft inspect一直在强调CPG（代码属性图）这个概念
查阅相关资料后我尝试理解了下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产品的痛点，创新的加入数据泄露检测，形成编码，测试，运行阶段的产品解决方案。
PS：最近又看了下ShiftLeft产品资料，这家公司的创新能力是真不错，最近又做了个杀手锏，把SAST与IAST联动，由SAST生成代码完整地图，结合IAST的实时数据流，实时展示IAST测试过程的代码覆盖度，用于帮助测试/安全人员把控IAST安全测试的覆盖率，后续还会出一篇文章再具体讲讲他们今年做的新功能。
