安全代码开发：敏捷的牺牲者？

敏捷团队以快速产生可靠和高质量的代码而著称。然而，快速交付的压力可能会导致走捷径的评审，缩减测试并缺乏对安全代码的重视。安全开发与敏捷共存是否只是一厢情愿的想法呢？

根据一项中小型企业的研究表明，敏捷团队并没有把安全当回事，即使是开发通过 Web 访问的系统。该研究引用说，

采访表明，小型和中型的敏捷软件开发组织不使用任何特定的方法来实现安全目标，即使当他们的软件是面向 Web 的，是潜在的攻击目标。这种情况下，研究证实即使在某些案例中安全是被明确要求的，安全设计作为实施团队的输入要求之一，最终的结果是否满足安全目标也没有保证。

Adrian Lane，也关注 敏捷方法开发软件风险的安全方面。 Adrian

关注功能的高效交付、以牺牲软件开发的安全为代价基于书本式的敏捷实施问题，并推动软件之外的安全确认与服务。

Rocky Heckman 认为，像 TDD 和结对编程这样的技术， 主要还是聚焦在功能上。

测试的重点放在高质量代码与可靠的可重复性操作。很少或根本没有提及渗透式测试或威胁模型。

敏捷开发是否意味着完全无视安全？看起来也许有一些解决方法。

Jim Bird 提出，通过一点点地提醒可能是一种渐进地解决这些风险的方法.

据 Jim 的观点，就像其他的质量提升实践那样，安全实践是要融入团队的意识中。 团队可以使用增量受攻击面分析来监控系统的安全风险状况的变化，这可能是由于接口架构的改变导致的。

对于逐步构建软件并对代码非常熟悉的团队来说，威胁模型并没有想象的那么严重。大部分可在 1 周或 2 周的 Sprint 做完的变更并不大，而且可以增量的修改，不用花太多时间来评审，即使受攻击面被改变了。

Jim 还提到了利用安全 Sprint，微软称之为安全突击或“迷你安全推进”，在该 sprint 中，团队寻找现有代码的安全漏洞，然后再作出进一步的重大变更。Jim 引用 Adrian Lane 的话，他提到，开发团队比客户更关注安全性。开发团队在其开发过程中应给予足够的重视并担负起责任。

即使一个强大的和善意的客户也不能被指望了解应用程序的安全问题，或如何构建安全的软件。他们自己的事情已经很多了。

因此，正确的措施和心态有可能把安全作为开发过程的一部分。

Jim 说，

没有理由认为敏捷开发 = 安全故障。技术工作，对于质量和细节与构建安全软件的承诺是相同的，而不论团队采用什么样的开发方式。

查看英文原文： Secure Code Development: A Casualty With Agile?