Veracode策略扫描怎么管理Veracode策略不通过时该怎么调整,核心不是单纯地把扫描任务跑完,而是要让扫出来的结果能跟企业自己定下的安全准入规则对应起来。Veracode官方文档里也提到,policy scan是用来照着安全策略去评估扫描结果的,而sandbox就更适合在开发测试阶段使用,不会影响整个应用的策略合规状态。所以在项目里,一定要分清楚:哪些扫描是拿来做日常验证的,哪些扫描是要放到正式的策略判断上去用的。
一、Veracode策略扫描怎么管理
要管好Veracode的策略扫描,一开始就得把应用归在什么地方、用哪种扫描类型,还有策略那边的要求是什么,全都弄明白。不然等到扫描结果跑出来了,团队可能还弄不清楚这到底算正式结果、算测试验证,还是某一次临时拉出来看看的东西。
1、先区分正式扫描和测试扫描
通过【Policy Scan】和【Sandbox Scan】区分正式合规扫描和开发阶段测试扫描。
正式的策略扫描,一般是拿来判断应用有没有够到组织那边给出的安全标准,它的结果会直接牵着应用的策略状态走;sandbox扫描就更适合让开发人员提前去把问题翻出来。把这两样分清楚以后,在开发那一段就可以来来回回地试扫很多遍,不用担心把每一次还没做完的结果都捅进正式的合规判断里面去。
2、策略规则要跟项目的风险配得上
Veracode的策略里面,能按严重等级、扫描类型、CWE类别这些条件去定下一些约束。官方说明里也讲了,一个应用要想从策略这条道过去,里头就不能再带着那些已经达到或是超过了规定严重等级的发现项。
所以策略在刚一开始的时候,不能就给设得过于理想化。碰上那种核心的业务系统,是可以把规矩收得再紧一些的;要是对着那些只放在内部使唤的低风险小工具,就不如先立上一道基础的坎,然后再一小步一小步地朝上抬。策略放得太松了,风险就挡不住;可策略要是定得过严了,项目又容易长时期地卡在通不过的状态里面。
3、扫描结果要定期回过头去看
策略扫描不是做一次就管一辈子的买卖。每逢要发布新版本、重要的依赖被更新了,再不就是代码的结构被动了,这些关口一过,都得重新再去确认一遍扫描结果。尤其是那些长期在维护的项目,老早以前剩下的旧问题也许早就修好了,可新的问题又可能顺着新添上去的功能混进代码里面。只盯住某一次通过了的记录,可并不代表后面再出来的版本也能一直安全下去。
二、Veracode策略不通过时该怎么调整
碰上策略不通过的时候,头一个念头绝不能是去把策略往低处拽。更对路的次序,是先翻出来看看究竟什么原因砸了锅,再去断它是代码自身的毛病、依赖组件那边撂的挑子、工具误报,还是策略本身就不怎么合适。
1、先定位是哪些发现项触发了策略失败
进入【Triage Flaws】或报告中的【Policy Control】相关信息,查看哪些缺陷影响了策略通过。
Veracode的报告会把扫到的问题全列出来,也能叫人瞧见应用在策略控制底下的那副表现。上手处理时别光扫一眼“Policy Failed”这个结论就完了,还得接着往里头看,到底栽在了高危缺陷上头,还是绊倒在哪几个特定CWE上,是引了带漏洞的开源组件,再不就是动态扫描那一边查出的毛病。
2、能修的就抢先去修
要是问题真真打代码本身的缺陷里头冒出来的,那回过头来就该头一个从代码这一层下手去收拾。像SQL注入、命令注入、把敏感信息硬写在里面、使的加密法子不够牢靠、再搭上路径遍历这么些问题,一般都不适合靠着放宽策略来糊弄过去。策略扫描本来的打算就是拦住这些高风险代码,不让它们朝后面的环节里再蹿一步,所以能修的,就该抢在前头给它修了。
3、第三方组件问题要看看有没有升级的路子
要是那些从外头引进的开源组件,再不就是项目倚着的依赖身上带着漏洞才叫策略毙了,那头一步就该去探听探听,是不是已经有了能往上头升一级的版本。Veracode在SCA这一块的处置建议里也点到,那些直接拴在一起的依赖里头的漏洞,凡有可用的修复版本,按说就该优先把版本升上去。可要是碰着一阵子里还找不见能用的版本,到那时再掉头来想能不能替掉这个组件、把使它的范围圈小些,再不就把担着这股风险留下来的凭据白纸黑字记清楚。
4、当真不能修的时候就走缓解流程
总也有些情形,是短时间里实实在在下不去手改它的,像早年搭起的架构它自个儿就框在了那里,再不就是肚里吞了第三方的闭源组件,再不然干脆是工具这边走了眼报了假信,又或者盘算下来动这一刀的成本明摆着已超出了眼下这个版本能扛的限度。碰上这些事,是可以去走那条缺陷缓解的路子的。官方文档也把话撂在了那里,说那些已得着批准暂时就这么搁着的缺陷,会从策略状态的计算里头拿出去,再从头把策略的状态给算过一遍;可缓解到底不是把问题一甩手就当没瞧见,你得把到底为什么、能够搅出多大动静,还有拿什么去往回找补这些道理,一样一样给说清白。
三、Veracode策略调整时要注意什么
动手去调策略这件事,是得揣着几分小心的。策略说到底是安全的一道坎,可不是单为了让报告脸面上好看,就能由着性子拨拉拨拉的配置。调以前,最好先劈开两路:一路是那套规则本身就跟这个项目对不上牙,另一路是代码里当真蹲着风险。
1、不要为一个版本随便去降策略的级
可别单因为某一次发版叫几个高危的刺儿头绊住、没能迈过策略这道坎,就急火火把策略的等级一把头给拽下来,这么一降,后头跟上来的一长串项目可全要给捎带着跑偏了。更妥帖的搞法,是把那些个问题结结实实地修好,再不给那当真能掏出凭据来的问题,单独去走上一趟缓解的路。策略这东西,一经被人松了手,往后再想往起拎、往紧里收,那就要难上许多了。
2、策略变更要留下记录
对照【策略版本】、【变更原因】和【适用应用范围】,记录每次策略调整。
好比把某一类中低风险的毛病从上纲上线的拦截项里拿出来,只搁在跟踪项那边去瞅着,你得把为什么要动它给掰扯明白,到底是频频炸响的误报闹的,还是这类业务骨子里风险就只有那么一丁点儿,再不就是眼下只是捱过一个坎、先过渡一阵子。要是做这一步的当口连个纸片子也没留下,到后头审计或者回头复盘的时候,就很难把当初是凭了什么才放它过去的那套说头给讲明了。
3、把策略扫描挂到发布流程里去
策略扫描最好紧紧拴在CI/CD流水线上,再不就是跟发布前的审批关口挂起钩来。在开发那一段,大可以敞开了用sandbox去提前探路,到了临发布的前一会儿,再把正式policy scan给拉起来跑上一遍。这么走下来,项目就不至于被蒙在鼓里,非得挺到要上线了才发现策略是通的还是堵的,而且也能把那种火烧眉毛了才急着去放宽规矩的情形给减下去不少。
总结
总的来看,Veracode策略扫描怎么管、策略不通过时又该怎么扳回来,骨子里那一下是把正式策略扫描、开发测试扫描、缺陷修复、缓解审批和策略变动一宗一件撕掳清楚。策略没过的时候,先瞪眼看准到底是哪几项在底下作祟;能下手修的就抢在前头修,是依赖那头撂的挑子就抢着去把版本往上抬一抬,等真到了扳不动、改不得的田地,再顺着缓解那条道往下走。策略自己当然不是铁板一块动不得的,可要紧的是每回动它都得有一圈明白的界,还得跟在屁股后头把底子留瓷实了,万万不能单为了叫某一次顺顺溜溜淌过去,就随手把安全那道大闸给拉了下来。