Gartner 2017调研报告:DevSecOps应当做好的十件事(下)

前文:《Gartner 2017调研报告:DevSecOps应当做好的十件事(上)

(4)不要固守传统的静态/动态分析方法,应当适应新的变化

在上一节中,我们强调了识别已知的组件、库和框架中的已知漏洞的重要性,但是对于应用程序中那些实际存在的10%~40%的自定义代码该如何处置呢?执行DevSecOps,意味着你应该寻找自定义代码的未知漏洞。但是,不要固守那些传统的针对应用程序安全测试的静态和动态分析工具和服务,要明白这些传统的测试解决方案需要被重构、调整或更换,具体步骤如下所示:

  • 可以从把简单的测试直接集成到IDE开始。一些开发者提出基于IDE的安全扫描的指标无法被跟踪和报告,这可能成为与DevOps建立合作伙伴关系的契机。
  • 所有的扫描工作应该是完全自动化的,在开发者的CI/CD工具链和诸如代码提交之类的事件处理过程中自动的通过APIs的方式触发,通过API引发开发商的CI / CD的工具链和过程事件像提交代码。第三方产品(如Cybric和BMC)可以帮助开发者实现安全检测自动化。
  • 扫描不应该要求安全专家运行、配置或解释结果,开发者就可以做到。
  • 扫描应该不断调整,以减少误报,即使是牺牲假阴性(漏报增多)。
  • 扫描结果应直接运送到bug跟踪系统或开发者面板,这依赖于开发者使用的CI / CD工具和方法。

无论执行哪种安全扫描,SRM负责人都应该按风险把发现的漏洞进行优先级的排序,并提供给开发者。工作重点应放在减少误报,在充分信任开发者的基础上指导他们优先修复严重的漏洞。正是因为这个原因,几个AST供应商正在尝试使用机器学习来修正扫描结果。接受较低风险的漏洞是可以的,这些漏洞可以通过运行时的保护控制来减轻,或者在将来的软件迭代中加以解决。

考虑交互式应用安全测试(IAST)替代传统的静态应用安全测试(SAST)和动态应用安全测试(DAST)是可行的,我们建议这么做。IAST是在DAST基础上的一种该进形式,测试过程更加可视化,包括内部和外部的。IAST综合了DAST和SAST的优势,在确保测试代码覆盖率的基础上尽可能的做到了减少误报。然而,目前支持IAST的平台有限,需要应用程序在运行状态下才能执行IAST。如果IAST工具