Checkmarx把结果标成误报后又出现，最常见的不是你没点对按钮，而是复扫时这条结果在系统里被识别成了另一条实例，或者抑制只对当前项目生效，你却换了分支、换了项目、换了扫描配置。要把问题一次性压住，你需要先确认抑制到底有没有保存成功，再把复扫复现条件统一，最后再决定要不要把抑制范围从项目扩展到应用层。

　　一、Checkmarx误报抑制后又出现怎么办

　　误报被抑制后又出现，优先按识别一致性去排查，也就是这条结果在新扫描里是否还是同一个漏洞实例。如果不是同一个实例，你之前的抑制当然不会自动套用，新结果会以新发现的形式重新冒出来；如果是同一个实例但仍出现，就要回到保存动作与范围设置去查。新扫描发现同一个漏洞实例时会标记为复现，并会把你之前对状态、严重性、备注等改动带到新扫描里。

　　1、先确认你抑制的是Not Exploitable而不是Proposed Not Exploitable

　　在结果列表里打开该条结果的状态栏，把状态改成Not Exploitable再保存；Proposed Not Exploitable通常只是提出疑似误报，仍会出现在统计与列表里，容易让人误以为抑制没生效。Not Exploitable的实例不会出现在扫描汇总、图表、报表与仪表盘里。

　　2、核对复扫时是否换了项目、分支或应用入口

　　同一套代码如果在不同Project或不同Branch里扫描，系统很可能把它当成另一条结果集合；你需要在门户里确认复扫选的是同一个Project与同一个Branch，再对照结果是否变成Recurrent。

　　3、检查代码是否做过格式化或大范围重构导致实例指纹变化

　　大规模移动文件、改函数签名、抽公共方法、重排目录，会让同一个问题在新扫描里落到不同的行号与不同的调用链，结果会被当成新实例重新出现；这时正确做法不是继续点一次误报，而是把复现条件稳定下来后再统一处理。

　　4、确认扫描预设与规则包有没有变化

　　如果你换了Preset，或平台更新了查询规则导致命中逻辑变化，旧结果可能以新的查询ID重新产出；这种情况要么在扫描范围层面关掉对应查询，要么接受它是新结果并重新做一次误报标记。

　　5、排查是否只在结果查看器里改了状态但没有真正保存

　　有些页面允许你在详情里编辑状态，但如果你没有点保存，刷新后就会回到原状态；你可以用下一小节的保存步骤重新操作一遍，然后重新打开该条结果确认状态仍为Not Exploitable。

　　6、如果你们用的是应用层聚合视图，确认抑制范围是否仅限Project

　　默认情况下，你对SAST结果做的状态与严重性调整只对同一Project内的相同结果生效；如果你的组织把同一应用拆成多个Project扫描，就会出现这个Project抑制了，另一个Project还会冒出来的情况。平台提供把调整范围扩展到整个Application的能力，但通常需要管理员通过API配置。

　　二、Checkmarx抑制规则怎么保存生效

　　保存生效的关键点只有一个，你必须在结果列表里完成状态变更并执行保存动作，然后再用一次刷新或复扫验证它是否被平台记住。不同产品线界面略有差异，但核心路径一致，先选中结果，再编辑状态，再保存。

　　1、在SAST结果列表里用复选框选中要抑制的结果

　　进入SAST结果页面的漏洞列表，勾选一条或多条结果，确保你选中的都是同一类误报，避免把可利用问题一起抑制掉。

　　2、用【Edit】下拉修改State并选择Not Exploitable

　　在列表上方点击【Edit】，把State改为Not Exploitable；如果你们有审批流程或要求备注，先把评论补齐再继续。

　　3、点击【Save】确认变更落库

　　完成状态选择后点击【Save】，保存成功后再回到列表确认该条结果的状态已更新。官方的SAST结果分诊步骤明确要求在修改状态或严重性后点击保存。

　　4、刷新页面确认抑制不会回弹

　　按【F5】刷新或重新进入该Project的结果页，确认该条结果仍保持Not Exploitable；如果刷新后回弹，优先怀疑你没有保存成功或当前账号无分诊权限。

　　5、用一次复扫验证抑制是否会随复现自动继承

　　触发一次同分支复扫，再回到结果列表，观察该条问题如果再次被识别为同一实例，是否会以Recurrent形式出现并自动继承你之前的状态；同实例复现会继承你对状态等谓词的改动，这是验证抑制是否真正生效的最直接证据。

　　6、如果你抑制后仍在汇总里看到数字，确认你抑制的是哪类状态

　　Not Exploitable不会体现在扫描汇总与报表里；如果你仍在汇总里看到它，说明状态可能停留在Proposed Not Exploitable或仍是To Verify，需要回到该条结果把状态改到Not Exploitable再保存。

　　三、Checkmarx复扫一致性怎么校验

　　想让误报不再反复出现，除了点一次Not Exploitable，更重要的是把复扫的输入条件稳定住，让系统每次都能识别到同一实例并继承你的分诊结果。你把下面三类口径固定下来，误报回潮会明显减少。

　　1、固定扫描入口与仓库分支口径

　　把日常扫描固定为同一个Project与同一个默认分支，临时扫描新分支就明确这是独立结果集，避免把分支差异误当成抑制失效。

　　2、固定扫描预设与查询包版本

　　团队内部不要今天用一个Preset明天换一个Preset，查询范围一变，结果实例就可能变化；如果必须变更Preset，先在小范围试跑并评估误报是否会重新出现。

　　3、把误报分层处理，结果级抑制与规则级抑制各管一类问题

　　单条业务场景导致的误报，用结果级Not Exploitable就够；同类误报大量出现且可预期时，考虑在Preset里禁用对应查询或调整规则口径，把噪声从源头关掉。

　　4、对跨项目的同类误报建立统一范围策略

　　如果同一应用拆成多个Project扫描，按默认设置抑制只在Project内继承；需要跨Project一致时，让管理员评估是否把结果调整范围扩展到Application级，平台提供该范围配置能力但通常需要API方式落地。

　　5、把分诊权限与审计要求提前对齐

　　部分组织要求分诊必须由特定角色完成，或必须写评论才能保存；你在没有权限的账号上操作，页面看似改了，实际不会落库，刷新就回弹。遇到这类情况先确认账号角色，再重新按保存步骤执行。

　　总结

　　Checkmarx误报抑制后又出现，先确认是否把状态真正保存为Not Exploitable，并用复扫验证同实例复现是否继承状态；如果新扫描被识别成新实例，或你换了项目分支与扫描预设，误报就会再次出现。要让抑制规则稳定生效，按结果列表勾选后用【Edit】改State并点【Save】落库，再把复扫入口、分支与Preset口径固定住，必要时再评估把抑制范围从Project扩展到Application级。