在Checkmarx里，漏洞分派怎么去设，还有分到开发手里以后怎么跟下去，好多团队把安全扫描接进来以后，都会撞上这个问题。扫描结果出来了，要光靠安全的人在平台里翻报告，开发那头根本闹不清该修哪条、什么时候修、修完又怎么认，那漏洞管理这档子事，就死死地卡在“发现”这一步上了。Checkmarx One能看扫描结果、管漏洞，也能走API、Webhook这些门道去跟外头的流程接上；SAST结果查看器，也就是在项目代码里认漏洞、管漏洞用的。

　　一、Checkmarx漏洞分派怎么设置

　　动手分派以前，先得把项目、应用、开发团队和代码仓库这几样的关系给理顺了。别一上来就把所有漏洞都怼到某一个开发头上，要不然到了后头，责任搅成一锅粥，还容易冒出重复分派、谁先修谁后修全乱了套的麻烦。

　　1、先照着项目和模块把责任划开

　　漏洞分派，头一个就得看代码到底是谁的。比方说，登录认证那块儿、支付那块儿、后台管理那块儿、公共组件，还有接口层，要是分别归不同的人管，那分派的时候，就该按模块或者仓库路径来。安全的人可以先粗筛一遍，把误报、翻来覆去的重复项、还有风险不大的毛刺先挑出来，剩下的，当真要动手修的毛病，再推到对口的负责人那儿去。

　　2、在结果页里把漏洞信息坐实了

　　在SAST Results Viewer那个地界儿，得瞅一眼漏洞是啥类型、有多严重、窝在哪个文件、数据流是咋淌过来的，还有修它的法子。这一步不是拿眼扫扫标题就算完，是要去认准了，这漏洞它是真真杵在那儿的，对眼下的业务逻辑，到底能不能碍着事。Checkmarx的SAST结果查看器，能给一张漏洞表，还有一个能看代码的地儿，这么一来，从漏洞单子再摸到代码的上下文里头，就方便不少。

　　3、搭着外头的系统把分派办了

　　实际干活的团队，一般会把Checkmarx跑出来的结果，同步到Jira、Azure DevOps、GitLab Issue，再不就是自己公司里头搭的管缺陷的台子上去。这么着，开发的人用不着天天去安全台子上探头，在自己手头正干着的任务趟子里，就能瞅见要修的漏洞。分派的时候，顶好是把漏洞编号、文件路径、严重到啥份儿上、修它的法子、打算在哪个版本里收拾，还有回头再扫一遍的规矩，都交代得明明白白的。

　　二、Checkmarx漏洞分派到开发人员后怎么跟踪

　　漏洞派出去了，后头要紧的，不是“派没派出去”，而是那个东西，它到底待在个啥光景里，还能不能瞧得见。一个漏洞从揪出来到关上，顶起码得走上这么几道坎儿：先得有人认了它，跟着才是动手去修、把改的东西交上去、再回过头来扫一遍，末了才能合上。这中间要是没个地儿把光景记下来，到了后头，再想闹明白它是真修掉了，还是就在管任务的家伙什儿里叫人随手划拉掉了，这就难了。

　　1、先把一套转状态的规矩立起来

　　能把漏洞的景况，分成等着人认、等着人去修、这会儿正修着呢、等着回头再扫一遍、已经关严实了，再要不就是把这点凶险先这么认了。安全的，就管认漏洞跟认那回头再扫的结果；开发的，就管动手改代码；能拍板管事的，就管排先后的趟子，还有那风险到底是修还是不修，得他点头画押才算。状态越是弄得清爽，就越不容易闹出那种“安全说没修、开发说早改了”的罗圈架。

　　2、拿回头再扫一遍的结果，去坐实它到底修没修

　　等修补的活儿干完了，得重新去戳咕它一把，叫它再跑一遍扫描，拿着那簇新的结果，去认一认那个窟窿还在不在。Checkmarx One能叫你去跑扫描，再去瞅结果，它那API也能伸把手去管漏洞、瞧结果，所以团队大可以把这回头再扫的果子，接进流水线，再要不就是塞进管毛病的台子里去。光是在交代码的时候甩一句“fix security issue”，那是不扛事的，非得拿着回头再扫的凭据，证死了那东西再也冒不出来了，才算作数。

　　3、多留神那些一个娘胎里出来的雷同货色，还有那从根子上就一样的毛病

　　有些窟窿，别看它在单子上沥沥拉拉排了老些条，其实说不准，全是从一个公用的函数、同一套滤东西的章法，再要不就是同一截少了进门查验的关隘里头生出来的。Checkmarx的结果里头，也有那么一手本事，能揪着埋在下头的、一模一样的淌法，把那些你修上它一个，就捎带手能撂倒一大片的货色，先挑出来。跟在后头盯的时候，可不能光知道照着数目往下硬压活计，也要多寻思寻思，是不是有哪个节骨眼儿，你把它摆弄好了，就能叫一大串警报都跟着消停下来。

　　三、Checkmarx漏洞分派怎么避免流于形式

　　好些个团队，栽跟头的地界儿不是压根儿没分派，而是派完了就没了下文，没人去把那个环儿给真真拧上。窟窿活计倒是进了管毛病的家伙什儿里了，可后头没个人去张罗着回头再扫；开发嘴皮子一碰，丢下句“这就是个误会”，手里头却连一丁点站得住脚的凭据都拿不出来；安全脖子一梗，说这口锅我认了，可审批单子上，连个拍板人的影儿都没有。这些光景，全会叫这套管窟窿的把式，变得跟纸糊的一样。

　　1、给那些悬乎的高风险窟窿，掐死一个修它的期限

　　高危的、要命的、叫外头人能摸着门儿的、会去捅认证跟敏感数儿的，得给它定下更短的拾掇日子。中不溜的、风险不大的，倒是能照着版本更迭的趟子去对付，可也得给它划下一道明明白白的死线。要不然，那些个不咋起眼的毛刺儿，在那里堆呀堆的，日子一长，等到了后头再有人来审你，也够你喝上一壶的。

　　2、要把认下了风险、不打算去修的记证，留得妥妥的

　　要是有些个窟窿，当真是暂且还不去动它的，那你就要动动手，把它到底是为着个啥，给写成白纸黑字。就比方说，是工具看走了眼、那一段码子压根儿跑不到、是人家第三方的家什儿你连根毛也动不了、再要不就是祖上传下来的老架子，你一碰它就要散，这些个由头，后头全都得跟着能叫人信服的理儿，还有拍板子的人落下来的印子。可不能就在那干活的单子上，大笔一挥写上“暂不料理”就蒙混过去了。

　　3、照着定死的趟子，去往外头端那跟在后头撵的报表。

　　要围着窟窿的数目、有多悬乎、都压在了谁头上、有没有在那儿赖着过了日子头的、回头再扫是个啥光景，还有真给拾掇利索的到底占了几成，去拢几张能叫人看个大概的报表来。在Checkmarx One那一揽子报告里头，能把扫描的信息，还有照着不一样扫法给规整出来的果子提要，都给亮出来，这东西拿来在分了段的时候拢个总账，再合适不过。报表倒不是图花里胡哨好看，是要帮整个团队揪出来，到底是哪一个模子里头窟窿扎了堆，又是哪个背事的人，他那肩上的担子快把脊梁骨压断了，还有哪些窟窿，是那割了又长、长了又割的老油条。

　　总结

　　Checkmarx漏洞分派怎么去设，分到开发头上又该怎么去跟，顶要紧的头一桩，就是先照着项目、模块和代码归谁，把各人的担子都画明白，完了再把窟窿的事，一股脑儿挪到开发天么天都在里头摸爬滚打的干活家伙什儿里去。等撒出去了还不算完，后头还得靠着那一套叫它从这头转到那头的景况章法、回头再扫的实打实凭据、认了栽的记证，还有隔三差五往外头端的报表，死死咬住了，跟在后头撵。管这些窟窿，万万不能就在扫完拉倒的报告上画死句号，非得是把揪出来、派下去、修利索、再扫一遍验明正身，到临了给它把门关严实了，这么一整套环儿都给严丝合缝地串到一根绳上，Checkmarx扫出来的这些果子，才算是一头扎进了开发那条顺顺当当转起来的趟子里头去了。