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

　　然后在用户故事的启动阶段，业务分析师、QA和开发人员会一起针对用户故事模板中我们自己的TOP 10进行筛选，将和用户故事相关的内容标识出来作为安全验收标准。如果在故事分析阶段，业务分析师已经遵循一些原则细化了安全验收标准，在这个阶段，也可以多个角色针对这些安全验收标准进行探讨，确保大家理解一致。

　　到了用户故事的开发阶段，通常开发人员都会按照验收标准来编写代码和测试，基于我们已经有了足够的安全验收标准，相应地，开发人员也会编码来实现这些安全条件并且添加相应的自动化测试保障，当然，除了满足安全验收标准之外，我们也会做一些静态代码的扫描和第三方依赖的扫描，双重保障。

　　用户故事的验收阶段非常重要，因为如果在这个阶段发现缺陷可以快速修复，我们一般是QA、开发人员和业务分析师一起，逐个验收我们之前制定的安全验收标准。当然，除了简单地从前端进行验证，针对安全验收我们需要借助一些工具（如Burp Suite），绕过前端修改请求，检查是否后端接口也作了相应的防范，如果发现安全问题，会在这个阶段及时修复并且增加相关的测试保障。

　　到了用户故事的测试阶段，QA会做跟安全相关的探索性测试，在这个阶段，需要QA从一个全新的视角来做测试，之前我们的模式是从正常用户的角度来测试功能，而针对安全的探索性测试则截然不同，我们要用攻击者的角度来思考问题，尝试各种看似不可能的手段，寻找安全漏洞。另外，在这个阶段，我们也会借助一些自动扫描工具（比如ZAP），来检测是否有一些通用的安全问题。

　　安全的演示阶段比较有挑战性，前面提到过，它不像功能需求那么可见，所以我们采用了一种全新的方式去展示，通常功能演示我们是给客户展示用户界面，如何使用系统等，开奖，而对于安全，我们尝试了展示安全缺陷以及我们的缺陷分布分析。比如在这一个月里，我们发现了六个安全问题，其中两个是通过ZAP扫描出来的共通的安全问题，另外四个是和业务强相关的安全问题（比如账户A可以通过特殊手段修改其本来没有权限的数据，属于我们自己的TOP 10的Authentication那一类）。

　　回顾整个过程，其实我们在用户故事的每个阶段都增加了和安全相关的实践，并且让团队所有人员都参与了进去，将安全融入到日常的工作中，不断改进，持续关注，而这些正是BSI所传达的理念。

　　客户看到我们的安全成果展示后非常满意，进而在我们整个团队开展了这样的安全实践。

　　在维持这样的安全模式几个发布周期之后，我惊喜地发现我们的开发人员开始有了安全的意识，比如前不久我们有一个用户故事需要实现一个邮件模板，系统要求能够接受用户定制化的html，功能实现非常简单，可是开发人员一筹莫展，接到用户故事后马上找到我，探讨如何让我们的系统允许接受html后还可以避免攻击，这让我深刻感受到，BSI（Build Security in our DNA）这个理念的精确含义，我们不是为了让大家遵循实践而去实践，而是让每个人都有安全的意识，每当我们接触到一个新的功能，马上会想到可能有哪些安全问题，而不是急于实现功能，长此以往，安全就真的进入了团队的DNA。

　　总结