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

　　一、Checkmarx规则怎么分级

　　Checkmarx的规则分级，先看的是漏洞本身的风险高低，而不是业务排期先后。这个顺序要是颠倒了，后面所有讨论都会越聊越乱。

　　1、先认平台原生严重度

　　Checkmarx会给结果分配Severity，常见级别包括Critical、High、Medium、Low、Info。这套等级描述的是漏洞本身的技术风险，适合用来做风险盘点、趋势统计和高危项筛选。

　　2、把每一级的含义讲明白

　　Critical一般对应系统可能被明显攻陷、未授权访问或严重数据泄露的问题。High也是高风险，但通常影响略低一层。Medium和Low更多是利用条件更苛刻、影响范围更有限的问题，Info则偏提示类结果。

　　3、知道严重度可以评审调整

　　Checkmarx支持在triage过程中对漏洞结果做进一步处置，必要时可以结合项目场景对结果做人工判断。这样做不是为了随意改级，而是为了让工具结论更贴近真实业务环境。

　　4、不要把分级和状态混在一起

　　在结果页里，严重度只是一个字段，另外还有状态、负责人、工单等信息。也就是说，一个问题有多危险，和它现在由谁处理、何时处理，本来就是两件事，不能混成一个口径。

　　二、Checkmarx严重度与优先级口径怎么统一

　　真正容易扯皮的，不是严重度本身，而是严重度和优先级总被混着用。想统一口径，最简单的一句话就是，Severity说的是风险，Priority说的是处理顺序。

　　1、Severity只回答有多危险

　　Severity建议直接沿用Checkmarx原生级别，不要在内部再造一套新名字。这样做的好处是报表能直接看，趋势能直接比，安全团队和研发团队看到的是同一套基础语言。

　　2、Priority只回答先修谁

　　Priority代表的是处置优先级，用来决定提单顺序、修复时限和升级管理。官方结果页里本来就把Priority作为单独字段展示，这说明它不是Severity的别名，而是另一层管理口径。

　　3、先定默认映射关系

　　落地时可以先把默认关系写死。比如Critical对应P1，High对应P2，Medium对应P3，Low和Info对应P4。这样项目一看到结果，先有一个默认动作，不会一上来就反复争论。

　　4、再补升降级条件

　　默认映射不是死板照搬，项目上还要补几个统一条件。比如外网暴露、生产环境、核心数据链路、存在明确利用路径时，可以把Priority上调一级。只有测试环境、已有补偿控制、明确不可利用时，才允许下调，而且必须留痕说明。

　　5、统一后只在一个地方改口径

　　最怕的是制度写一套，工单系统配一套，项目群里又口头说一套。比较稳的做法，是先把映射规则写进内部规范，再同步到Jira一类工单配置里，让工具字段和管理规则保持一致。

　　三、Checkmarx项目里怎样真正落地

　　规则写出来不难，难的是每次扫描之后都能按同一套方式执行。想让口径长期稳定，必须把动作固定下来，而不是靠人临场判断。

　　1、扫描完成先做一次初筛

　　先在结果页按严重度筛出Critical和High，再看状态和历史结论，把重复项、已确认项和明显噪音先分出去。这样研发拿到的不是一整包原始结果，而是第一轮整理后的问题清单。

　　2、再做一次统一复核

　　初筛以后，由安全负责人和项目技术负责人一起判断这批问题的Priority。复核时不要只看漏洞名称，要看是不是外网可达、是不是生产路径、是不是涉及账号、支付、隐私或核心接口，按同一张表来决定是否升降级。

　　3、所有改级必须写原因

　　不管是调Severity，还是调Priority，或者接受风险、延期修复，都要在备注里把原因写清楚。这样下次复盘时，团队讨论的是依据，不是重复争论结果。

　　4、报表分成两层看

　　周报和月报不要只看一个数字。第一层按Severity看风险面，第二层按Priority和时限看治理效率。这样管理层能看到风险，研发负责人也能看到执行情况，两个视角不会混在一起。

　　总结

　　Checkmarx规则怎么分级，核心不是把等级做得多复杂，而是把严重度和优先级彻底拆开。严重度负责说明漏洞本身有多危险，优先级负责说明这个问题要多快处理。只要把默认映射、升降级条件、留痕要求和复核动作一起定下来，团队里的口径自然会慢慢统一，后面的提单、修复和报表也会顺很多。