3.3 何时进行安全代码审查

组织一旦决定将安全代码审查作为他们内部编码过程的一部分，面临的下一个问题便是何时进行安全代码审查。本节探讨安全代码审查的3种可能方法，包含软件开发生命周期中的安全代码审查的如下3个阶段。

1.代码即将被审查（预提交）

软件开发组织可以在开发过程中声明，在代码被提交到源代码库之前，所有的代码需要进行审查。由于审查可能需要时间，这样做的缺点是减慢代码提交进程，但是也有很多优点，由于低于标准的代码不会被放在源代码库中，因此，管理者可以确信（如果各流程被遵守）提交的代码符合规定的质量。

过程中可能会声明要提交的代码必须包含需求和设计文档，以及必要的单元和自动化测试内容，这样，审查人员就可以根据各种文档确切了解正在修改的代码，同时根据测试内容了解开发人员已经对代码进行了怎样的测试。如果同行审查认为文档不完整或者测试覆盖不全，他们可以拒绝实施审查，并非由于代码本身，而是因为必要的文档或测试不完备。在使用持续集成的环境中，自动化测试每晚都在运行，一般来说，开发团队第二天会知道提交的代码质量是否过关。管理层也会知道，一旦代码被签入代码库，表示开发人员的任务已经完成，就没有“我下周会完成这些测试”这种增加开发任务风险的场景了。

2.代码已被提交到代码库审查（提交后）

这里指的是开发人员提交他们的代码变更后，通过代码库更改列表发送代码差异进行审查。由于在开发人员签入代码之前没有审查门槛，这对于他们来说具有更快开发的优势；但缺点是，在实践中这种方式可能导致代码质量较差。一旦代码被签入，开发人员就倾向于不去修复较小的问题，同时还有时间风险，因为其他开发人员可能在审查完成之前，将其他修复代码写入同一个模块，或者由于修改和测试已经被写入，使开发人员不仅必须依据同行审查或安全审查实现代码变更，而且必须确保不会破坏其后续代码变更。因此，开发人员必须重新测试后续修复以确保没有回滚。

一些使用敏捷方法的开发组织在其开发流程中加入了“安全冲刺”，在安全冲刺期间代码可以进行安全审查，并且增加了明确的（人工或自动化的）安全测试用例。

3.安全代码审查完成

一些组织的安全代码审查流程有一定的时间间隔（每年），或当一段有漏洞的代码被怀疑在代码库中重复时进行审查。通过对代码的静态代码分析或简单的字符串搜索（针对特定的漏洞模式）可以加快审查进程。此时的审查与功能或漏洞修复的提交无关，而由过程对策触发，这很可能涉及整个应用或代码库的审查，并非对单个提交代码的审查。