在Veracode里，修复建议要怎么去看，修完了以后又该怎么重新验证结果，这是应用安全扫描落地时很常见的问题。Veracode扫描后会把发现项放到结果页里，开发人员可以围着漏洞类型、严重级别、代码位置、数据流路径和修复说明来拿主意怎么改；如果用着IDE插件或Veracode Fix，也可以在开发环境里看修复指导，或者叫它给出建议的代码修法。官方文档也讲了，在IDE插件里能按发现项去查看问题，并用修复指导或Veracode Fix来处理那些缺陷。

　　一、Veracode修复建议怎么查看

　　看修复建议的时候，别光拿眼扫一下漏洞的名字就算完，很多问题名字看着差不多，可触发的位置、输入的源头、传播的路径，还有最后怎么修，可能压根不是一回事。比较稳的搞法，是先把扫描类型弄明白，再去看发现项的详情，最后搭着代码上下文去断到底该使什么修法。

　　1、先进入扫描结果页

　　在【Findings】或者扫描结果那个页面里，按严重级别、漏洞类别、文件路径和策略状态把要处理的问题筛出来。

　　Veracode文档里讲，结果评审最要紧的就是查看这些发现项，再把该修的毛病给修掉。这一步别一上来就批量处理，高危的、已经碍着策略通过的、刚好蹲在关键业务模块里的，眼光要先搁在它们身上；低风险的，或是老早撂在那里没动的旧问题，可以照着项目自己的节奏分拨来料理。

　　2、查看漏洞详情和代码位置。

　　把单个发现项点开以后，重点去看漏洞归在哪一类、连累到了哪些文件、窝在哪一行、调用链怎么串的、不可信数据头一个从哪冒出来的，还有最末了跑到哪里去了。像SQL注入、路径遍历、命令注入、跨站脚本这类问题，不能只盯着最后报错的那一行，还得去瞅那个不可信数据，到底是从代码里哪个口子钻进来的，中间又被哪些函数给递来递去。

　　3、结合修复指导判断改法

　　如果结果里已经给出了修它的说法，可以先看人家举荐的料理法子，再钻回代码里去断一断合不合得上眼下业务的路数。Veracode的IDE插件文档里也讲，自己动手修的时候，能用那个给的remediation guidance；要是手里还捏着Veracode Fix的许可，还能去用它的建议修法。不过这些修它的建议不能直接照搬，像输入校验、输出编码、参数化查询、权限校验，再要不就是把依赖版本往上升，这些全都得搭着业务的具体情形去断，要不然闹不好，漏洞倒是瞅不见了，可原先跑得好好的功能，里头的逻辑反倒给改坏了。

　　二、Veracode修复后怎么重新验证结果

　　漏洞修好了以后要再验证，可不是在页面上把状态扒拉成“已完结”就算完，是得重新跑一回扫描，叫Veracode自己来认一认，看看那个发现项还在不在。不同的扫描法子，验证的道儿也不一样，静态扫描、Pipeline Scan、SCA依赖扫描、动态扫描，全得照着原来用过的那套法子再从头跑上一遍。

　　1、先确认代码和依赖已经更新

在重新验证以前，得把拿来修漏洞的那些代码，有没有好好交到对头的分支上，完了构建出来的那个玩意里头，是不是也已经换上修过的版本了，这些都给核对清楚。要是碰上SCA扫出来的开源组件漏洞，还得再瞧一眼依赖的版本、锁定的文件，还有实际打出来的包，是不是都跟着一块儿更新过了。要是没做这一步，页面上倒是重新扫了，可拿去扫的对象还是那套没动过的旧货，跑出来的结果自然不会起什么变化。

　　2、使用同类扫描重新验证

　　原来那个问题，是靠着静态策略扫描给揪出来的，那就把修好以后重新构建的包再传上去做一回Static Analysis；原来是在Pipeline Scan里发现的，就在CI里重新跑一回；要是原来是SCA那边的问题，就再去把对口的SCA扫描给执行一遍。Veracode文档也把策略扫描、开发沙盒扫描，还有CI/CD这些不同的场面都给分开了。这么做的好处是跑出来的结果能拿到一块堆儿去比，可别用一种扫描法子找出来的毛病，回过头又用另一种扫描法子就随随便便断它已经关掉了，要不然闹不好就因为扫描范围对不上，叫你验证的结论站不住脚。

　　3、对比新旧结果

　　等重新扫描跑完了，要把那个发现项的编号、归在哪一类漏洞、文件窝在哪个地界、严重级别，还有策略上头的状态，都拿来跟先前的老结果对着比一比。要是原本那个东西就这么不见了，那照常理讲，就是你修补的活儿已经起了效验；可要是它还原模原样在那里杵着，就得去寻思是不是改岔了道儿、构建出来的包压根没更新、那条路就没走到，再要不就是跟它穿一条裤子的同类，还在别的地界照样待着呢。

　　三、修复验证时容易忽略哪些问题

　　在Veracode里头关掉一个漏洞，看着好像就是“改改代码，再扫一回”这么点事，可当真搁在项目里，倒三天两头卡在构建包、分支、扫描配置和误报处理这些事情上。验证的时候，得保着要验的货是同一个东西，拿出来的凭据也得是圆图个儿的，不能光靠嘴皮子去顶替扫描跑出来的结果。

　　1、不要只在本地验证

　　自己机器上跑单元测试倒是都绿汪汪地过去了，可这不等于说Veracode里那个发现项就已经没影了。安全扫描盯着的是一整条囫囵的代码路径、那些依赖的包，还有编译好了拿去给它解剖的对象，特别是Java、.NET和前端要打包的项目，非得盯死CI里头或是上传的那个包里，确实把修过的东西给裹在里头了才行。

　　2、误报或无法修复要走说明流程

　　要是转来调去地瞧，认准了就是工具在那瞎闹是个误报，再要不就是底下框架自己带着保护，第三方代码动不了，再要不就是业务上硬卡在那里不能直接改，撞上这些情形，可以顺着先缓缓、再留个说法下来的章程去走。Veracode文档里也提到，那些打上去的、经过大伙儿点头的mitigated flaws，会照着定下来的规矩，从策略状态和报告单子上另眼相看。可是这个缓解，不是大笔一挥就放过去了，得把到底为着什么、能把多大范围捎带上、又拿了些什么旁的法子去往回找补，还有上头怎么给你画押点头的，这些记证一样不能少，不然挨到后头的审计，就讲不明白了。

　　3、保留修复证据

　　建议把那一套【修复记录】留下来，里头要把原来给发现的货色、动了哪几次提交、挑了什么日子重新扫的、新扫描的结果、回过头再跑回归测试的结论，还有它到底碍没碍着策略通过，全都给包圆了。

　　这么一来，等后头再有人来审安全、版本来往外头放，或是客户那边的审计过来，你就能把当初那个毛病是怎么一针一线缝上的，后头又是怎么验的，给人家说道个一清二楚。

　　总结

　　Veracode修复建议怎么看，修复后怎么重新验证结果，头顶要紧的是头一桩得先把发现项的详情瞧仔细了，完了再搭着修复指导和代码上下文去动手料理。都改完之后，要挑跟原来一模一样的扫描道儿再重新跑一回，跑的时候还得把扫描对象、分支、构建包和依赖版本，全都确认是当下最鲜亮的。对实在没法直愣愣去修的问题，也要走一套叫人管着的、先缓一缓再把话撂下的过场。这么一来，Veracode跑出来的结果才不只是一份干巴巴的告警单子，才能当真变成一根能叫你牵着，去动手改代码，再把安全的环儿给合拢上的实打实的拐棍。