如上图，以用户故事为单元，所有的用户故事都会经历一个从分析到最后给客户演示的生命周期，多个用户故事组成一个Feature，然后我们会进行Feature的功能测试，给客户展示整个功能，最后在发布之前，客户会邀请第三方的专业安全公司做渗透测试，然后找我们的开发团队修复安全缺陷。

　　那么这种方式有什么问题呢？

守门员模式，安全测试非常滞后

安全问题的修复时间非常有限

只有少数人关注和了解安全

依赖独立的渗透测试

　　所谓守门员模式，指的就是把所有的问题和风险都留在最后，靠少数人来保障，在当时的开发模式下，第三方的安全公司就是我们系统的安全守门员，可想而知，如果我们的团队对安全没有任何了解，在用户故事的开发阶段引入的安全问题要等到发布之前才能够被发现，安全测试是非常滞后的，反馈周期特别长。

　　另外当第三方的安全公司发现问题，留给我们团队修复问题的时间特别有限，因为渗透测试是发布前的最后一个阶段，长时间的修复又会导致发布延期，所以经常会导致安全修复以补丁的方式发布。

　　而且除了少数修复过安全缺陷的开发人员对安全有一点点了解之外，团队内是没有人关心安全的。

　　最大的问题是，所有的安全防范都依赖于最后的独立渗透测试。虽然因为执行渗透测试的是专业的第三方安全公司，他们有专业的安全知识，可以发现很多公共的安全问题，也可以提供专业的极具权威性的安全报告，但这种方式的渗透测试有个致命的弱点，他们对业务知识了解不够，很难发现跟业务相关的安全问题，而这一类的安全问题又占了相当大的比重。

　　可以看到，这种敏捷开发模式的现状就是：试图将安全注入一个已经成型的系统中。

　　安全落地尝试

　　那么了解了之前开发模式存在的问题，安全又这么重要，客户和团队都希望可以改变这种现状，提高安全质量，减少补丁，让每一个人都关心安全，但是我们都担心安全需要巨大的投入，会影响功能的发布，所以我们决定选择一个Feature小组做为安全试点，目标周期为一个月（我们的发布周期），观察投入产出比，然后决定是否要在整个团队实行。

　　首先我们小组开始学习BSI，我们认为它所传递的是这样一些理念：

将安全融入整个软件开发过程中

所有团队成员一起为安全负责

安全的设计和实施一个持续进行的过程

　　那么在一个几乎没有安全知识储备的团队中，如何将以上理念在团队应用呢？我们遇到了很多的困难，比如：

不知道怎么把安全和日常开发结合起来

不知道如何编写安全需求，怎么做安全测试

接受了很多安全培训，不知道如何下手

对安全缺乏专业的认知,对安全开发和测试没有信心

不知道如何满足客户期望

　　分析这些困难，我们开始迈出了艰难的第一步。

　　首先，召集团队的核心成员（包括了业务分析师，开发人员，测试人员，技术主管），同时我们邀请了公司的一位安全专家帮我们解答难题，大家头脑风暴，参考OWASP TOP 10， 结合曾经项目上出现过的安全问题以及对于业务领域的深入了解，尝试总结属于我们自己的安全问题项目并且和OWASP TOP 10进行关联，比如我们讨论后的成果是这样的：

　　可以看到，我们总结出来的这十项并不是将OWASP TOP 10调换顺序这么简单，我们是针对业务需求，有针对性地进行了重新整理和组织，比如其中的Sensitive Data Exposure，我们就结合项目将它划分成了四类（1.Authentication，2.Error Handling，3.Code Leak，4.Cookie Management），之所以会划分的这么具体，是因为我们自己的TOP10更贴近实现。另外我们还针对每一项添加了项目上的例子作为参考，让团队每一个人都清楚地知道我们自己的TOP 10都是什么样的以及业务场景下可能出现的安全问题。

　　然后我们将项目专属TOP 10作为模板加入到了每个用户故事中，这么做有两个好处：

第一，业务分析师在写用户故事的时候，可以将其作为参考来编写安全验收标准；

第二，如果业务分析师在缺乏安全知识的情况下很难编写安全需求，我们可以将其直接作为安全需求以防遗漏。