项目做完首轮扫描，团队准备保留历史问题、集中处理新增漏洞，却发现启用增量扫描后，旧问题依然出现在列表中。这不一定说明基线失效。Checkmarx如何建立漏洞修复基线，Checkmarx基线应用后历史问题仍被列出如何核查，需要先确认基线用于扫描还是修复跟踪。以下以Checkmarx One的SAST结果为例。

　　一、Checkmarx如何建立漏洞修复基线

　　修复基线是一份有明确代码范围和检查条件的问题清单。增量扫描使用的基础扫描或基础分支，承担计算参照作用，不能直接当成历史漏洞的豁免清单。

　　1、选定一次完整扫描作为参照

　　①固定代码提交，在同一项目下完成全量SAST扫描，检查源码范围、排除项、预设和自定义查询是否符合约定。

　　②进入【Resource Management】→【Scans】，找到该轮扫描，核对【Project】、【Branch】及完成状态，记录Scan ID和代码提交标识。

　　③点击扫描记录，在【Scanners】中打开SAST的【Results】，检查结果；再到【Scan Configuration】保留实际使用的配置。

　　④为该轮结果建立基线编号，记录日期及责任人，保证后续能够定位参照资料。

　　2、整理问题清单与审查结论

　　①在结果表中保留漏洞类型、源文件、汇点文件、实例标识和严重性，使用CSV导出功能保存明细。

　　②逐条检查【State】。尚未确认的结果保留【To Verify】，确认需要处理的问题按实际情况标记为【Confirmed】或【Urgent】。

　　③使用【Add Notes】记录修复任务、责任人和审查依据，将历史存量与后续发现的问题分开跟踪。

　　④确认为误报时，才由有权限的人员使用【Not Exploitable】。不能为了让历史数量归零，将真实漏洞批量改成不可利用。

　　3、建立后续扫描与比较约定

　　①继续在约定项目和分支下扫描，保留提交标识及Scan ID，不要仅靠日期判断是否同一轮结果。

　　②查看【Status】中的【New】与【Recurrent】，再与固定基线清单比对。这是平台的实例跟踪分类，不能直接等同于“相对任意指定基线的新增和历史”。

　　③需要增量扫描时，在【Project Settings】→【Rules】中配置SAST相关规则，或在当前扫描入口选择【Incremental scan】。

　　④使用基础分支配置时，确认具体引用。Base branch属于增量计算设置，不会自动隐藏历史漏洞，基础分支的全量扫描也应保持更新。

　　二、Checkmarx基线应用后历史问题仍被列出如何核查

　　先找一条历史问题，查看它的Status、State和数据流，再区分正常保留、筛选未生效和实例匹配变化。

　　1、检查历史结果是否属于正常合并

　　①打开当前扫描的【Results】，查看旧问题是否标记为【Recurrent】，再核对扫描类型是否为增量扫描。

　　②确认问题所在文件及路径是否进入本轮变更分析范围。增量扫描会将基础全量扫描中的部分结果合并回来，提供完整结果集。

　　③若只想查看平台标记的新增结果，点击【Status】列的筛选图标，选择【New】，检查【Groups&Filters】中显示的条件。

　　④刷新后重新确认筛选是否仍在。需要保留常用视图时，使用默认视图保存功能；只改变分组不会排除历史条目。

　　例如，全量扫描已有某条注入路径，后续仅修改另一模块，增量结果中继续保留该条目，并不意味着旧文件又被完整扫描了一遍。

　　2、核对状态继承和实例身份

　　①打开历史记录与当前条目，对照【Source Node】、【Sink Node】和攻击路径中的中间元素，确认是否为同一实例。

　　②检查【Changes Made in】列，查看源码、查询或扫描器是否变化。路径元素变化后，即使漏洞类型相同，也可能被识别为另一实例。

　　③核对两轮结果是否属于同一项目。审查信息保存在项目范围内，迁移项目后，不能假定原有状态自动继承。

　　④检查操作是否保存及当前【State】。Status描述新旧发现关系，State描述审查结论；标记为Confirmed不会让漏洞消失。

　　三、Checkmarx漏洞修复后如何验证基线记录

　　历史问题仍在时，先验证修复是否进入被扫描代码，再判断实例跟踪情况。关闭任务前，应有对应的复核结果。

　　1、确认修复提交进入本轮扫描

　　①比较修复提交与本轮源码，核对分支、上传文件和排除项，确认修复文件没有遗漏。

　　②从【Scanners】的更多操作中选择【Download logs】，查看执行日志，结合【Scan Configuration】检查实际条件。

　　2、用全量扫描复核争议结果

　　①遇到增量合并结果难以解释时，对同一提交执行全量扫描，保持查询及源码范围一致。

　　②定位原实例及相关数据流，检查问题是否不再出现，或仍存在另一条未修复路径。

　　③将复核Scan ID、代码位置和结论写回修复记录。问题消失时，还要排除文件退出扫描、查询关闭等原因。

　　3、同时保留存量和新增两份视图

　　①一份清单保留历史未关闭问题，另一份列出本轮需要审查的新增实例，分别关联任务。

　　②导出时记录项目、分支、扫描编号及过滤条件，避免用全量报表总数对比网页中的筛选数量。

　　③更新修复基线前核对未完成任务，保留旧版本，让进入新参照清单的问题继续受到跟踪。

　　总结

　　Checkmarx如何建立漏洞修复基线，Checkmarx基线应用后历史问题仍被列出如何核查，影响着团队能否区分“已经记录”和“已经解决”。保留历史结果有助于继续跟踪风险，新增视图则便于安排本轮审查，两者可以同时使用。把扫描编号、代码提交和处理任务关联起来，后续更换分支或调整查询时，也能解释问题为何保留、为何重新出现。希望这些操作能帮助大家减少重复排查，让修复记录有清楚的验证依据。如有Checkmarx相关需求，欢迎联系我们咨询。