在临近发布、缺陷短期内又修不掉，业务方希望先走风险接受流程的时候，常常会碰到Veracode的缺陷缓解要怎么提交，还有万一交上去的记录审核没通过，又该怎么处理的问题，做缓解这件事，它的目的，并不是要把一个漏洞给硬说成没问题，而是要解释明白，为什么当前这个缺陷，在一种特定的场景底下，它的风险是可以被控制住的，又或者说，是要说明白，已经有了什么样的补偿控制手段，能够去把那个风险给降下来。Veracode的缺陷缓解，通常是在缺陷分诊那个页面里去操作的，那些已经被批准通过的缓解缺陷，会被从策略的状态，还有一部分报告的明细计算里面给移出去，但是，在跟缓解有关的那些页签，或者是附录里面，还是会留着记录的。

　　一、缺陷缓解要怎么提交

　　在往Veracode里去提交缺陷缓解之前，得先分清楚，眼下这个缺陷，它到底应该是拿去修掉、当成误报来处理，还是可以被拿来提交一次缓解，要是代码里面，那个风险是确确实实存在的，仅仅就是因为排期来不及了，才想着去缓解它，那么在写说明的时候，就必须要把临时控制的手段，还有后续打算怎么去处理的计划，都给交代明白，可不能就只丢下一句“业务上接受了”便不管了。

　　1、进到缺陷的列表里面去

　　登录进Veracode的平台，进到对应的那个应用，还有它扫出来的结果里面去，在分诊缺陷的页面里，去照着严重的级别、缺陷分类的类型、是哪个模块里的、在哪个文件的路径下、还有对策略的影响，去把你需要处理的那些缺陷，给筛出来，可以先从那些，会影响到发布，或者是会影响到策略合规的项目，开始着手处理。

　　2、去核对一下缺陷的上下文

　　点开一个缺陷的详情，去瞅一眼它的数据流、是在哪个文件里的、对应的是哪个方法、到底是在哪个点上被触发的，还有Veracode自己给出来的那个修复的建议，在动手去提交缓解之前，得先确认好了，这个缺陷的位置，你没有给看岔了，特别是，当同一个类型的缺陷，同时出现在了好几个文件里面的时候，可不要手一抖，把给A位置写的那些解释，给贴到了B缺陷的头上去。

　　3、去选好缓解的动作

　　在缺陷操作的那个区域里，去选上提交缓解，或者是跟它类似的这么一个操作，然后，就按照平台界面上的提示，去把缓解的类型，还有详细的说明，给填进去，在这个说明里面，要把缺陷的原因、对风险的判断、现在已经有的那些控制手段、拿来验证过的证据，还有它适用的范围，都给写清楚了，要是这其实是个误报，那就要去讲明白，为什么那条路径根本就是走不到的、输入的东西早就被校验过了，又或者，是在它实际跑着的那个环境里面，压根儿就没有能触发它的条件。

　　4、把它提交给做审核的人

　　等这些信息全都填完了以后，就把这条记录给提交上去，等着那个被指定的审核人，或者是专门管安全的团队，来对它进行审查，Veracode这边，也是提供了API的方式，可以用它去对着一个，或者是好几个缺陷，来执行像写评论、提交缓解、接受或者是拒绝缓解，这一类的动作，这个接口，比较适合拿去跟公司内部的流程系统，做集成用，但是，对那种普普通通的项目来说，还是在平台的界面上，去直接处理，看着会更直观一些。

　　二、缓解记录审核没通过该怎么办

　　Veracode的缓解记录，审核要是没有通过，这通常倒不是系统本身出了什么问题，而是人家看完以后，觉得你给出的那套说明，撑不起最后那个关于风险的结论，来做审核的人，他们更在意的，是证据充不充分、你说的那个控制措施到底有没用、影响的范围有没有被讲清楚，而不是看你写的字，到底够不够多。

　　1、先去看一眼被退回来的意见

　　进到对那个缺陷的缓解记录里面去，看看做审核的人，他给出来的拒绝原因到底是什么，比较常见的几种意见有，证据还不够、描述写得太笼统了、当成误报的理由站不住脚、补偿的控制手段没有经过验证、适用的范围讲得不清不楚的、还有，就是说到底，还是得去把代码给修掉。

　　2、去把那种能被验证的证据，给补上

　　可不要只是把说明，给改成了“这个东西已经被确认是安全的”，就完事了，你是可以往里面去补充，像代码的片段、配置文件里相关的截图、用来校验输入的那段逻辑、关于权限控制的说明、网关上的规则、WAF上的策略、测试跑出来的结果，还有日志的记录，这些材料的，但是，补上去的证据，它得能跟眼前的这个缺陷，实实在在地对应上，可不要拿那种系统通用的、大而化之的安全策略，来替代掉针对这一个点的具体说明。

　　3、重新去把风险的判断给写一遍

　　在缓解的说明里面，应该是去写清楚，那条用来攻击的路径，它到底是不是真实存在的、要触发它，得满足一些什么样的条件、攻击者他得拿到什么级别的权限才行、可能会受影响的数据范围有多大，还有，你现在已经有的那些控制措施，到底能在哪一个环节上，把攻击者给拦住，要是风险，确实只是被降低了一些，但是并没有被彻底地消除掉，那就要把剩下来的那些风险，还有你计划在什么时候去修掉它，都给明确出来。

　　4、到了必要的时候，就干脆转成去修复

　　要是做审核的人，觉得你交上去的这个缓解，根本就不成立，那就别再去反反复复地，把同一套说法，换着花样地往上交了，这个时候，就应该把这个缺陷，直接转给做开发的人，让他们去改代码，等改完了以后，再去重新跑一次扫描，看看结果怎么样，缓解这个东西，它比较适合的场景，是拿来做一个短期的风险控制，或者是去说明一下为什么是个误报，它并不适合，被拿来当成是长期替代修复的一个方案。

　　三、缓解记录要怎么样才能写得更稳当

　　一份能让人觉得稳当的缓解记录，它最核心的一点，就是要让那个来做审核的人，能够顺着你写的那些说明，一步一步地，去把你当时做判断的那个过程，给重新走通一遍，有不少的记录被退回来，其实倒不见得是你的结论真的就错了，而是那个过程，你没有把它给讲透，结果别人，就根本没法去判断，你这个结论，到底是怎么给得出来的。

　　1、要对着缺陷，一条一条地去写

　　可不要把好几个不同的缺陷，全都给塞到一段，看起来完全是一模一样的说明里面去，就算是它们对应的缺陷分类是一样的，可具体到文件路径、入口的参数，还有控制的手段，这些东西，也都可能是千差万别的，就算你觉得可以合并在一起说明，那也得把，这段说明所能覆盖到的，那些缺陷的范围，都给一条一条地列出来。

　　2、要把误报，和那种对风险的接受，给区分开

　　说一个东西是误报，那你是得去证明，这个缺陷，在实际跑着的代码，或者是运行的那条路径上，它是不成立的；而说一个东西，是对风险的接受，那你首先就得承认，这个缺陷，它是确实存在的，然后再去解释清楚，你有哪些补偿的手段，还有，剩下来的那个风险，到底还有多大，要是把这两样东西给写混了，那是很容易，就被做审核的人，给退回来的。

　　3、不要去写那种空泛的结论

　　像“内部系统嘛，风险总是比较低的”、“已经在安全上做过控制了”、“这东西是不会被人利用的”，这种说法，是不太够用的，你应该把它，给写成一种非常具体的控制，就比如，这个接口，它是只允许内网去访问的、想要调它，得先拿到管理员的权限才行、传进来的参数，是经过了白名单校验的、那个有危险性的函数，它吃进去的输入，是根本没办法被用户给控制的。

　　4、要把复审的记录，给保留下来

　　就算是缓解被通过了，也要去把对应的版本、是哪一次扫描的批次、缺陷的ID、是谁批准的，还有批准的时间，这些都给记录下来，因为到了后面，一旦代码发生了变化、接口暴露出去的范围变了、或者部署的环境也调整过了，那么原来那套用来缓解的理由，就有可能不再成立了，到了那个时候，就需要去重新复核一遍。

　　总结

　　关于Veracode的缺陷缓解要怎么去提交，还有万一交上去的记录，审核没有通过，后面又要怎么去处理，这里面最关键的地方，就是要把缺陷待的那个位置、你对风险的判断、打算用什么手段去补偿控制，还有能拿出来的证据说明，这几点全都给写得明明白白，在提交的时候，要先进到分诊缺陷的页面，去把缺陷的详情给打开，确认了它的上下文没有问题以后，再去把缓解的理由给填上；等发现被退回来的时候，也别慌，先去看一眼审核给出来的意见，然后再去照着它，把证据补上、把影响的范围讲得更清楚一些、再把验证的结果也给附上去，那些能够被修掉的缺陷，当然还是应该优先去修掉它，而对于那些确实需要走缓解流程的项目，也一定要让留下来的记录，能够经得起后面安全评审，还有发布审查的再一次追问。