/catalog/296695a3fdd74f71b4ced1996c9b6856//Document/304898482892869.html/Document/304549706600517.html/Document/304188584996933.html/Document/303818784497733.html/Document/302700517105733.html/Document/302416475320389.html/Document/302077848256581.html/Document/301288627347525.html/Document/300279638184005.html/Document/274792263872581.html/Document/273024381308997.html/Document/272683642789957.html/Document/272351623921733.html/Document/271961406242885.html/Document/271560844214341.html/Document/270477420015685.html/Document/269881559916613.html/catalog/c51244b85e704db9a2a34ca396e9fe27//Document/297463116619845.html/Document/296410729726021.html/Document/294281412902981.html/Document/289614801383493.html/Document/289336711553093.html/Document/288989717336133.html/Document/267736666357829.html

可知、可视、可管——DevSecOps落地的终极目标

前面的文章我们为大家介绍了DevSecOps的全部流程、如何合理地将安全测试融入到各个阶段中,以及静态代码分析工具、黑盒测试工具的推荐,本文继续为大家介绍,除了白盒测试、黑盒测试,还有哪些策略可以帮助我们提高应用安全?

软件测试管理

还有一个很重要的方面是第三方开源组件的测试,像前段时间的Log4J,还有前两年的心脏出血之类的事件都属于开源组件的问题。


做Java开发写log基本上都要用到这个组件,这些组件的问题其实都不是业务层面程序员的代码出现了问题,而是底层出现了问题。


所以我们不但要保证开发人员写的代码是安全的,同时还要保证代码依赖的、引用的开源组件也是安全的。所以我们的安全测试需要全面,代码扫描不只是扫描本身编写的代码,代码依赖的底层的依赖库、公共库也要保证安全。


这里我们推荐的Sonatype工具,可以帮助我们很好地发现公共的开源组件的问题,而且还可以跟Fortify相结合,既扫源代码,又扫依赖库,这样才是最全面的。

安全测试管理

最后我们讲一下软件安全中心的重要性。工具的本身是负责测试的,这些测试是针对某一个特定项目的测试结果,我们要做好整体的视图,把不同的工具、不同阶段的测试结果由一个统一的安全管控平台做可视化的展现。


没有绝对的安全,安全做得再好,也不能解决100%的问题,但是我们要做好安全的“可知”、“可视”、“可管”。


“可知”指我们测试完之后,发现了一些问题,知道问题在哪儿,漏洞在什么地方,在代码的哪一行,该怎么改。


“可知”还不够,还要“可视”,需要有一个可视化的平台,统一地去做展现。比如说领导层,他并不关注漏洞的代码怎么改,他想看到的是整体的安全状况。哪些漏洞在企业中存在最多,哪个项目问题最多,哪个项目组问题最多等等。对于程序员来说,想看到的点就是微观层面了,自己负责的代码有没有什么问题,问题在哪里,怎么改。


“可知”、“可视”之后,才能够“可管”,我们才能够很好地去管理企业的应用。