在Checkmarx里面，数据流路径到底要怎么去看，还有数据流路径跟断点为什么老是对不上，很多情况下，这并不单单是工具本身的问题。安全扫描那一头，它看到的是代码里头，那些有可能存在的数据传播的路径，而本地调试这一边，它看到的，是某一次运行的时候，到底有没有真正走到那个地方。一个更偏向于静态分析，一个更偏向于实际执行，两边的结果不完全吻合，这也是很正常的事情。排查的时候，不能只把眼睛盯在漏洞的名字上面，也不能就只看最后那一行sink，还是要把输入的来源、中间是怎么传递的、最后那个危险的调用，这好几段东西连在一起去看。

　　一、Checkmarx数据流路径怎么查看

　　Checkmarx给出来的数据流路径，它通常，是从外部的输入开始起步，中间要经过变量、函数、对象，或者是一些封装的层，到了最后，就流到了数据库、文件、命令执行、页面输出，这一类比较敏感的位置上面去。看这条路径的时候，是要多拿出一点耐心来的，不能就光看打头的第一行，和顶末尾的最后一行，那些被夹在中间的节点，常常才是判断它到底是个误报，还是真有风险的那个关键的地方。

　　1、进到漏洞的详情页里头

　　把具体的漏洞给点开以后，是可以先去看一看那个【Source】、【Sink】，还有夹在路径中间的各个节点的。Source这一边，多半就是请求的参数、表单里面填进来的内容、文件里头的东西、外部接口给返回来的值，这一类的来路；Sink那一头呢，它可能就是SQL的执行、文件的读取、命令的拼接、日志往外输出，或者是给客户端的响应。先把这进口跟出口给弄清楚了，到了后面，你才能闹明白，这一条路径它到底是在说些什么。

　　2、照着数据流的先后顺序去读代码

　　这一条数据流的路径，最合适的看法，是打从Source那边，朝着Sink这边，顺着往下捋，可不要倒着去读。就打个比方，有一个参数，它先从Controller那个地方跑了进来，又穿过了Service、工具类、还有实体对象的转换，最末了才进到了数据库的查询里面去，这中间不管是哪一步，都有可能把最后判断的结果给改变了。有些时候，你看着前面好像是已经给它做过过滤了，可是过滤完了以后的那个值，它其实并没有接着再往下头传；也有些时候，路径里头某一个被包起来的方法，它把那个真正的风险，给藏得比较深。

　　3、重点去看它到底有没有被有效地处理过

　　要判断风险的时候，是要去看一看，在这个中间，到底有没有白名单的校验、参数化的查询、编码的处理、权限的限制，或者是用固定的枚举去给它对上号。不是说，你一看到用户输入进了函数，就一定是有了漏洞，也不是说，一看到有过滤的函数，就觉得它完全安全了，这里头的关键，说到底，还是要看那些被处理过了以后的数据，它到了最后，有没有真的流进后续的调用里面去。

　　二、Checkmarx数据流路径断点为什么对不上

　　断点跟它对不上，这里头最容易碰到的一个原因，就是你拿去扫描的路径，跟你眼下手头正在调试的这条路径，它俩压根儿就不是同一个东西。静态扫描，它是会把那些“有可能会走得通”的路径，全都给列出来，可是你本地这一次的请求，并不一定就满足了对上的那些条件，也不一定就走得到同一个分支上去。

　　1、先看代码的版本

　　最容易叫人给忽略掉的，就是版本它没有对上。扫描的时候，用的是某一个分支、某一次的提交、某一个构建出来的包，可本地调试的时候，说不定早就已经改过代码了。行号差了几行，方法挪了位置，旧的结果又没顾得上重新去扫，这些个情况，都会叫那一条路径看起来，怎么也对不上号。排查以前，要先去做一个确认，把扫描的时间、分支的名字、提交的记录，跟你本地这一套代码，去对上一对，看看它们到底是不是一致的。

　　2、完了以后，再看触发的条件

　　有些个路径，它那个脾气就是，非得要碰上特定的参数、特定的角色、特定的配置，甚至要等某一个开关被打开了以后，它才会去跑。你在本地，随随便便构造了一个请求，断点根本就没有进去，这并不能直接就说明，那一回扫描是误报。你是可以，从入口参数那个地方开始，先补上几个断点，完了再在中间那些关键的变量，还有Sink的旁边，各打上一个点，慢慢地去把这个范围给它缩小。

　　3、多留神一下框架和那些封装的层

　　现在的项目里面，什么Controller、Service、DAO、拦截器、AOP，还有工具类的封装，都非常多，数据在里头绕来绕去的，可能被传得比较远。Checkmarx它是能把一部分的调用关系，给串起来的，可是轮到你自己调试的时候，你可能就只在那些写着业务逻辑的方法里头，丢了几个断点，那前头的框架入口，还有公共的方法，你并没有打到，所以就会觉得，这条路径好像是走着走着就断了。特别是那种反射、注解、模板给生成的代码，它的行号，跟你实际运行起来的时候的那个位置，也有可能不是完全贴在一起的。

　　三、路径对不上的时候，怎么去处理会更稳妥一些

　　真要是碰上了路径对不上的情况，可不要直接就写上一句“断点没进去，这是个误报”。就这么一句话，它的力度实在是太轻了，拿到安全复核那里，是很容易就被人家给退回来的。一个更把稳的做法，是先去确认版本这回事，完了再照着输入条件把它给复现一遍，到了最后，才根据代码上的证据，去下这个判断。

　　1、先确认扫描跟本地，它是一致的

　　去比对那个扫描的分支、提交的ID、构建出来的包，跟你本地的这一套代码，先把这个版本错位的可能，给排除出去。这个动作，你看着好像是挺平常的，可是很多路径对不上的问题，追到了根儿上，那个作怪的原因，就是出在了这里。

　　2、给那些关键的节点，把证据给补上

　　要是你心里头怀疑，说这一条路径它压根儿就是走不通的，那就把具体的条件给它记录下来，比方说，入口的那个参数，它根本就不是从外头来的、分支的条件它凑不到一块儿去、变量在半道上被一个写死了的值给盖掉了，再要不就是，那个Sink实际接到手里头的，其实早就已经是一个参数化了的对象了。这一类的证据，你给得越具体，到了后面跟人解释的时候，它就越能立得住。

　　3、去给它标记成误报的时候，手底下要谨慎一些

　　只有到了那个份儿上，你是真真地确认了，那一笔数据，它是千真万确地，就不会流到那个危险的调用那里去，再要不就是，前头已经有了明明白白的、安全上面的处理了，到了这般时候，那才适合去把它标成一个误报，再要不，就是去申请对这个风险做接受处理。最好是把那个输入的来源、处理的位置、判断的依据，还有当前业务给它带来的那些个限制，全都给交代得清清楚楚的，可不要就只丢下一句“工具给扫错了”，就这么完事了。

　　总结

　　Checkmarx的数据流路径怎么去查看，还有数据流路径断点为什么对不上，这里头顶要紧的一条，就是先把那条静态的路径，跟实际跑起来的路径，给分开来去理解。去查看的时候，要从Source一路读到Sink，中间的变量、封装层，还有处理的逻辑，全部都要看；断点对不上的时候，先去查版本，再去查触发的条件跟框架的调用，不要急着去关那个漏洞。路径要是能解释清楚了，到了后面，误报的处理和真实漏洞的修复，这两件事情，才不至于在那里来回地拉扯。