在Veracode里头，漏洞的评级要怎么看，还有那些漏洞的优先级，又该照着什么来给它排一排先后，光去盯着页面上那一个严重的等级，是不大够的。Veracode在扫描跑完了以后，会把漏洞的严重程度、它属于哪一类、窝在哪个地方、策略上是个什么状态，这些个信息都给列出来，团队这边真正要做的，是要把这些个信息，跟业务上受不受影响、是不是亮在了外头、修起来麻不麻烦，全搁在一块堆儿去琢磨。官方的数据字典里头也说了，Veracode做静态分析的时候，常用S0到S5来表示严重的程度，S0是那种信息类的，S1是很低的，S2是低，S3是中，S4是高，S5就是很高了。

　　一、Veracode漏洞评级怎么看

　　Veracode给出来的这个漏洞的评级，顶大的用处，就是拿来断一断风险的高和低，可它也不是唯一的一杆尺子。一个高危的漏洞，要是它刚好落在了核心认证、付钱、用户数据处理这些个模块里面，那它的优先级，照理说就是要往前头排一排的；一个中危的漏洞，要是反反复复地、大量地往外冒，那也是能拉低整个应用的评价的。官方的说明里头也提过，一个应用，有可能因为几个高风险的缺陷，再要不就是攒下了一大堆中等风险的缺陷，最后就给了一个不怎么样的评级。

　　1、先看严重程度这个等级

　　严重程度的等级，是顶直接的一个入手的地方。S5跟S4这两个，一般是得抢在前头，先给对付了的，S3呢，就得结合当时的具体情况再去断一断了，S1和S2，按平常的路数，是可以排到常规的修补计划里头去的。S0这玩意儿，多半就是个提醒，不该把它跟正儿八经的漏洞搅和在一块儿去排先后。到这儿要留心一件事，等级的数字越是高，可不代表你立马就能修好，可它至少是在告诉你，这个东西，得提到前头，先去掂量掂量。

　　2、再看策略是不是通过了

　　在【Policy Evaluation】那个地方，要去看一看，应用它是不是因为挂上了某些漏洞，就没能迈过安全策略那道坎儿。

　　Veracode的安全策略，是可以设下一些条条框框的，就比如说，在某些扫描类型里头，不准有达到事先定好的严重度及以上的发现项。反过来讲，要是一个漏洞，它弄得策略都失败了，那轮到处理它的时候，它的优先级，一准儿是要高过那些个还排在那里等修的普通货色的。

　　3、结合漏洞的类型来断风险

　　一样的，都是顶了个高危的帽子，可不同的类型，带来的影响是不一样的。像是认证给绕过去了、SQL注入、命令注入、敏感信息给漏了、危险的反序列化，这一号的问题，骨子里就比那些平常写代码闹出来的质量毛病要更扎手。在看漏洞的时候，可别光拿眼睛在它的标题上停一停就算完了，还要去瞅瞅它的CWE类型、数据是顺着什么路子流过来的、叫它给波及到的文件，还有人家建议的，那个能把它给修好的法子。

　　二、Veracode漏洞优先级应该怎么排序

　　给漏洞的优先级去排个先后，一个比较实在的法子，是先去对付那些“严重程度又高、露在外头的面又大、还要去动到核心业务”的麻烦，等把这些个给料理了，再掉过头来，去归置那些个影响面比较窄、修起来也花不了多大代价的中低风险的问题。可别就闷着脑袋，照着那一长串的清单，从上往下挨着改，要不然，很有那个可能，你起先一头劲儿地修掉了一堆小毛病，到头来，那些个真正会卡住发布的大问题，还原封不动地杵在那里。

　　1、先排那些卡住策略的东西

　　要是有些个漏洞，它把事情闹到了，应用就这么直挺挺地卡在了安全策略上，过不去了，那这一号的，一般是得把它给摆到最顶上去的。因为这类东西，会直接捅到发布的门禁、给客户交货，再要不就是内部的审查这些个事情上去。特别是那些S4、S5的，再要不就是策略里头明令不准有的漏洞类型，就该叫它头一个进到修补的计划里头去。

　　2、再排那个能被利用的可能，还有露在外头的面

　　搁在对外的接口、登录的口子、文件上传、付钱的接口、管理后台、API网关这些个地方的漏洞，比起那些个藏在内部的工具页面，或者是权限很低的后台页面里的，那是肯定要先下手去办的。一个漏洞，它能不能被外头的人够着，是不是非得登录了才能碰，还是说随便一个普通用户就能把它给点着了，这些个东西，全都会影响到那个实实在在的优先级。

　　3、关注那些依赖库的漏洞。

　　要是SCA扫出来的，是藏在开源组件里头的漏洞，那就要去想想，是不是有个能用的、升级的版本。Veracode官方的建议是，直接依赖的组件里头要是真有漏洞，那头一件事，就是把它给更新到推荐的那个版本；可要是，连一个靠得住的、能拿来修的版本都找不见，那说不定，就得往上游那边去递个修它的帖子，再要不，就是干脆把那整个组件给换掉。

　　三、Veracode漏洞处理怎么形成闭环

　　给漏洞排那个前前后后的座次，这不过是刚迈出去了头一步，到了后头，还得能去把它给证明出来，那个毛病，是真真地，已经叫人给收拾好了。好些个团队，栽跟头的地方，倒不是他们压根儿没去修，而是那个修补的记录、回头再扫一遍跑出来的结果，还有策略上那个状态的变化，这一串的东西，它就没给串到一根绳上去，等到末了，审查的人过来一问，还是两眼一抹黑，讲不利索。

　　1、把漏洞给分成几个处理的批次。

　　是可以照着，那些会卡住发布的、最近一阵子就要修掉的、排在计划里头等着修的，还有那风险就横了心先认下来的，这么几类，给它分门别类地归置归置。高危的，还有在策略上栽了跟头的，就给拎到发布前头去料理，中危的呢，就照着模块，还有版本的那个节奏，去给它排排日子，低危的那些个，就可以把它们给并到那一堆技术欠债的计划里头去。这么样一来，比起光是在那里扯着嗓子喊一句“全都给我改了”，是更容易落到地上去的。

　　2、把修复和复扫的结果给留下来。

　　在【Triage Flaws】那个地界儿，再要不就是报告里面，要记得去把漏洞它眼下是个什么光景、你打主意怎么去摆弄它、是在哪一个版本上给修掉的，还有回头再扫一回，得出来的那个结论，都给一笔一笔地记下来。

　　要是那个漏洞，是已经叫你给收拾好了的，那就得能瞧见，新跑出来的那一份扫描的结果里头，它再也不冒头了；要是你横看竖看，觉着它是个误报，再要不就是心甘情愿把这风险给吞了，那也得掏出一套道理来，还要有那个谁点了头、画了押的凭据，搁在那里才行。光是在代码里头动了动手脚，可是到了平台上头，却没个回头再扫一回、给它点个头的印子，那你这一整条的证物链，它就还是豁着口子，拢不拢的。

　　3、不要只按严重的程度来机械地排序

　　严重程度这玩意儿，它是个打底子的根基，可是呢，也还得去把业务系统它是个什么量级、数据敏感不敏感、在网络上是敞着多大的口子、有没有那种已经满天底下都传遍了的、能拿去祸害它的现成路数、修起来要搭进去多大的本钱，还有你预备在哪个节骨眼上把它给往外头放，这些个，全都得捆到一堆儿去寻思。你就拿一个中危的漏洞来说，它要是就蹲在了那个核心系统、朝着外头开着的那个大门口上，那它说不定，就比一个窝在里头的、低风险的、可脑门上却顶着高危牌牌的东西，要更该被提前弄去修了。

　　总结

　　总起来讲，在Veracode里面，漏洞的评级要怎么去看，那些漏洞的优先级又该怎么去排，这里头最要紧的，是头一步，先去瞧那个严重的程度跟策略上是个什么动静，完了以后，再把漏洞是哪一类的、业务上会给它搅和成什么样、暴露出去了多少、修起来是顺手还是扎手，全都揉到一块堆儿，去给它定个先后。S4、S5还有那些个把策略给捅穿了的项，这一般都是要搁在前头，赶着去办的，那些个能被外头人够着的、会动到核心数据的，再要不就是跟认证那条线搭着边儿的问题，也是要提早给它排上日子。