打开一条漏洞记录，页面最先定位到的代码，未必就是数据进入程序的位置。有时它停在公共处理函数，有时指向最终执行操作的语句，需要沿路径继续查看。Checkmarx的数据流视图可以帮助核对输入经过哪些处理后到达风险位置。下面以Checkmarx One的SAST结果界面为例，介绍查看方法，并说明路径看似中断时如何查找原因。

　　一、Checkmarx如何查看漏洞的数据流路径

　　先确认扫描版本，再打开单条漏洞。若本地代码已经更新，直接按当前文件行号查找，容易与扫描结果对不上。

　　1、打开漏洞的代码面板

　　①进入目标项目，打开需要检查的扫描结果，选择【SAST】结果。

　　②在漏洞列表中找到目标记录，单击该行，打开对应的【View Code】面板。

　　③查看【Source Node】、【Source File】、【Sink Node】和【Sink File】，确认路径两端的位置。

　　④在描述区域点击【View More】，阅读该类问题的判断依据。

　　也可以勾选多条漏洞后点击【View Code】，但初次核查建议单击一条记录进入。单条视图提供描述和变更历史，比较适合逐项阅读。

　　2、沿攻击路径逐个查看代码

　　①在【View Code】面板中找到【Attack Vector】，依次点击路径节点，查看对应代码。

　　②从输入节点开始，核对变量赋值、参数传递、返回值和字段访问。

　　③点击末端节点，确认风险操作实际使用的是哪个变量或表达式。

　　④返回中间节点，检查校验结果是否真正约束了继续传递的数据。

　　面板默认可能聚焦【Best Fix Location】，即建议优先修复的位置。它可能位于路径中间，不能据此把它当作源头。数据流路径也不同于完整调用栈，不会逐行展示执行过的所有语句。

　　3、对照同一输入产生的其他结果

　　同一入口可能流向不同风险操作，也可能经过不同处理分支。只读一条路径，容易漏掉其他使用位置。

　　①返回结果列表，按【Source File】或【Source Node】查找相关记录。

　　②单击另一条结果，在新标签中打开代码面板。

　　③切换结果标签，对照【Attack Vector】中的分叉位置。

　　④检查公共节点是否适合统一处理，并分别核对各条路径需要的防护方式。

　　二、Checkmarx数据流追踪中断时如何定位源头

　　先区分“页面没有显示更多节点”与“分析没有识别上游关系”。路径起点也可能是规则识别的输入位置，并不一定对应业务流程最早的入口。

　　1、排除选中状态和结果类型的影响

　　①在【View Code】中取消漏洞复选框的选中状态，再单击目标结果标签。

　　②检查【Attack Vector】是否恢复显示，避免把批量操作工具栏误认为路径丢失。

　　③查看【Source Node】与【Sink Node】，判断是否属于单节点结果。

　　④打开描述中的【View More】，核对该检查是否本来就针对局部代码问题。

　　单节点漏洞的源节点与汇节点可以相同。此时没有跨函数路径，并不能单独说明追踪失败，应先按该检查项的含义阅读代码。

　　2、核对扫描源码是否包含上游实现

　　①根据当前路径记录文件名和函数名，检查本次扫描提交的源码包或仓库版本。

　　②查看扫描日志及实际文件过滤配置，确认入口、公共模块和相关实现文件是否包含在内。

　　③核对生成代码是否在提交扫描前已经生成，避免扫描包只有调用位置。

　　④在相同代码版本上调整必要的扫描范围，执行一次完整扫描后重新查看结果。

　　例如，业务模块调用了内部封装函数，但扫描时没有提交该封装的实现，分析可用的信息就受到限制。补文件时应依据实际调用关系，不宜把无关目录全部加入。

　　3、从最后一个可解释节点反向查找

　　①在【Attack Vector】中点击靠近疑点的节点，记录方法名称、参数位置和接收变量。

　　②在对应版本的源码中查找该方法的调用位置，沿实参继续向上检查。

　　③对返回值，进入实现查看它来自参数、成员字段、数据库读取还是其他接口。

　　④遇到接口调用时，结合项目配置确认实际实现类；遇到回调或反射时，记录关联依据。

　　⑤将人工确认的关系与扫描路径分开记录，保留尚不能确认的位置。

　　比如，页面把一个包装函数的返回值识别为源头，可以继续查看包装函数内部的数据来源。这里补充的是人工代码审查证据，不是点击某个按钮就能让扫描路径自动延长。

　　4、检查查询对自定义接口的识别

　　源码齐全，路径仍停在自定义框架附近时，可以进一步检查查询模型。需要具备相应权限，并使用当前环境支持的查询编辑功能。

　　①打开【Resource Management】→【Query Editor】，载入与问题对应的源码或项目上下文。

　　②在【Query Browser】中选择相关查询，查看输入源、风险操作及净化处理的识别逻辑。

　　③点击【Run Query】，在【Results Browser】选择执行结果，再查看【Results】。

　　④需要查看查询调试输出时，打开【Debug】。

　　⑤若确认需要调整规则，在适当作用域建立自定义覆盖，用问题样例及安全样例验证。

　　自定义查询可能影响多条上层规则。不能为了得到更长的路径，就把普通方法全部声明为输入源；也不能仅因函数名包含“校验”，就把它认定为有效净化处理。

　　三、Checkmarx路径核查后如何保存判断依据

　　排查结论应能回到具体扫描和代码位置。后续重新扫描时，也方便比较变化来自源码、配置还是查询。

　　1、记录疑点并复核新结果

　　①在单条漏洞的【View Code】中使用【Add Note】，写明扫描标识、疑点节点和已检查的调用关系。

　　②点击【Save】，保存备注。

　　③调整源码或扫描配置后重新扫描，比较路径起点、汇点及中间节点。

　　④打开【Changelog】，查看结果状态与严重性调整记录，避免把人工改状态当作漏洞已经修复。

　　⑤只有在证据充分时再调整【State】，并保留对应理由。

　　总结

　　一次漏洞讨论经常需要开发人员解释业务入口，安全人员核对数据处理方式。Checkmarx把相关代码位置连接起来，能让双方围绕同一条记录查看，减少只凭告警名称沟通的误解。对于封装较深的项目，路径之外的源码和配置同样有用，查清一个公共接口后，也能为后续同类问题留下参照。希望本文能帮助大家找到数据流查看入口，把暂时看不清的节点逐步核实。有相关需求，欢迎与我们交流。