应用安全不能只依靠防火墙，必须要在应用开发阶段采取适当的安全控制措施，使得应用在发布上线前就具备较好的安全性，避免人为失误造成安全隐患。
不少企业早就意识到了这一点，然而理想和现实之间还隔着几十个安全漏洞，尤其是那些采用敏捷或者精益开发模式的团队，在具体的实践过程中，几乎无可避免的会遭遇到下面几个挑战。
挑战1：一次性的安全检查无法匹配持续性的交付
为确保团队开发出来的应用具有足够的安全性，最常见的选择是对其进行全方位的安全渗透测试。无论这样的测试是由企业自己的安全团队执行，还是购买外部第三方服务，最终都会得到一份详细的安全报告，团队接下来需要做的就是基于这份报告所揭露的漏洞，对应用进行相应的调整，直到安全漏洞被修复为止。
持续交付是敏捷、精益开发团队的核心能力之一，这意味着团队可以做到每周甚至任意时刻发布产品，持续性的从真实环境中获取市场反馈，然后基于这些反馈对产品进行调整。一个可以参考的案例是，早在2014年的时候，亚马逊平均每秒有一次以上的产品部署，每天如此。
与此同时，安全渗透测试却没有这么高的“交付”速度。由于渗透测试的特殊性，虽然有大量的自动化漏洞扫描工具可以使用，但是一次全面、高质量的渗透测试依然需要人工参与，几天甚至一两周之后才能得到测试报告是普遍现象。
那么问题来了，一方面开发团队持续性的每周都有新功能上线和旧功能调整，另一方面渗透测试却没办法在这么短的时间里完成，它只能是阶段性、或者定期性的进行，例如每个季度测试一次。
这种情况下，开发团队该何去何从？如果要安全，那么就得等着做渗透测试，而且一旦发现安全漏洞还要花额外的时间去修复，产品发布必定会延期。如果要效率，那么就只能冒着风险发布，因为谁也不知道当前应用有没有安全漏洞，万一被黑客发现并且加以利用，后果不堪设想。
问题的关键在于，开发团队是在持续的发布应用到生产环境，然而渗透测试却是个相当耗时的一次性活动，它没办法跟上这么快的交付速度。
挑战2：缺乏自动化、自助化的支持，安全实践落地难
开发团队其实明白安全对于应用而言至关重要，也知道在开发过程中就应当通过运用各种安全最佳实践来主动消除安全问题，把安全风险降至最低。不过现状却是，不少安全实践要么无法落地实施，要么有流于形式的倾向。
一个真实的案例
一个开发团队在做完业务需求梳理后，立即进入了开发阶段。安全团队虽然在项目启动时提出过安全要求，例如要求团队采用威胁建模活动，识别出应用面临的安全威胁，并制定应对措施。然而由于该项目交付压力大，时间紧任务重，再加上团队成员对于威胁建模并不熟悉，最后这个活动被一拖再拖，直到应用开发完毕进行上线前的审批时，才发现没有做威胁建模，而此刻为了能让应用按时上线，只好回过头来临时补一份威胁建模的文档，仅用于应付安全部门的要求。这种情况下，安全威胁根本得不到全面的分析和应对，风险由此而生。
在项目前期的设计阶段是进行威胁识别的最佳时刻，开发团队只要在这时做一次威胁建模，就能识别出潜在的安全风险，并且在接下来的开发过程中采取适当的措施加以应对。但是开发团队却仿佛是懒癌晚期患者，硬是拖到上线前才把威胁建模补上，而此时它早已失去意义。
为何开发团队一边认同安全的重要性，一边却又对安全实践如此怠慢呢？本质原因在于，某些安全实践需要大量人工参与，或者对人员安全技能有很高的要求，与此同时又缺乏自动化、自助化的支持，因此在开发团队看来，这些实践的采纳成本太高，在面临交付压力的情况下选择性的忽略，或者认认真真的走个形式，就成了再正常不过的结果。
挑战3：高耸的部门墙让开发和安全团队难以进行高效的协作
随着敏捷、精益开发模式的普及，再加上DevOps转型的助推，不少企业已经开始组建全功能开发团队，团队中各个角色有着共同的目标，相互协作以更高的效率交付应用。但是安全团队却依然隶属于一墙之隔的安全部门。
别小看了这堵墙，说它是万恶之源有点太夸张，但它的存在确确实实阻碍了企业实现其业务价值最大化。墙的这边，开发团队竭尽所能的以最快的速度完成应用开发，以求尽快上线获取反馈；墙的另一边，安全团队只关心应用是否安全，至于是否急着上线，那不是他们关心的问题。但是他们都忽略了一个事实，那就是企业的成功需要两者共同高效的协作。
小结
敏捷、精益团队一方面要保持快速的交付速度，一方面还要提高应用的安全质量，看上去这是鱼和熊掌不可兼得的事情，然而事实上我们依然有办法解决这些挑战。
开发团队可以通过自动化，显著降低安全实践的实施难度和成本，把一次性的安全检查转变为持续性的安全质量反馈。对于安全团队，也应当向着开发团队迈进一步，打通开发和安全部门之间的隔离，以更加紧密和高效协作的方式，共同确保应用具备更高的安全质量。
