企业面临的安全挑战已经发生改变
如今，越来越多的企业选择部署移动技术和数字化来强化自己的业务，传统的业务模式在新的技术革命中面临新的安全问题和挑战。这些挑战集中体现在如下几个方面：
第一，固守网络边界安全难以达到预期的效果。传统的安全思路是，在网络边界实行严格的访问控制、部署网络防火墙、***检测以及***防御系统等，企业以为这么做足以高枕无忧，但实则是被安全的假象所包围。近年来，******进入企业内网，绕过网络防火墙，通过IT系统漏洞获取最高执行权限、下载敏感数据，种植***病毒等***事件层出不穷。
更何况，随着云技术的快速发展和大量使用，传统的企业网络边界正变得越来越模糊，这势必给固守边界安全这种方式带来更大的挑战。
第二，应用防火墙存在天花板效应。和网络防火墙侧重在网络层做防御有所不同，应用防火墙则是在应用层入手，扮演门卫的角色以保护IT应用。但随着企业在数字化道路上的不断前行，企业IT应用数量和业务复杂度都在持续增长，这使得管理维护应用防火墙安全规则的难度也在不断加大。当这种难度大到难以掌控的时候，应用防火墙便遇到了天花板，例如谁也不知道某条安全规则为何存在，谁也不敢轻易去修改安全规则，谁也不敢添加新的安全规则，因为有可能会对正常访问造成误杀等等。此时本来是为企业安全保驾护航的应用防火墙，反而成了企业数字发展的瓶颈。
除了安全规则的管理维护难度大之外，无论是网络防火墙还是应用防火墙，都无法彻底解决漏报和误报的问题。误报对用户体验是种伤害，然而更为严重的是，由于安全的特殊性，一次漏报就有可能造成后续的安全事件。
第三，在提倡持续交付、DevOps以及通过MVP基于市场反馈进行快速改进的开发部门面前，偏好实施安全控制和审计的传统安全部门无法跟上开发部门的快速开发节奏。随着敏捷精益、持续交付、DevOps等理念和技术的发展，开发部门可以做到一天之内数次发布产品。例如，早在2014年的时候，亚马逊平均每秒就有一次以上的产品部署，每天如此。在这种情况下，安全部门如何跟上开发团队的速度？如何在快速变化当中了解即将发布的IT应用的安全情况？
这些挑战使得安全成为了企业数字化转型中“最薄弱的一环”，在日益复杂的未来环境中面临严重风险。大部分企业认为自己有能力抵御网络***，可实际情况是，企业安全问题已经迫在眉睫，很多安全公司对企业安全是持悲观态度的。
安全领域的资源投入出现了严重错位
根据企业规模和行业的不同，安全在IT投资中的占比也不同。一般而言安全投资的比例会占到5%-8%，金融行业略有不同。大部分的资源被投入到了IT基础设施安全（例如，网络、服务器、数据安全）。而安全风险越来越突出的应用安全方面，却存在着严重的不足。
伴随投入占比失衡的问题，更加突出的是安全技术的变化，现在的安全威胁已经由传统的病毒***、系统漏洞、缓冲区溢出***转变为虚拟机安全，激动安全，APT***，DDoS***等。这些***带来的安全风险和威胁也随之加剧。比如携程网信用卡泄露事件，从表面上看是Web页面上的漏洞所致，漏洞的产生主要是由于产品在其App端调试的过程中便开发了整个目录的遍历，由于开发过程中安全控制不足，上线后***能够巧妙的绕过服务器的权限访问到文件系统的其他部分。此次安全漏洞可导致用户个人信息、银行卡信息等泄露。由于发现及时，最后得以控制和限制。但这件事给越来越多的成长中的企业以警示。使得更多的企业在面临数字化创新、求新求变的同时，将安全放在重中之重的地位。
金融行业是安全风险和***出现的重灾区，以银行行业为例，银行为了更多地吸引客户和方便客户，开通了网上银行业务，由于任何用户都可以通过互联网访问业务系统，因此网上银行系统存在来自互联网各种***的安全风险，这种风险在P2P行业盛行的中国尤为突出。
安全风险和对应的投资呈现出严重错位
企业中的绝大多数数据访问都是通过应用程序进行访问的 。根据Gartner统计，现有的***中80%的网络***也是发生在应用层。面对新的安全形势，企业若不采取有效措施加以应对，应用程序中的安全漏洞一旦被公之于众，必将对业务造成破坏性影响，使企业陷入竞争不利的局面。一般应对此类安全问题的措施是采用应用层防火墙做一些基础性的防护，系统性地测试和扫描所有应用，通过特征库来区分安全威胁和风险，这种控制的方式存在误报率高、问题发现不彻底的缺陷。要解决应用层安全的问题，最佳的方式是在软件开发的过程中，根据软件和应用的特性，在应用开发的过程中解决安全风险。
另外一个普遍的现象是，虽然有不少常见的安全措施可以采纳，但其实大多数企业依然是在依靠防火墙来阻挡***，用***测试来暴露安全漏洞。随着安全挑战的变化，这些传统措施的抵御力越来越低。
防火墙的主要职责是阻挡***，为开发团队争取修复漏洞的时间，而并非取代漏洞的修复工作。换言之，只要应用中导致安全问题的代码没有被修复，漏洞就会一直存在，一旦防火墙规则被绕过，或者配置不当，反而会将应用置于更高的安全风险当中。此外，误报和漏报始终是防火墙无法彻底解决的问题。
至于上线后的***测试，它确实能发现安全漏洞，但是也存在着明显的不足。通常而言，***测试会被安排在应用上线发布之前进行，此时如果检查出安全漏洞，企业反而会面临两难的境地：修复安全漏洞之后再发布应用可能导致项目延期，错失市场机会；如果强行发布含有安全漏洞的应用，又将提高被******利用的风险。
数字化企业，需要注入安全基因
为了更好的应对新的安全挑战，做好应用的安全防护势在必行。不过，在介绍具体做法之前，让我们先看看为何企业采纳了众多安全措施，可开发出来的应用中依然存在不少安全漏洞，就像顽疾一样无法彻底根除。
应用中的安全漏洞是在开发过程中由于各种原因被引入的，然而回顾现有的安全措施就会发现，许多措施并没有被作用于开发过程中。例如防火墙、安全监控发生在应用上线之后，***测试需要在开发完毕后才能进行，而安全培训、安全规范只能起到预防作用。正因如此，安全问题从引入到被发现，间隔很长，使得安全问题不能被及时的反馈给开发团队。
建议的做法是，在开发团队中建立起一个高效的安全反馈机制，在开发过程中引入安全活动，尽早开始收集安全反馈信息，加快获取安全反馈的速度，在整个开发过程中持续关注应用的安全性，与此同时团队成员共同来承担安全职责。ThoughtWorks将这些在实践中总结出来的经验命名为©Build Security In DnA（下文简称BSI，http://www.buildsecurityin.net），从源头上尽早、尽快、持续性的、以团队共同协作的方式发现并解决安全问题。
Build Security In 内检安全基因
越早获取到安全反馈信息，越有利于开发团队以更低的成本将其修复。与其依赖于项目后期的***测试，不如在开发过程当中引入一些适当的安全实践，比如在分析业务需求的同时主动分析安全需求，将其作为质量验收标准在团队内明确出来，再比如，对代码进行安全评审、测试人员在测试业务功能的同时还对安全性进行验证。通过这种方式，使得团队能够尽快的知应用的安全状况，而不必依赖于很晚才能提供安全反馈的***测试。
在开发过程当中引入安全实践
对于常规的安全测试完全可以借助工具以自动化的方式进行，不仅能够以更快的速度得到安全性反馈，还能在一定程度上弥补由于人员安全技能不足所造成的安全测试不够全面的问题。此外，自动化带来的另外的好处是，它可以集成入CI服务器，从而让开发团队可以利用CI流水线在第一时间发现应用的常规安全问题并及时修复。
收集安全反馈不是一次性的活动，高效的安全反馈机制和持续集成秉持相同的理念：除了尽早集成、尽快集成之外，很重要的一点就是让集成活动能够持续性的发生。类似的，对于建立高效的安全反馈机制而言，在能够尽早、快速的获取安全反馈的同时，还需要让这个反馈循机制在应用开发过程中持续地运行下去。
对安全保持持续性的关注
实施BSI的挑战
我们将BSI在多个大型金融企业里进行了实践探索，而在实施BSI的过程中，我们遇到了各种各样的挑战，其中比较典型的三个如下：
挑战一：安全活动排不上高优先级
企业完全认同IT应用的安全性是数字化战略中不可或缺的一部分，但是具体到BSI实施落地层面，却发现安全活动排不上高优先级，总是会被各种原因不断的往后延期。其中一个常见的说法是，开发团队面临着很大的交付压力，要在规定的发布日期到来前完成计划中的业务功能已经实属不易，没有充足的时间执行安全活动。
出现这样的情况并非是因为开发团队不清楚安全的重要性，这背后潜藏的原因是，某些传统安全活动给开发团队留下了一些不太好的印象，比如说，需要耗费开发团队比较多的时间，或者某些传统安全活动过程繁琐、流于形式，难以产生实际有效价值。再加上实现业务功能永远是开发团队的第一优先级，因此安全活动难以推进执行也是必然的结果。
从我们的实战经验来看，要解决这一挑战，企业可以精心挑选一个试点团队，将其打造成BSI的样板工程，以成功案例的方式让更多的开发团队进一步了解BSI，明白它能够最大限度的借助自动化，提高开发团队在安全活动上的投入产出比，用相对而言更少的时间，更有效的提高IT应用的安全性。
挑战二：传统安全团队的焦虑
传统的IT应用安全运作模式是，每次IT应用在发布上线前，开发团队将其交给安全团队做扫描，安全团队将扫描结果汇总成安全报告并提供给开发团队做修复。在这一模式中，安全团队报告的安全漏洞数量越多，严重性越高，越能体现出自身的价值。
而在实施了BSI后，开发团队承担了更多的安全职责，将原本由安全团队才有能力报告的安全漏洞及时发现并修复了，这使得传统安全团队感到一丝焦虑。想象一下，如果某次安全扫描后，没有在IT应用中发现任何安全漏洞，安全团队到底是应该欢喜雀跃，还是黯然神伤？
BSI是IT应用安全发展的必然趋势，在这个大趋势下，安全团队需要重新思考和调整自己的定位，将关注点从安全漏洞数量，转移到为开发团队提供自动化、自助化的安全服务上来。
挑战三：安全活动如何可视化？
在实施BSI的过程中，我们经常被开发团队问到的一个问题是：我们做了这么多安全活动，仅仅只是我们自己知道它非常有帮助是不够的，如何才能把它可视化出来？
BSI中的每个安全活动都有着明确的产出物，我们可以通过收集整理这些产出物，将其作为基础，通过图表的方式进行可视化。比如，威胁建模会产出一系列安全需求，它们会随着开发的进行逐个被实现。在这一过程中，开发团队可以将当前已完成的安全需求、未完成的安全需求的数量以燃尽图的形式展示出来。再比如，开发团队可以持续统计通过自动化安全测试发现的安全漏洞数量，依然以图表的形式进行可视化。
通过BSI安全成熟度模型来对企业或者某个开发团队的安全实践进行评估，并且将其结果可视化出来也是一个不错的选择。不仅如此，企业还能通过这个办法，从中识别出当前面临的安全短板，为开发团队设立安全改进目标提供帮助。
在数字化革命面前，金融企业业务的正常运转必然将高度依赖于IT应用的可靠运行，IT应用的安全性将对企业产生重大影响。企业有必要通过BSI这种内建安全的方式，尽早发现安全问题，利用自动化的优势缩短安全问题的反馈周期，持续的、以共同协作的方式主动预知并化解安全问题。