另外一个普遍的现象是，虽然有不少常见的安全措施可以采纳，但其实大多数企业依然是在依靠防火墙来阻挡攻击，用渗透测试来暴露安全漏洞。随着安全挑战的变化，这些传统措施的抵御力越来越低。

　　防火墙的主要职责是阻挡攻击，为开发团队争取修复漏洞的时间，而并非取代漏洞的修复工作。换言之，只要应用中导致安全问题的代码没有被修复，漏洞就会一直存在，一旦防火墙规则被绕过，或者配置不当，反而会将应用置于更高的安全风险当中。此外，j2直播，误报和漏报始终是防火墙无法彻底解决的问题。

　　至于上线后的渗透测试，它确实能发现安全漏洞，但是也存在着明显的不足。通常而言，渗透测试会被安排在应用上线发布之前进行，此时如果检查出安全漏洞，企业反而会面临两难的境地：修复安全漏洞之后再发布应用可能导致项目延期，错失市场机会；如果强行发布含有安全漏洞的应用，又将提高被黑客攻击利用的风险。

　　为了更好的应对新的安全挑战，做好应用的安全防护势在必行。不过，在介绍具体做法之前，让我们先看看为何企业采纳了众多安全措施，可开发出来的应用中依然存在不少安全漏洞，就像顽疾一样无法彻底根除。

　　应用中的安全漏洞是在开发过程中由于各种原因被引入的，然而回顾现有的安全措施就会发现，许多措施并没有被作用于开发过程中。例如防火墙、安全监控发生在应用上线之后，渗透测试需要在开发完毕后才能进行，而安全培训、安全规范只能起到预防作用。正因如此，安全问题从引入到被发现，间隔很长，使得安全问题不能被及时的反馈给开发团队。

　　建议的做法是，在开发团队中建立起一个高效的安全反馈机制，在开发过程中引入安全活动，尽早开始收集安全反馈信息，加快获取安全反馈的速度，在整个开发过程中持续关注应用的安全性，与此同时团队成员共同来承担安全职责。ThoughtWorks将这些在实践中总结出来的经验命名为©Build Security In DnA（下文简称BSI，），从源头上尽早、尽快、持续性的、以团队共同协作的方式发现并解决安全问题。

　　图2：Build Security In 内检安全基因

　　越早获取到安全反馈信息，越有利于开发团队以更低的成本将其修复。与其依赖于项目后期的渗透测试，不如在开发过程当中引入一些适当的安全实践，比如在分析业务需求的同时主动分析安全需求，将其作为质量验收标准在团队内明确出来，再比如，对代码进行安全评审、测试人员在测试业务功能的同时还对安全性进行验证。通过这种方式，使得团队能够尽快的知应用的安全状况，而不必依赖于很晚才能提供安全反馈的渗透测试。

　　图3：在开发过程当中引入安全实践

　　对于常规的安全测试完全可以借助工具以自动化的方式进行，不仅能够以更快的速度得到安全性反馈，还能在一定程度上弥补由于人员安全技能不足所造成的安全测试不够全面的问题。此外，自动化带来的另外的好处是，它可以集成入CI服务器，从而让开发团队可以利用CI流水线在第一时间发现应用的常规安全问题并及时修复。

　　收集安全反馈不是一次性的活动，高效的安全反馈机制和持续集成秉持相同的理念：除了尽早集成、尽快集成之外，很重要的一点就是让集成活动能够持续性的发生。类似的，对于建立高效的安全反馈机制而言，在能够尽早、快速的获取安全反馈的同时，还需要让这个反馈循机制在应用开发过程中持续地运行下去。

　　图4：对安全保持持续性的关注

　　我们将BSI在多个大型金融企业里进行了实践探索，而在实施BSI的过程中，我们遇到了各种各样的挑战，其中比较典型的三个如下：

　　挑战一：安全活动排不上高优先级