在Checkmarx里面，预设规则集要怎么选，还有这套规则集跟项目语言又要怎么匹配，不能光想着“规则越多就一定越安全”。预设规则集这东西，说到底，就是一整套查询规则，它的作用是在跑SAST的时候，决定到底要重点去查哪些漏洞类型、哪些风险级别，还有哪些跟语言挂钩的规则。Checkmarx One的文档里面也讲过，Presets就是一组可以让你去选的查询规则，SAST扫描必须选定一个预设规则集，要是你没去挑，它就会自己用上那套默认的。

分支扫描看起来覆盖不全，常见有两类情况：一类是分支确实没有把该扫的分支触发起来，或文件被过滤规则排掉了；另一类是你在拉取请求也称为Pull Request的视图里只看到New Issues，以为老问题没扫到。先把现象归类，再去改触发分支与文件过滤，会比反复重跑扫描更快。

Checkmarx新项目导入后不识别代码，最常见不是代码真的没进来，而是扫描口径把文件排除了，或者语言模式只扫了某一种主语言，导致你看到的结果像是没有代码。处理这类问题要先确认两件事，第一是文件是否被排除规则与推荐排除挡住，第二是语言识别是否按多语言方式运行，再把过滤规则收敛到你真正要扫的目录与扩展名。

Checkmarx登录后反复跳转，多数发生在已完成身份认证但会话没能落地这一段，浏览器不停在Checkmarx登录页与企业身份提供方页面之间来回。排查时先确认你接入的是哪一种单点登录方式，再把回跳地址、会话Cookie、反向代理与IdP配置逐项对齐，问题通常能在一到两轮验证里定位清楚。

很多团队在接入Checkmarx之后，最先遇到的不是扫描不会跑，而是结果出来以后口径不统一。安全团队盯着严重度，研发团队盯着排期，项目经理又只关心这批问题要不要马上修。时间一长，同样是一个High，有的项目当天提单，有的项目却放到下个版本，最后不是工具有问题，而是规则没有说清。要把这件事理顺，关键是先把Checkmarx的分级逻辑拆开，再把内部优先级定成统一标准。

很多人第一次接触Checkmarx，会先把它理解成一款代码扫描工具，但按Checkmarx目前的官方定位来看，它已经不只是单一SAST产品，而是一个覆盖多类应用安全能力的平台。官方首页和产品页把Checkmarx One定义为应用安全平台，整合了SAST、SCA、Secrets、IaC、ASPM与AI Assist，用来统一处理开发阶段到治理阶段的安全问题。

Checkmarx的增量扫描本质是SAST在已有全量基线之上，只聚焦上次全量扫描以来的改动代码，并把与改动相关的邻近代码一并纳入分析，以便更快出结果。要让它稳定生效，你需要先跑通一次全量扫描，再把增量开关与范围过滤配置到项目规则、流水线或CLI里，最后用扫描类型与历史记录验证本次到底跑的是增量还是全量。

在Checkmarx里，“项目”通常对应一个源码仓库或其中一个可独立交付的组件，项目创建做对了，后续扫描范围、权限隔离、基线与趋势才会稳定；做错了，最常见的就是权限混乱、结果串项目、流水线变量到处写死。下面按创建项目的落地步骤，再讲如何把项目结构与命名规则统一到团队可执行的口径。

只要团队开始大量依赖Checkmarx，就会发现一个绕不开的问题：扫描能扫，报告也能出，但真正要落到开发手上时，大家往往很难快速判断哪些问题和自己相关、哪些属于底层框架、哪些只是共用组件遗留的历史问题。很多开发者甚至会把报告翻几页后就放一边，等到安全团队来催才重新打开。报告难分类，并不是开发者不用心，而是默认的呈现方式很难匹配现实中的工程结构。要真正让结果能"看得懂、分得清、发得出去"，必须先搞明白难点在哪，然后再思考怎样重塑分组方式，让报告成为工作流的一部分，而不是负担。

很多团队把Checkmarx接入CI/CD后，最期待的功能就是增量扫描，结果实际跑起来却经常发现：明明只改了几行代码，扫描时间还是两三个小时，一看日志还是走的Full Scan。久而久之，大家干脆把增量当摆设，直接接受全量。这其实不是Checkmarx本身的问题，而是增量扫描对前置条件要求极高，任何一个环节没对齐，系统就直接“认怂”退回全量。今天我们系统梳理一下Checkmarx增量扫描为什么经常不生效，以及增量范围到底是如何识别的，把这些容易忽略的关键点讲清楚，帮大家把增量真正用起来。