在遵守Agile开发原则时关注安全意味着要像坏人一样思考。

需要密切关注不起眼的用户故事，这些简单构建的模块里通常能够发现Agile安全性问题—有很多版本——记录在白板上的各种颜色的即时贴里。

用户故事提供了简单的方式来查看安全性漏洞。“最简单的做法是帮助公司看到攻击者能看到的漏洞，” San Jose的主席和CEO，Judy Neher说，这是一家总部在加利福利亚州的公司，开发制造半导体时使用的气体液体交付系统。

在华盛顿的Agile2015大会上Neher分享了降低软件漏洞的方法。

编程中解决敏捷安全性

如果有好时机来来戴上黑帽，那就是现在，基于之前这些年公开数据泄露的次数——Target和联邦管控是其中两个。越早发现安全风险越好解决。比如，美国国家标准与技术研究院（NIST）说，在代码上线之后解决安全漏洞的代价50倍于开发阶段解决的代价。有些估计甚至更高，认为代价可能是100倍。

即使知道代价巨大，也很容易在问题真正发生的最后一刻之前都将安全考虑推到一边。一个Agile2015的参会人员，来自一家大型很有名的娱乐公司的员工承认公司里没有人在”上线之前“考虑敏捷安全性的。Neher说即使她自己也是很多年才意识到安全的重要性，因为她当程序员的时候总是关注于具体要做的事情，而不是处理安全性。

“但是开始考虑需求的时候就应该考虑到安全性，“她说。”需要在一开始就考虑到如何错误使用或者滥用某个特定的功能。”

从user story开始，Neher建议到，尽可能得和团队成员集体讨论出可能得反向场景，将其转变为滥用故事。”谁想获得我们的数据？“Neher问。”他们为什么想要我们的数据？他们可以使用数据干什么？攻击者想从攻击中得到什么？“

与会者支持早期安全投入

在流程的早期开始考虑安全性对于一些开发人员而言是好消息，他们说他们喜欢这个主意。”我们通常在最后之前都不会考虑到安全性问题，因此我喜欢这个想法，从用户故事阶段开始安全性规划，“一个大型能源公司的Agile项目经理说。”如果我们能够更早发现问题，的确能够帮助减轻压力。“

验收标准也需要仔细审查。验收标准的缺失或者不完整会让软件更容易受到攻击，Neher提醒到，同时必须经过最坏情况场景的审核。实际上，每次添加或者改变什么东西的时候，团队成员必须自己想一想这个新功能会被如何故意或者无意地滥用，Neher说。

最终，这些abuser story可以在产品backlog里和其他story一起基于威胁风险来评级。要想更好得控制风险，Neher推荐一个称为”明智的头脑风暴“的流程，该流程里会请专题专家或者安全官员来审核被滥用的可能性以及开发所基于的前提条件。

“攻击者不是标准使用的客户，“她解释道。”谁是我们的敌人，他们想从我们这里得到什么？我们必须假定他们会攻击我们所有的弱点。”

当然，这里也需要业务决策。要点是找到功能和安全性间的平衡，适当地按照开发量区分优先级。”我们从来不是想要完全消灭所有威胁，但是我们想要持续降低威胁。“Nether说。

对于需要帮助来确定安全需求的公司，Neher推荐查看NIST书籍《在联邦信息系统和企业里评估安全和隐私控制》的附录F。