Checkmarx完成SAST、SCA、IaC等扫描后，报告不仅用于保存漏洞清单，也承担安全评审、整改分派和版本对比等作用。风险等级则用于表达漏洞的潜在影响和处理优先级，但不同扫描器的等级来源并不完全相同。围绕“Checkmarx怎么导出安全扫描报告，Checkmarx报告中的风险等级怎么解读”，需要把报告范围、漏洞严重程度与项目整体风险分开理解，避免仅根据颜色或数量判断项目是否安全。

代码仓库中往往同时存在业务源码、第三方依赖、构建产物和临时文件。如果全部进入SAST扫描，结果中容易出现大量无关内容。设置排除路径时，还要确认扫描分支、源码根目录和规则匹配方式。弄清Checkmarx扫描排除路径怎么添加Checkmarx排除路径设置后仍被扫描怎么办，可以让扫描范围更准确，也能减少规则保存后没有生效的情况。

在Checkmarx里，漏洞分派怎么去设，还有分到开发手里以后怎么跟下去，好多团队把安全扫描接进来以后，都会撞上这个问题。扫描结果出来了，要光靠安全的人在平台里翻报告，开发那头根本闹不清该修哪条、什么时候修、修完又怎么认，那漏洞管理这档子事，就死死地卡在“发现”这一步上了。Checkmarx One能看扫描结果、管漏洞，也能走API、Webhook这些门道去跟外头的流程接上；SAST结果查看器，也就是在项目代码里认漏洞、管漏洞用的。

关于Checkmarx增量扫描的开启方法，还有出现漏报问题时的排查思路，不能简单把增量扫描理解成扫描速度变快；增量扫描的核心作用是缩小扫描的范围，一般只扫描和上一次基准扫描相比发生改动的代码，还有和改动代码存在关联的部分内容。根据Checkmarx官方文档的说明，SAST增量扫描会对上次扫描之后出现的代码改动进行检测，以此缩短扫描的时长，降低资源的消耗；同时文档也提到，全量扫描的结果会更完整，但是花费的时间也会更长。

团队里预设被反复改动，表面看是有人点错了几下，实质是预设被当成了个人偏好而不是受控配置，结果就是同一个仓库今天扫出一批问题，明天换了预设又变了口径，研发与安全两边都很难对齐。要把这件事管住，思路分两条线：一条线把预设的创建、更新、删除权限收紧，另一条线把预设本身做成可追溯、可回滚的配置资产。

很多团队在Checkmarx里加了自定义规则后，扫描结果却毫无变化，或者CI里一会儿能命中一会儿不命中；另一类常见现象是升级或打了内容包后，预置规则集变了，项目突然出现查询为空、规则列表空白、命中数量异常波动。要把问题一次定位清楚，建议把排查顺序固定成两条线：先确认自定义规则到底有没有被“加载并启用”，再确认扫描时有没有“按正确的规则包与预置集执行”。

同样是提一个PR，有的仓库能自动出扫描结果和评论，有的却一点动静都没有，常见原因不是规则写错，而是触发链路断在了更前面，例如Webhook没创建成功、Scan Trigger没开、Protected Branches没把目标分支纳入，或你用的是CI触发但流水线事件根本没命中。Checkmarx One这类代码仓库集成通常依赖仓库事件与Webhook来触发扫描，触发条件本质上由Scan Trigger与Protected Branches共同决定。

在Checkmarx里改规则后看不到效果，很多时候并不是规则源码本身没保存，而是规则虽然改了，却没有真正进入这次扫描的生效链路。按Checkmarx官方公开文档来看，这条链路至少有三层：先在Query Editor里改查询，再把查询放进Preset，最后让项目扫描时真正使用这个Preset。再往后，如果你跑的是增量扫描，或者项目在“无代码变化”场景下直接复用了上次结果，表面上也会很像“规则改完没生效”。所以这类问题更稳的排查方式，不是只盯着查询源码，而是把规则、Preset、项目绑定和扫描方式连起来看。

做Checkmarx选型时，最容易乱的不是安装命令，而是一开始就把本地部署、云端平台和混合接入混成了一件事。按Checkmarx官方文档的口径，本地部署这条线主要还是围绕Checkmarx SAST 9.x展开，支持集中式、分布式和高可用架构；云端这条线则更多对应Checkmarx One，平台能力通过Web、CLI、CI插件和API直接使用。也就是说，先分清你要的是自建扫描服务，还是直接使用云平台，后面的部署路线才不会选偏。

Checkmarx SAST的结果看不懂，常见原因不是规则太深，而是没有按固定顺序下钻：先把结果列表筛出可处理队列，再打开单条问题去看证据链，最后用路径把数据从输入点追到风险点。下面按你实际在界面里会点到的入口，把结果阅读和路径数据流的读法整理成一套可复用动作。