让安全实践在敏捷团队落地(3)

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

安全落地尝试

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

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

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

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

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

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

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

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

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

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

5.不知道如何满足客户期望

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

首先，召集团队的核心成员（包括了业务分析师，开发人员，测试人员，技术主管），同时我们邀请了公司的一位安全专家帮我们解答难题，大家头脑风暴，参考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作为模板加入到了每个用户故事中，这么做有两个好处：

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

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

当然这还远远不够，更理想的情况是在需求分析阶段、业务分析师和客户在讨论需求的过程中尽量参考一些基本的原则，比如最小权限原则，来确定和编写更加准确的安全验收标准。如下图。还可以让更多的人参与到需求分析阶段，通过威胁建模等手段分析出更全面的安全需求。当然这就需要我们的业务分析师增加安全相关的知识储备，我们也在向这个方向努力。

原文转自：http://www.infoq.com/cn/articles/let-safe-practices-land-in-the-agile-team