上面这个图就是本文重点要跟大家分享的DevSecOps最佳实践的流程图，也就是如何把应用安全很好地嵌入到我们的整个流程里面去。

首先，在开发的这个闭环中，开发人员在IDE开发代码的同时，我们就可以将应用安全测试嵌到开发工具里。具体例子，比如说我们在eclipse上，通过安全工具的插件，把安全审计的功能嵌入进去。

IDE里就多了一些菜单和选项，能够让我们在开发的时候就可以做相应的安全的检查。这样的检查是自查，这时候开发人员并没有提交代码。

当然这里也涉及到企业文化，比如开发人员说“我没空去做检查，我的职责是实现软件功能，我可能没有时间和精力去做安全测试”。这时候应该怎么办呢？我们还有一些插件是可以实时检测的，就是每写一行，就同步告诉你，你写的这一行有没有安全问题。

不需要开发人员再花时间去做安全测试，而是实时地去检查代码。我们可以称之为“安全小助手”，帮助我们做代码的检查。当然最好还是做全面的检查，去做安全测试，当然要花一些时间，比如可能我们需要在下班的时候开启一个扫描，第二天上班的时候再去看扫描结果。

代码提交到仓库之后，这个时候，我们需要通过Jenkins去做CI/CD了，在这个时候去做安全测试也是非常好的。因为这个时候我们已经形成一个版本了，模块也已经完成了，可以把完整的项目代码拉出来，做一个完整的、全面的安全扫描测试。

这一部分在我们的用户实践里面是最广泛的，比开发人员自查自检要广泛。因为很难保障开发人员自己去检查自己的问题，因为没有一个机制强迫开发人员去做这个事情。但是在CI/CD阶段，流程里肯定是要加这个环节，这是必须要做的一件事情。

测试完成之后，我们的测试结果要自动传到可视化的漏洞安全管理平台上去，我们需要将测试结果可视化，而且需要很方便就可以看到。而且也可以通过专门的相关的人员，如审计员，去把这些测试结果里面确定的bug，提交到Jira这类缺陷管理平台里面，做跟踪和管理。直到开发人员把这些问题修复掉，bug关掉了就算结束了。

我们在下一轮再去做扫描，验证是不是已经被修复了，再做一次测试。而且这种上线之前的自动化测试不仅仅是针对源代码的安全测试，还可以模拟黑客，对web应用做漏洞扫描。

这一点也是目前比较新的理念，大家对黑盒测试的理解往往是上线之前最后阶段才测，但是我们建议在CI/CD阶段应用发布的时候就可以去做一次模拟黑客的web漏洞扫描了，这是可以做到的。我们后面也会讲到，黑盒测试是可以再左移到CI/CD阶段的。

然后在问题修复完成之后，才能保证上线。上线之后，在生产环境中，我们的安全防护也是必不可少。当然，我们现在更多的是部署WAF、web应用防火墙这种边界的防御。但是未来的大方向我觉得还是RAST技术，应用的自我防御。因为WAF产品毕竟是网络边界产品，有很多威胁防御不了、发现不了。从应用本身内部去发现和监控问题，这一定是未来一个大的方向和趋势。