关于Checkmarx误报标记要怎么处理，还有标记误报之后重新扫描为什么还会显示，首先要分清楚两种情况，一种只是修改结果的展示状态，另一种是真正把这个风险从之后的扫描结果里排除掉。在Checkmarx One当中，SAST的扫描结果可以做分类处理，用户可以修改结果的状态或者严重等级；如果判断某个漏洞没法被利用，官方文档里对应的做法是标记为Not Exploitable，这样后续同一个项目的扫描里，通常就不会再继续显示这个漏洞了。

　　一、Checkmarx误报标记怎么处理

　　处理Checkmarx的误报标记，不能只写一句“误报”就结束；相对稳妥的做法，是先确认代码的上下文，再说明这条结果为什么不可利用，最后把状态、备注和相关证据一起留存下来。

　　1、先确认是否真的误报

　　我们可以对照【漏洞路径】、【Source】、【Sink】和【Data Flow】，检查数据是不是真的能从输入点，流向危险调用的位置。

　　有些结果看着像是误报，其实只是数据走的路径比较绕；比如输入经过了多层封装，工具没识别到其中某一步的校验逻辑，又或者业务代码里还有额外的白名单判断。判断的时候不能只看结果的标题，要点开数据流详情和对应的代码位置，确认这条攻击路径是不是真的能成立。

　　2、再修改结果状态

　　打开结果详情或者分类处理的页面，把确认不可利用的结果标记为Not Exploitable，也可以按照团队约定好的，选择False Positive、Ignored这类自定义的状态。

　　这里要注意一点，不同的平台版本、不同团队的配置里，状态的名称可能不完全一样；Checkmarx的文档里提到，Result States可以用来标记扫描结果，比如把某些结果标成误报，让团队知道这些结果可以忽略。如果企业内部已经规定了统一的状态标准，就按内部的要求执行，不要每个人都随意选择。

　　3、备注要写清楚原因

　　标记误报的备注，不能只写“false positive”就完事。更实用的写法是说明为什么不可利用，比如输入来源没法被外部控制、参数已经经过统一编码、危险函数只处理固定白名单的值、这条路径只存在于测试代码中等等。备注写得清楚一些，后续重新扫描或者做审计的时候，才能知道当时为什么要做这个判断。

　　二、Checkmarx误报标记后复扫为什么还显示

　　标记误报之后重新扫描，结果仍然显示，不一定代表标记操作失败了；常见的原因是扫描对象、分支、项目、代码位置或者结果的匹配方式发生了变化。

　　1、扫描项目或分支不是同一个

　　首先要检查【Project】、【Branch】和【Scan ID】，确认重新扫描的结果，和当初标记误报的是同一个项目范围。

　　如果是在开发分支上标记的误报，重新扫描的却是主分支；又或者是在旧项目里标记的结果，把代码导入新项目之后再扫描，平台可能就没法直接继承原来的标记。CI配置里的项目名、分支名、仓库路径发生变化，也会造成结果的状态对应不上。

　　2、代码位置变化导致重新识别

　　Checkmarx需要根据结果的特征，来判断这是不是同一个问题。如果代码做了重构、文件路径变了、函数被拆分了、调用链路发生了变化，原来的误报标记可能就没法和新结果完全匹配上。表面看是同一类告警，平台可能已经把它识别成了新的结果，所以复扫之后还会出现。

　　3、标记的是展示状态，不是风险排除

　　有些团队会用自定义的Result State标记误报，这只是给团队内部看的备注状态，不一定等同于Not Exploitable，也不能直接把风险从结果里排除。官方文档里对Not Exploitable的说明，更偏向于让漏洞不再出现在同一个项目的后续扫描中。如果只是用了自定义状态，复扫后仍在列表里显示，也就不奇怪了。

　　4、权限或保存动作没有生效

　　修改SAST结果的严重等级或者状态，需要对应的账号权限，Checkmarx的文档也提到，修改风险严重度或者分数需要相关权限。如果账号权限不足、页面操作没有保存成功、API调用失败了，误报标记可能只是在前端页面看着改了，实际上并没有写入到结果状态里。

　　三、复扫后误报仍显示该怎么排查

　　处理这类问题的时候，不要反复重新扫描；更合适的做法是先对比旧结果和新结果，确认它到底是“旧问题没继承状态”，还是“新问题重新出现”。

　　1、对比新旧结果特征

　　对照【文件路径】、【查询名称】、【漏洞节点】和【数据流路径】，看看复扫的结果和旧的误报是不是完全一致。

　　如果查询名称一样，但是路径、函数或者Sink的位置变了，通常就要按新结果重新做分类处理；不能因为漏洞类型一样，就直接把所有结果都当成旧的误报。

　　2、检查过滤条件

　　有些时候并不是结果没有继承状态，而是页面的过滤条件，把Not Exploitable、Ignored或者历史状态的结果也一起显示出来了。需要检查当前的视图设置，是不是包含了已忽略、已缓解或者不可利用的结果；过滤条件不一样，能看到的结果数量也会不一样。

　　3、统一团队误报处理规则

　　团队最好固定误报的处理口径，明确哪些情况可以标不可利用，哪些问题必须修复，哪些结果需要安全负责人复核。误报如果随便标记，后面复扫仍然会反复有争议；误报如果不写原因，审计的时候也很难解释清楚。

　　总结

　　总的来说，关于Checkmarx误报标记怎么处理、标记后复扫为什么还显示，重点是把误报判断、状态标记和复扫继承的关系分开来看。确认误报前要检查数据流和代码上下文，标记的时候要选合适的状态并且写清原因。复扫后结果仍显示，常见原因包括项目或分支不同、代码位置变化、只是自定义展示状态、权限不足或者过滤条件不同。逐项对比之后再处理，比反复重新扫描更有效。