‌CheckMarx

关于Checkmarx误报标记要怎么处理，还有标记误报之后重新扫描为什么还会显示，首先要分清楚两种情况，一种只是修改结果的展示状态，另一种是真正把这个风险从之后的扫描结果里排除掉。在Checkmarx One当中，SAST的扫描结果可以做分类处理，用户可以修改结果的状态或者严重等级；如果判断某个漏洞没法被利用，官方文档里对应的做法是标记为Not Exploitable，这样后续同一个项目的扫描里，通常就不会再继续显示这个漏洞了。

很多团队遇到的现象是扫描一跑就把节点CPU打满，内存一路涨，队列越堆越多，最后要么扫描超时，要么节点被挤到不可用。处理这类问题不要只盯着加硬件，更关键是把并发、扫描范围、扫描类型三件事先压住，再用平台自带的引擎限制与分支规则把资源曲线拉平。

内网环境连不上Checkmarx服务器，现场最常见的不是软件本身故障，而是访问入口写错、代理走向不对、证书与协议不匹配三类问题叠在一起。处理时别先反复重装插件或换账号，先把网络链路跑通，再把代理参数落到你实际使用的客户端组件上，最后用一次可复现的验证动作把配置固定住。

很多团队看Checkmarx报告时，最容易只盯当前漏洞总数，结果一到管理层复盘或项目周会，就讲不清风险到底是在下降，还是只是扫描口径变了。Checkmarx官方其实已经把趋势分析拆成了几层：一层是Analytics里的趋势图和KPI，用来看当前时间段与上一时间段的变化；一层是Project或Application视图里的Total Results Overview与Resolved Results Overview，用来看项目级和应用级的结果走势；再往下才是按严重级别、状态、年龄和语言维度做细分。因此，报告解读不能只看一张结果表，而要把时间范围、统计对象和结果口径先对齐。

Checkmarx SAST扫描慢，很多时候不是单纯“机器不够”，而是把三类问题混在了一起。一类是扫描范围本来就偏大，一类是项目没有用好增量扫描这条提速路径，另一类是队列和并发上限没有按CxManager与CxEngine的边界去配。Checkmarx官方文档写得很清楚，队列里会区分Pending和Queued，其中Pending还在做上传、解压等准备动作，Queued才是已经准备好但在等系统资源；同时，CxManager的并发上限和CxEngine的并发上限也不是同一个配置项。

想要搞明白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里，漏洞分派怎么去设，还有分到开发手里以后怎么跟下去，好多团队把安全扫描接进来以后，都会撞上这个问题。扫描结果出来了，要光靠安全的人在平台里翻报告，开发那头根本闹不清该修哪条、什么时候修、修完又怎么认，那漏洞管理这档子事，就死死地卡在“发现”这一步上了。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里面，预设规则集要怎么选，还有这套规则集跟项目语言又要怎么匹配，不能光想着“规则越多就一定越安全”。预设规则集这东西，说到底，就是一整套查询规则，它的作用是在跑SAST的时候，决定到底要重点去查哪些漏洞类型、哪些风险级别，还有哪些跟语言挂钩的规则。Checkmarx One的文档里面也讲过，Presets就是一组可以让你去选的查询规则，SAST扫描必须选定一个预设规则集，要是你没去挑，它就会自己用上那套默认的。

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

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

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

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