在上一篇文章《敏捷精益团队面临的三大安全挑战》中，我们对现如今敏捷精益团队所面临的安全挑战进行了总结和分析，这三大挑战分别是：
- 一次性的安全检查无法匹配持续性的交付模式
- 缺乏自动化、自助化的支持，安全实践落地难
- 高耸的部门墙让开发和安全团队难以进行高效的协作
在接下来的几篇文章中，我们将逐一为你介绍团队、组织应该如何应对这些挑战。本篇文章先来讲讲如何解决第一个挑战。
原则：采用持续性的、轻量级的，能够融入到持续交付模式的安全活动
对于绝大多数团队而言，为了确保开发出来的应用具有足够的安全性，渗透测试是一个被广泛采用的手段，也可以说是唯一依赖的手段。然而由于渗透测试比较重量级，通常只能提供一次性的安全反馈，而这在追求快速开发、迅速响应市场变化的敏捷精益开发方式下，它的不足被放大了。
团队需要的是一个高效的安全质量反馈机制。所谓“高效”是指，这个机制必须能以更快的速度、更高的频率提供应用的安全质量反馈，并且要足够轻量级以便于无缝融入到迭代交付过程中。
那么“更快”是多快？多频繁才算“更高的频率”？“轻量级”要轻到什么程度？快到“立等可取”，比如只需几分钟甚至更少时间，就能知道应用的安全质量如何；频繁到任意时刻都可以获取一次安全质量反馈，比如每次代码提交后，都能知道应用安全质量是否被破坏；轻量级到团队不认为这些安全活动会带来多大的额外付出，比如每日代码审查中，顺便从安全的角度对代码进行评审，就能阻止有安全风险的代码被提交到代码仓库，而整个过程可能只多花费了几分钟时间而已。
一些推荐采用的安全活动
在CI中集成自动化安全扫描工具
其实在很早以前大家就已经发现，凭借人工的力量从应用里寻找安全漏洞异常耗时，另外对于某些安全漏洞，完全可以通过特征识别的方式通过脚本来自动进行检测，于是从那时起就诞生了一系列自动化安全扫描工具，以下简称“漏扫工具”。
与此同时，在应用开发这件事情上，持续集成、持续交付的理念也在迅速的被广泛接纳，越来越多的团队开始使用CI，也体会到了自动化的威力所带来的好处。
随着CI的广泛普及，团队完全可以把这些漏扫工具集成到CI当中，作为应用构建过程中的一个标准步骤来执行。这样，团队既可以借助漏扫工具以节约人工成本，又可以持续性的对应用安全质量进行监控：一旦某次构建发现安全问题，构建流水线就会失败，引起开发团队的注意，促使团队尽快对有问题的代码进行修复，从而降低漏洞修复成本。
漏扫工具数量众多，可以说是百家争鸣，不过可惜的是，易于集成到CI中的却不多。OWASP ZAP提供了RESTful API，也有Jenkins插件，算是做得比较不错的漏扫工具，而BurpSuite要做到同样的效果还需要额外的配置才行。推荐团队可以先尝试把ZAP集成到CI中。关于具体的集成细节，我们会通过后续文章进行介绍。
编写自动化安全功能性测试用例
漏扫工具不是全能的，有些类型的安全漏洞，比如身份认证、访问控制以及和业务强相关的漏洞，它就很难甚至根本无法扫出来。然而，这些漏扫工具不容易扫出来的安全漏洞，对于人来讲却正好是小菜一碟。
举个例子，人能够很好的理解下面这个API应当具备的安全行为，并对其进行有针对性的测试，然而漏扫工具则已经哭晕在厕所：
API：
/api/customers/{customer_id}/orders
期待API的安全行为：
- 若请求未通过身份认证，则拒绝当前请求。
- 在请求通过身份认证的前提下：
(a) 若当前用户的角色是CUSTOMER，那么如果当前用户ID和URL中的custoemr_id不匹配，则拒绝当前请求。
(b) 若当前用户的角色是SALES_MANAGER，那么如果URL中的customer_id所指代的用户不在该SALES_MANAGER的所管辖范围内，则拒绝当前请求。
漏扫工具检查不出来的安全问题，人可以很好的进行测试，并且依然通过自动化来提高效率。团队可以像平常编写集成测试，或者端到端功能性测试那样，对于期望应用应当具备的安全行为，编写对应的测试用例进行覆盖。我们把这种做法叫做编写自动化安全功能性测试用例。
随着自动化安全功能性测试用例数量的不断累积，它的威力也将越来越明显，尤其是在对应用进行回归测试的时候，更是显露无疑。通常而言，在团队每次做应用发布之前，都会进行一次回归测试，主要目的是为了确认新功能工作正常，与此同时已有功能未被破坏。安全作为应用质量中的重要组成部分，也应该进行一次回归测试。相比于传统的渗透测试，自动化安全功能性测试用例再配合上CI中的自动化漏扫工具，在很短的时间里就能对应用进行比较全面的安全检查，为应用发布提供决策支持。
识别安全需求，并将其作为验收标准写入到用户故事卡
如果说把漏扫工具集成到CI，以及编写自动化安全功能性测试用例是在“把事情做对”，那么识别安全需求，并把它作为验收标准写入到用户故事卡中则是在“做正确的事情”。
团队其实是很重视安全的，他们愿意付出努力提升应用的安全性，然而这又和我们实际观察到的现状有冲突：安全的事情大家心知肚明，但就是没人主动去做。为什么？原因是多方面的，其中一个重要的原因是，因为安全需求没有被明确提出来，它既不在故事卡的验收标准里，也没有在给故事卡估点的时候考虑进去。于是安全需求就仿佛变成了“多出来的”工作量，一旦团队面临交付压力，这部分工作自然就会被无限期的往后推迟，最后的归宿就是不了了之。
因此，团队除了需要借助漏扫工具以及自动化安全性功能测试用例，还需要把安全需求明确出来，纳入到项目交付范围内。团队可以用威胁建模、恶意攻击场景头脑风暴等活动来梳理安全需求。
此外需要注意的是，安全需求的表现形式不是最重要的，最关键的在于把需求在团队内部明确出来，而不是大家心照不宣。比如，安全需求是写入到故事卡的验收标准里，还是单独创建安全故事卡，这本身并不重要，重要的是安全需求通过这些形式能得到明确，让团队能把安全需求和常规的业务需求一起放到Backlog里，统一对它们估点、设置优先级、安排迭代交付计划。
小结
敏捷精益团队面临的第一大安全挑战就是一次性的安全检查无法匹配持续性的交付模式。应对这一挑战，团队需要采用一系列持续性的、轻量级的，能够融入到持续交付模式的安全活动，从而使得团队建立起一个高效获取应用安全质量反馈的机制。
至于敏捷精益团队如何应对另外两大安全挑战，我们将在后续的文章里一一详解，敬请期待。