代码已经合并，问题单也已关闭，下一次扫描却又报出同类漏洞。这时先找到两次扫描对应的代码，再看漏洞路径，通常比直接重开问题单更容易查清原因。报告中的“再次发现”可能来自旧代码回流，也可能是另一条尚未处理的路径；相反，列表中没有漏洞，也需要确认它是否参加了本次检查。下面以Checkmarx One英文界面的SAST扫描为例说明。

　　一、Checkmarx如何复核已修复漏洞的扫描状态

　　复查需要同时核对扫描任务和漏洞结果。任务完成，只能说明分析流程结束；漏洞是否修复，还要结合扫描版本、检查范围以及前后路径判断。其他Checkmarx产品的入口和状态名称可能不同，不宜直接套用。

　　1、确认扫描检查的是修复版本

　　流水线有时会扫描指定分支、临时合并代码或上传的压缩包。即使扫描时间晚于修复时间，也不能仅凭日期认定修复已经包含在内。

　　①打开目标项目，进入【Scan History】，选择修复后的扫描。

　　②在扫描概览中记录扫描编号、来源和状态，并到【Scanners】检查SAST是否完成。

　　③对照流水线检出日志或上传记录，确认分支、提交编号及源码包包含修复内容。

　　④打开【Scan Configuration】，核对规则配置与文件过滤条件，确认相关代码仍在检查范围内。

　　2、比较修复前后的结果

　　支持扫描对比的版本，可以选择同一项目、同一仓库分支或相应上传源码的两次扫描，查看新增、已解决和持续存在的结果。配置变化导致未重新检查的内容，还需单独辨认。

　　①在【Scan History】中选中修复前、修复后的两次SAST扫描，点击【Compare SAST Results】。

　　②在预览中点击【View Results】，找到原漏洞，检查其属于已解决、持续存在还是新增结果。

　　③查看是否存在未评估结果；若有，打开详情读取原因，不能将其当作修复通过。

　　3、区分扫描变化与人工研判

　　漏洞的State用于记录研判，例如待验证、已确认或不可利用；扫描对比则反映两次分析的发现情况。把一条结果改成不可利用，并不等于代码已经修复。

　　①检查原漏洞的状态及备注，确认此前是完成代码修改，还是通过人工研判调整了状态。

　　②在复查记录中关联原漏洞、修复提交和新扫描编号，注明对比结果及必要的评审、测试依据。

　　二、Checkmarx修复后漏洞再次出现的原因有哪些

　　先比较问题实例，再判断是否复发。Checkmarx One会依据源节点、汇节点及攻击向量元素识别SAST实例；这些元素变化后，相似问题也可能被识别成另一实例。因此，漏洞名称相同或行号接近，都不足以证明是原问题重新出现。

　　1、修复没有进入本次扫描代码

　　修复提交留在开发分支，发布分支尚未移植；合并冲突时保留旧实现；流水线上传了之前生成的源码包，都可能让扫描再次看到原有路径。

　　①对照本次实际扫描的提交，检查修复涉及的文件和语句是否存在。

　　②沿提交历史查看合并、回退及移植记录，确认修改是否被覆盖。

　　③若源码包来自构建目录，重新生成并检查包内文件，再安排扫描。

　　2、只修复了部分数据流

　　例如同一数据库操作被多个入口调用，只调整其中一个入口，其他输入路径仍可能到达原来的危险操作。另一种情况是增加了检查，但后续使用的仍是未经处理的原值。

　　①从新结果中找到输入来源、传播过程和最终操作位置，与旧结果逐段比较。

　　②检查安全处理是否覆盖当前路径，并确认处理后的值确实被后续操作使用。

　　③根据遗漏路径补充修复和回归用例，避免只围绕原报告中的单一入口验证。

　　3、分析条件或问题身份发生变化

　　规则、引擎或扫描范围调整后，可能发现以前未覆盖的路径。项目迁移、新建项目或代码结构变化，也可能使原有研判无法直接对应到新结果。Checkmarx One的实例研判保存在项目范围内，不会自动应用到另一个项目。

　　①比较两次扫描的项目、配置、规则及可查的引擎版本信息，记录变化项。

　　②检查新旧结果的源节点和汇节点，判断是旧路径持续存在，还是另一个实例首次被识别。

　　③按新结果重新核实可利用条件，保留与旧记录的关联，不直接复制关闭结论。

　　三、Checkmarx复查结果不一致时如何继续定位

　　若同一份代码在前后扫描中表现不同，可以暂时缩小变化范围：先固定源码和配置，再检查日志与结果。这样更容易判断差异来自修复、扫描设置，还是分析过程本身。

　　1、补做一次可比较的扫描

　　增量扫描的结果需要结合其基线理解。出现难以解释的差异时，可以用完整扫描补充验证，避免同时更改代码、规则和过滤范围。

　　①固定待复核提交，保存当前配置；需要时，在相同项目中安排完整SAST扫描。

　　②从SAST扫描卡片的更多选项中选择【Download logs】，检查异常、跳过文件及分析范围。

　　③将完整扫描结果与原记录对照，确认漏洞路径是否仍然存在。

　　2、让记录解释清楚本次结论

　　①持续检出且确认仍有风险时，追加原因和后续修复安排。

　　②确认为不同实例时，新建或关联问题记录，说明与旧漏洞的关系。

　　③未检出且完成必要核验时，保存扫描编号、配置及验证依据，再按项目流程关闭问题。

　　总结

　　漏洞再次出现，往往也是检查修复流程的一次机会。某次分支遗漏、一个未覆盖的调用入口，甚至上传源码包的方式，都可能在复查中暴露出来。查明后把原因写进记录，后续遇到相似情况就有现成线索，不必重新翻遍日志。希望这些步骤能帮助大家更准确地判断扫描结果，让开发与复查人员围绕同一份代码沟通。日后开展Checkmarx相关工作时，如有需要，也欢迎联系我们交流。