Checkmarx默认查询规则能够覆盖大量常见安全问题，但在实际项目中，企业通常还需要针对内部编码规范、特殊业务逻辑以及自定义安全要求增加检测能力。自定义查询可以补充默认规则无法覆盖的场景，但由于它涉及查询编写、规则加载、代码解析和扫描配置多个环节，出现“规则已经创建但扫描没有结果”的情况并不少见。围绕“Checkmarx怎么配置自定义查询规则，Checkmarx自定义规则没有触发如何检查”，关键是确认规则是否真正进入扫描流程，并判断问题发生在哪个阶段。

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

Checkmarx完成SAST扫描后，结果查看器中可能同时存在不同语言、严重程度、漏洞类型和代码路径的问题。合理使用分组，可以更快定位同类风险，但分组节点数量、相似结果数量和实际漏洞实例数量采用的统计口径并不相同。了解Checkmarx结果分组怎么设置Checkmarx结果分组后漏洞数量不一致怎么办，有助于避免把页面展示变化误认为扫描结果发生变化。

想要搞明白Checkmarx容器镜像扫描怎么开启，还有扫描失败了该怎么排查，不能只想着把代码仓库交给工具扫一遍就行，更重要的是先搞清楚扫描的对象到底是什么，是Dockerfile里的基础镜像，还是已经构建好的成品容器镜像。Checkmarx的Container Security模块可以扫描项目里的Dockerfile，找出里面用到的容器镜像，还有镜像存在的风险；如果用CLI命令运行，还能指定公共或者私有仓库里的具体镜像来扫描。

在Checkmarx里面，数据流路径到底要怎么去看，还有数据流路径跟断点为什么老是对不上，很多情况下，这并不单单是工具本身的问题。安全扫描那一头，它看到的是代码里头，那些有可能存在的数据传播的路径，而本地调试这一边，它看到的，是某一次运行的时候，到底有没有真正走到那个地方。一个更偏向于静态分析，一个更偏向于实际执行，两边的结果不完全吻合，这也是很正常的事情。排查的时候，不能只把眼睛盯在漏洞的名字上面，也不能就只看最后那一行sink，还是要把输入的来源、中间是怎么传递的、最后那个危险的调用，这好几段东西连在一起去看。

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

做Checkmarx结果导出时，失败最常见的原因不是扫描没跑出来，而是导出走了不适配的通道。很多团队一边在Web里点报表，一边又想拿到SARIF，结果发现Web报表只给PDF、JSON、CSV，SARIF反而要走CLI或CI产物。把你当前用的是Checkmarx One Web报表、还是CLI结果导出先分清，再按对应路径排查和下载，效率会高很多。

写Checkmarx结果报告时，最容易失真的地方，不是漏洞名字写错，而是复现描述、证据截图和调用链说明各写各的，最后读报告的人只能看到一个结论，却看不清它是怎么被发现、影响落在哪里、修复点又该放在哪。Checkmarx官方文档把这条线拆得很清楚，SAST Results Viewer本身就把结果分成Vulnerabilities Table和Code Viewer两大部分，结果详情里还能继续展开Source、Destination、状态、优先级、Best Fix Location和评论记录，所以一份能落地的报告，本来就应当顺着这些官方结果要素来写，而不是只抄一个漏洞标题。

做Checkmarx扫描时，很多人会把“扫描失败”“语言没识别出来”“依赖缺失”当成同一种问题处理，结果前面反复重跑，后面还是找不到真正卡点。更稳的判断方式，是先把问题拆成三层来看：第一层是SAST本身有没有按预期识别代码语言和扫描范围，第二层是扫描到底跑到哪一步失败，第三层才是依赖缺失是不是来自SCA Resolver、包管理器或构建环境。Checkmarx官方文档对这几层是分开描述的，所以排查时也不该混在一起。

很多团队用Checkmarx扫描一段时间后会遇到同一个瓶颈：内置规则能抓到共性问题，但对你们的框架约定、输入校验封装、网关鉴权逻辑不够贴合，误报偏多，遗漏也难解释。解决方法不是把规则全关掉，而是用自定义规则把你们的真实代码语义“教给”扫描器，并把自定义内容纳入Preset与项目配置，形成可复用、可回滚的治理闭环。