Checkmarx报告里字段多、扫描引擎多，最容易出现两类问题，一类是同一字段在不同引擎里含义不同导致误读，另一类是团队各自标注状态与归因口径不一致导致复扫后又打回。把字段解释和状态归因规则一次定清楚，你的报告结论才会稳定可复核。

　　一、Checkmarx报告字段怎么解释

　　看Checkmarx报告字段，建议先按扫描引擎分层，再按字段类别理解，先把共通字段讲明白，再补每个引擎的专有字段。这样你拿到任何一份导出表或平台列表，都能快速判断字段是在描述风险强度、复现证据、还是处置状态。

　　1、Severity字段表示风险严重度分级

　　Severity用于表达漏洞风险等级，平台常见分级是Critical、High、Medium、Low、Info，并且允许在分诊时调整严重度以贴合你方风险场景。

　　2、State字段表示处置状态而不是是否再次出现

　　State用于表示你们对该条风险的处置结论，常见选项包括To Verify、Confirmed、Urgent、Proposed Not Exploitable、Not Exploitable，Not Exploitable通常代表已确认不可利用或误报并会影响结果展示口径。

　　3、Status字段多用于区分New与Recurrent

　　在部分结果视图中，Status用于表示该漏洞是New还是Recurrent，也就是新出现还是再次出现，容易和State混淆，建议你在内部口径里把Status固定翻译为出现状态，把State固定翻译为处置状态。

　　4、Confidence字段表示结论可信度或利用把握度

　　Confidence常用来表达对该漏洞在当前代码上下文中可利用性的把握度，文档中给出了0到100的分值含义与计算思路，你在对外汇报时可把它作为风险排序的辅助信息，但不要用它替代处置结论。

　　5、Instances字段表示同类漏洞实例数量

　　Instances通常表示同一漏洞类型在目标范围内出现的实例数量，适合做集中治理的工作量估算，但在复核时仍需要回到具体实例路径确认是否是同一根因或同一修复点。

　　6、Evidence、Path、Query一类字段用于解释为什么被报出

　　SAST结果通常会提供代码高亮、攻击向量路径、查询规则等视图信息，Path类信息用于展示从入口到风险点的链路，Query用于说明检测规则来源，复核时优先用这些字段判断可达性与数据是否可控。

　　二、Checkmarx状态与归因口径怎么统一

　　状态和归因不统一，最直接的后果是复扫后同一问题在不同人手里被标成不同结论，或者一条问题在不同模块之间来回扔。统一口径的关键是先把状态定义成可执行规则，再把归因固定到可追溯对象，并把范围生效层级设成团队共识。

　　1、先把State五种常用状态写成团队定义并绑定使用场景

　　To Verify用于待确认，Confirmed用于确认需要修复，Urgent用于需要优先处理，Proposed Not Exploitable用于拟定误报待复核，Not Exploitable用于已确认误报或不可利用并按平台口径影响统计展示，定义写清楚后再允许个人选择，避免用词随人变化。

　　2、把Status固定解释为New与Recurrent并写入复扫规则

　　把New定义为本轮首次出现或首次被识别，把Recurrent定义为历史出现且本轮仍出现，复扫时先看Status判断是否修复生效，再看State判断是否需要再次确认或升级优先级。

　　3、把误报相关状态强制要求填写说明并纳入审核

　　当你把结果状态改为Not Exploitable或Proposed Not Exploitable时，平台支持要求填写说明并记录变更日志，建议你把说明字段作为必填门槛，说明至少包含不可达条件或防护点位，避免误报结论无法复核。

　　4、统一处置范围层级，先决定按Project还是按Application生效

　　同一条结论到底只影响当前项目还是影响整个应用层面，需要在账户配置里明确结果范围层级，默认常见是Project级别，若你们按应用统一治理，应把范围层级调整到一致并写入流程，避免同一结论在不同项目里重复标注。

　　5、归因先统一到两级对象，修复归属与根因归属分开写

　　修复归属建议以代码仓库路径或服务模块为主键，确保能落到负责人团队；根因归属建议以风险点文件与关键调用链为依据，SAST优先以风险点所在函数与路径链路做根因归因，DAST优先以URI与证据字段做根因归因，这样工单不会在团队间反复流转。

　　6、需要更细的状态体系时用Custom States但先锁定映射关系

　　如果你们要对接既有流程，例如已分派、已修复待复测、延期处理，可用Custom states扩展状态，但必须提前规定每个自定义状态对应到哪一种处置动作与复核要求，并确保报表统计与门禁判断只依赖明确的映射集合。

　　三、Checkmarx报告复核与交付怎么做

　　把字段解释和状态归因统一后，还需要一套可重复的复核与交付动作，确保每次出报告都能在同一口径下快速定位阻断项、形成处置闭环，并且复扫后能解释为什么变成New或Recurrent。

　　1、建立一份Checkmarx报告字段字典作为交付附件

　　字段字典至少包含Severity、State、Status、Confidence、Instances、Evidence、Path的中文解释与使用规则，并标注哪些字段用于统计，哪些字段用于复核与举证，避免不同读者按各自理解解读同一份表。

　　2、复核时先筛选Confirmed与Urgent再看To Verify

　　在结果列表里先按State筛出Confirmed与Urgent，优先处理会进入阻断或高优先级队列的条目，再处理To Verify，拟定误报类先集中复核再批量推进审批，减少反复切换上下文。

　　3、对拟定误报统一走说明加复核加审批三步

　　第一步在标注为Proposed Not Exploitable时填写说明并引用证据，第二步由非提交人复核Path或Evidence确认不可达或已防护，第三步再改为Not Exploitable并保留变更日志，保证误报结论可审计。

　　4、工单化交付时把归因字段与链接入口写进同一条记录

　　把修复归属团队、文件路径、风险点行号、State与Status一并写入工单，并在平台中按支持入口创建或关联缺陷跟踪系统工单，避免只发PDF导致处理过程不可追踪。

　　5、复扫验收用Status与严重度继承规则做对照

　　复扫后先看原问题是否变为Recurrent，若仍是Recurrent说明修复未覆盖或出现回滚，再核对你们调整过的严重度与处置状态在复扫后是否按平台规则保持一致，确保历史治理成果不会被新扫描冲掉。

　　总结

　　Checkmarx报告字段解释建议先抓Severity、State、Status、Confidence、Instances、Evidence与Path这几类核心字段，再按扫描引擎补专有字段。状态统一要把State与Status分清，并把误报类状态的说明与复核做成硬规则，同时统一处置生效范围与归因主键；最后用一套固定的复核与交付动作把结论沉淀到工单与变更日志里，复扫时就能用同一口径解释New与Recurrent并快速闭环。