2.4 确定安全代码审查的范围

安全代码审查的等级根据软件的业务或需要的监管规定、软件开发组织机构的规模和开发应用程序人员的技能而确定。与软件开发的其他方面类似，如性能、可扩展性和可维护性，安全性同样也是度量应用程序成熟度的一个方面。安全性应该作为一个非功能性需求，被纳入用于商业或政务目的的所有核心应用程序或工具中。

如果开发环境仅包含了一位编程爱好者和使用VB（CMM等级1）来编写一个跟踪客户每周购物情况的程序，那么让那个程序员使用本书中的所有意见来执行广泛的安全代码审查是不太实际的。在另一个极端的案例中，一个具有数千名开发人员开发上百个应用程序的大型机构，（如果他们想要成功的话）应非常认真地对待安全性，就像他们会认真对待应用程序的性能和可扩展性那样。

并不是每个开发组织机构都有必要或资源去遵循和执行本书中的所有主题，但是，所有的组织机构都应当针对那些对他们最重要的流程和技术意见编写他们的开发流程。然后，随着组织机构的不断发展和逐渐成熟，这些流程应该被扩展以包含更多的安全代码审查。

在一个仅由3人组成的初创团队中，是不会有“安全代码审查团队”审查代码的，相反，可能在房间的角落里有一个开发人员曾经阅读过安全编码相关的书籍，而那本书现在正垫在他的显示器下。

在一个中等规模的公司里，可能有400位开发人员，其中一些人员对安全感兴趣，甚至是非常专业的。不过，从组织流程来说，可能审查一个3行CSS变更代码的时间和重新设计旗舰产品身份验证代码的时间一致。这里的挑战是，提高员工的（通用）安全编码知识，并通过威胁建模和安全代码审查改善流程。

一些拥有数千位开发人员的大型公司，对于S-SDLC的安全需求是最大的，但流程的有效性对安全基线存在影响。以一家拥有5000位开发人员的大公司为例，在流程中引入变更将导致每位开发人员在每周额外花费15分钟执行一项任务，即公司需要每周额外耗费1250个小时，或者每年（假设每周工作40小时）额外使用约30位全职的开发人员才能使流程正常运行。这里的挑战是：确保开发生命周期中的安全变更是有效的，且不妨碍开发人员执行他们的任务。

然而，必须记住，不管组织的规模有多大，执行安全代码审查是为了识别更多的安全漏洞，并且在S-SDLC的早期识别它们。执行安全代码审查和以这样的方式识别安全漏洞，要比在测试阶段或上线阶段找到安全漏洞快很多。对拥有5000人的组织来说，在测试过程中找到一个安全漏洞，调查、重新编码、重新审查、重新测试和重新发布要花多长时间呢？如果是在带有项目管理和技术支持的代码开发阶段呢？也许每周15分钟看起来会非常划算。