Microsoft 的 Agile 安全开发生命周期 (SDL) 指南建议在项目的设计、实施和发布期间实施安全实践。无论使用何种开发方法，在经过安全审查之前，任何代码行都不应投入生产。如果财务限制阻碍了专业人员进行这种级别的安全审查，则必须由同行进行安全审查，然后才能最终确定发布。完成发布可以成为一个有趣的过程，我看到公司举办全公司范围的黑客马拉松并为有趣的错误发放奖品。

微软在 SDL 方面做了大量工作，微软的安全性也有所提升。

简短的回答是：将安全性集成到您的软件开发生命周期中。它应该集成到每个阶段：设计、实施和测试。

关于如何在软件开发生命周期中构建安全性的资源有很多。参见，例如，Cigital 的 SDLC（7 个接触点）]、Microsoft 的 SDLC、OpenSAMM 的 SDLC、BSIMM、CERT 的 Build Security In或此处的问题，例如安全软件开发、安全软件开发环境的创建、什么被认为是最简单的（或最轻）安全的开发生命周期？,选择哪种安全开发生命周期模型？.

“安全审查”不是一回事。有不同形式的安全审查。将安全性集成到您的软件开发生命周期中需要在每个阶段都考虑安全性，而这些不同类型的安全审查将产生不同的影响。这些元素可能包括：

• 您应该进行安全设计审查，审查您的设计以了解与设计相关的架构级安全风险以及潜在的设计级缺陷（这就是微软所说的“威胁建模”）。您无需在每次更改实现时重新检查这一点，只需在更改设计时重新检查即可。

• 您还应该进行安全代码审查，以审查您的代码以识别可能危及安全性的潜在实现级代码缺陷。每当您编写新代码或更改现有代码时，您都需要检查该代码是否存在实现错误。

• 您还应该将安全性集成到您的测试工作中。在发布新版本之前，您可能会测试其安全性，尤其是关注已更改的功能。

如果您的安全模型基于对整个代码库进行时间点外部审计的概念，那么您的安全性就错了。

...而且您可能也错误地使用了审计。但我们会做到这一点。

毫无疑问，所有代码都需要进行安全审计。在许多情况下，这实际上是一项法律要求：没有经过审计的代码就不会发布。传统观点认为，这样的审计是生命周期中某个时刻的事件，但更明智的做法是随时审计代码。也就是说，所有代码在签入您的代码库之前都会经过安全审核。

理论很简单；存储库已经过审核，因此我们不需要作为标准程序重新审核其组件。但是，当提出新功能或补丁或错误修复时，差异必须由适当的维护者签署。您可以签收对您来说重要的任何事情。例如，Linux 内核有一个相当复杂的审批流程，在此过程中需要对质量、简单性、一致性、性能等进行多次认可。您的要求可能会有所不同，但安全审计应该是该审批流程的一部分。

在这种情况下，您不是在端到端审核产品，您只是在审核差异。但是，在产品开发周期过程中进行的数千次小型审核将比任何一次端到端审核所希望的更加深入和全面。

完整的产品端到端审计肯定是有帮助的，不应该避免。这种审核应该以一种在您一直在进行的补丁级别审核中不容易做到的方式关注整个产品。您想不时查看整个森林，而不仅仅是单个树木。这些大规模审核的时间可能应该与主要版本、重大更改或合规认证审核相对应。

但是通过保持最新的补丁级审计，您可以确保代码始终保持在可验证的状态，因此您可以放心地继续定期发布。

关于提交时批准
如果您的公司没有这样做，那么您做的一切都是错误的。通过要求每个代码更改至少得到另一个人的批准，包括（尤其是）在初始开发期间，可以解决数十个甚至数百个问题。您应该始终至少有两个人了解每一行代码的工作原理，并同意代码是正确的。

这至少与单元测试一样重要。如果您不这样做，请停止一切​​并重新访问有关质量和安全性的政策。

是的，这个过程确实可以扩展。如上所述，世界上最大的软件项目使用它，世界上一些最敏捷和最成功的软件公司也使用它。

添加误用案例。

如果有系统必须展示的功能，则使用用例。如果存在系统不得展示的功能，请使用误用案例。

“作为竞争对手，我想在数据库后端查询公司敏感数据；这绝对不能发生。”

“作为一名黑客行动主义者，我想使用 DMZ 来反映对政府的攻击；这绝不能发生”。

产品负责人可以将这些故事与其他故事一起优先考虑，但它们就像任何其他用户故事一样是可测试的。

（我坦率地承认，我不是敏捷秘密奥秘的发起者；敏捷已经成为了第 77 届共济会的东西，充满了不可打破的奥秘和诫命，因为害怕无法言喻的恐怖）。