在DevSecOps实施方案中，过去的sDLC实施方案将被遗弃，安全和开发不再是两个完全隔离的环节，安全能力被嵌入到开发的整个生命周期中，这种能力会逐渐左移。在此期间，APP安全测试将更加多样化。在以DevSecOps方法为引导的新一代应用程序开发环节中，APP安全测试不再仅仅依靠过去的黑盒测试和白盒测试，安全测试方法将更加多样化。交互式灰盒测试(iast)将逐渐流行起来，成为提高漏洞检测率和降低漏洞误报率的重要环节。
安全能力的渗透范围将扩大。在过去的sDLC中，安全能力只关注编码阶段的白盒检测和测试阶段的黑盒检测。虽然大部分安全问题都是在这两个环节发现的，但是从软件安全修复成本的角度来看，并不是一个好的解决方案。如果在安全需求分析阶段能够尽可能考虑所有的安全风险，并给出相应的威胁模型和解决方案，那么后续软件修复的成本将会大大降低。在DevSeFeps中，安全能力的渗透主要表现在安全需求讨论阶段的威胁建模和分析，安全编码阶段的组件检测服务和代码检测服务，安全测试阶段的多样化安全测试方法(白盒、黑盒、灰盒)，以及APP上线后持续的安全风险监控。
自动化势在必行。许多公司的安全部门都有许多自己开发或购买的APP检测服务产品，但这些产品通常是分布式的，由相应的安全人员处理。未来，sDLC将逐步走向自动化，安全检测工具将不再分散，而是集中管理，统一安排在一个平台上，检测服务将趋向于更加自动化。
安全联动使1+1>2。所谓安全联动，就是每个环节的安全能力不再只对这个环节负责，而是通过能力反馈和激励的方式影响上下游环节。在回顾过去一年里，理想的汽车安全部门DevSecOps集团也在DevSecOps上做了许多实践。作为DevSecops系列文章的开始，这里我将简要介绍一下我们在静态白盒检测方面所做的许多事情.
还没有评论，来说两句吧...