开发人员完成代码修改后，Checkmarx不会因为代码仓库中已经提交了修复，就自动把原漏洞改为已修复。平台需要重新扫描修改后的源码，并通过前后两次结果匹配判断问题是否仍然存在。了解Checkmarx修复验证怎么执行Checkmarx修复验证后漏洞状态没有更新怎么办，可以避免因扫描分支、源码范围或结果视图选择错误，误以为修复没有生效。

　　一、Checkmarx修复验证怎么执行

　　修复验证的核心是使用修改后的代码重新运行SAST扫描，再将新结果与修复前的扫描进行比较。开始验证前，应先记录原问题的文件位置、攻击路径和相似性标识。

　　1、确认需要验证的漏洞信息

　　①进入【工作区】→【项目】。

　　②找到目标项目，将鼠标移到项目所在行。

　　③点击【结果】，选择【SAST】。

　　④在结果列表中搜索需要验证的漏洞。

　　⑤打开漏洞详情，查看源节点、目标节点和完整攻击路径。

　　⑥记录漏洞所在文件、代码位置、查询名称和相似性标识。

　　修复时不能只修改平台标出的最后一行代码。还要沿着攻击路径检查外部输入、数据传递、校验过程和危险调用，确认风险路径已经被真正切断。

　　2、完成代码修改并提交

　　根据漏洞类型调整代码后，应先在本地完成编译、单元测试和相关功能测试，再把修改提交到用于Checkmarx扫描的分支。

　　提交完成后记录代码提交编号，并确认扫描账户可以读取该分支。若项目采用压缩包上传，还要重新生成源码压缩包，不能继续使用修复前保存的旧文件。

　　3、重新发起SAST扫描

　　①进入【工作区】→【项目】。

　　②在目标项目所在行点击【扫描】。

　　③在【扫描源】中选择代码仓库或源码压缩包。

　　④使用代码仓库时，选择包含修复内容的分支。

　　⑤使用压缩包时，重新上传修复后的完整源码。

　　⑥点击【下一步】。

　　⑦勾选【SAST】。

　　⑧需要完整验证时，不要勾选【增量扫描】。

　　⑨点击【扫描】，等待任务完成。

　　只修改少量文件时可以运行增量扫描，但涉及文件移动、方法重构、公共组件调整或扫描配置变化时，完整扫描更便于核对修复结果。

　　4、比较修复前后的扫描结果

　　①打开目标项目。

　　②进入【扫描历史】。

　　③勾选修复前扫描和修复后扫描。

　　④点击【比较SAST结果】。

　　⑤展开对应的语言和漏洞类型。

　　⑥查看【新增问题】【重复问题】【已修复问题】。

　　⑦打开目标漏洞，核对代码路径和相似性标识。

　　原问题只出现在旧扫描中时，会进入【已修复问题】；两次扫描都能匹配到时，会显示为【重复问题】；新扫描中出现无法与原结果匹配的问题，则会显示为【新增问题】。

　　二、Checkmarx修复验证后漏洞状态没有更新怎么办

　　修复后的扫描已经完成，但漏洞仍显示为重复或确认状态时，应先检查验证对象是否正确，再判断代码修改是否真正消除了查询识别的数据流。

　　1、检查扫描分支和源码版本

　　①进入【扫描历史】。

　　②打开最新扫描的详细信息。

　　③核对代码仓库、分支名称和扫描时间。

　　④将扫描时间与代码提交时间进行比较。

　　⑤确认修复提交已经进入当前扫描分支。

　　⑥使用压缩包扫描时，检查上传文件是否为重新生成的版本。

　　代码已经提交到开发分支，但扫描仍使用主分支，或者流水线复用了旧压缩包，都会导致原漏洞继续出现。

　　2、确认打开的是最新扫描结果

　　①进入项目的【SAST结果】。

　　②检查页面右上角的分支选择。

　　③切换到修复代码所在分支。

　　④返回【扫描历史】，确认最新任务状态为已完成。

　　⑤重新打开最新扫描的结果页面。

　　⑥清除结果列表中的状态、严重程度和关键词筛选。

　　项目存在多个分支时，页面可能仍停留在主分支或上一次查看的结果。旧扫描中的漏洞不会因为其他分支完成了修复验证而消失。

　　3、重新检查修复后的攻击路径

　　①在最新结果中打开仍然存在的漏洞。

　　②查看源节点和目标节点。

　　③沿着攻击路径逐个检查中间节点。

　　④对照代码仓库中的实际修改。

　　⑤确认输入校验、编码、权限判断或参数化处理位于正确位置。

　　⑥修改遗漏后重新运行扫描。

　　有些修改只改变了变量名、封装方式或代码位置，危险数据仍然可以到达目标调用。此时相似性标识可能保持不变，平台会把问题继续识别为重复漏洞。

　　4、检查扫描配置是否发生变化

　　①分别打开修复前后的扫描信息。

　　②核对查询预设。

　　③检查语言模式和文件排除规则。

　　④比较扫描文件数和代码行数。

　　⑤确认没有更换项目或扫描包目录结构。

　　⑥配置不一致时，统一条件后重新执行完整扫描。

　　查询预设、扫描范围或项目分支发生变化，会影响结果匹配。修复后的问题也可能因文件路径、源节点或目标节点大幅调整，被识别成一条新的结果。

　　三、怎么确认漏洞已经完成闭环

　　漏洞进入【已修复问题】后，还需要核对新扫描中是否出现相近路径，并保留能够追溯修复过程的记录。

　　1、核对是否产生替代性新增问题

　　①在扫描比较页面查看【已修复问题】。

　　②记录原漏洞的查询名称和涉及文件。

　　③切换到【新增问题】。

　　④按照相同查询名称、文件和目标节点进行筛选。

　　⑤打开相近结果，检查攻击路径。

　　⑥确认新增结果不是原问题因代码移动而重新生成。

　　原相似性标识消失并不一定代表风险彻底解决。大范围重构后，原漏洞可能以新的文件位置或数据流重新出现，需要结合代码路径判断。

　　2、保存修复验证记录

　　①记录修复前后的扫描编号。

　　②记录代码提交编号和验证分支。

　　③保存原漏洞编号、查询名称和相似性标识。

　　④说明采用的修复方式。

　　⑤记录扫描比较中的最终分类。

　　⑥将验证结果关联到开发任务或缺陷工单。

　　完成记录后，开发、安全和测试人员可以使用同一组信息确认修复范围，也便于以后出现相似问题时追溯处理方式。

　　总结

　　Checkmarx中的修复验证并不是手动把漏洞改成关闭状态，而是通过新一轮扫描确认原有风险路径是否仍然存在。处理Checkmarx修复验证怎么执行Checkmarx修复验证后漏洞状态没有更新怎么办时，需要同时核对源码版本、扫描分支、攻击路径、查询预设和相似性匹配结果。只有原问题不再被检测到，并且没有以新的路径重新出现，才能认为本次修复已经形成完整闭环。如有相关使用需求，欢迎联系咨询。