手动源代码审查
当开发进程中有足够的代码进行审查时可进行手动源代码审查。手动源代码审查通常仅限于寻找代码级的可能导致安全漏洞的疏漏。代码审查不是用来揭示以下内容：
有关业务需求却不能被安全执行的问题
有关应用特殊技术的选择事项
可能导致漏洞的设计事项
源代码审查通常不会担忧漏洞被人利用。从审查中找到的结果会被通过其他方式找到的结果一样对待。代码审查对可用于非安全查找，只要它们有可能影响代码的整体质量。代码审查通常不仅会导致安全认证的问题，而且会导致无作用程式码，冗余码，不必要的复杂性或其他问题。所有查找出的结果都遵循自己的优先性，而这些优先性通常都被定义为企业内部的“漏洞优先矩阵”。漏洞报告通常包含一个特定的补救推荐措施以便程序员可以适当对其进行修复。
手动代码审查的成本比较高，因为它设计许多手动操作且需要安全专家进行辅助审查。但是，就准确性和质量而言，手动审查物有所值。它们可以帮助我们识别自动静态代码分析器无法识别的逻辑漏洞。
源代码审查通常被称为“白盒”分析。这是因为这类审查对内部设计，威胁模式和其他有关应用的系统文档都十分了解。而“黑盒”分析是从旁观者的角度来审查应用，因此没有应用的内部情况有详细了解。“灰盒”分析是介于黑盒与白盒之间的一种分析，我们稍后会对此再做介绍。
代码审查进程
代码审查进程始于项目管理团队和开发团队，目的是确保有足够的时间和预算分配给SDLC来执行此类审查。所有程序员和审查员都应该有权使用有利于执行此类审查的工具。代码审查进程包括图8.1中列出的四个高级步骤：
图8.1
代码审查的第一步是了解被执行的应用，该应用的内部设计以及威胁模式。了解这些可以极大地帮助我们识别代码中的关键组件并将优先权分配给它们。事实上，我们并不能保证每次都有足够的时间对代码进行逐行审查。因此，非常有必要了解代码的关键所在并确保这些关键部分可以被全面审查。
第二步是在优先部分的基础上对识别的关键部分进行审查。这样的审查可以由不同团队程序员来执行。另一个方法是让相应开发团队的程序员对所有代码执行同级审查。 不管代码审查是否完备，还是有必要将审查覆盖到关键部分从而使程序员和安全专家都有机会看到这些部分。所有识别出的漏洞必须用企业的漏洞管理工具记录在案，再对其分配合适的优先权。审查者必须将推荐的修复方案和这些漏洞一起记录下来以确保这些错误不会进入最后的生产代码中。
代码审查的第三部是与应用代码编写者进行协调，帮助他们执行修复。这其中可能涉及已有的，可重复的安全组件的整合，或者它会提出代码由简化繁的请求以及后续审查。
最后一步是学习审查周期，吸取改进的部分。这样可以让下次代码审查更有效。
要求进行深层驱动审查和分析的关键组件有：
用户身份验证和授权验证
数据保护
从受信任的数据源接受并处理数据
数据验证
涉及异常条件处理的代码
操作系统资源和网络的使用
低端架构代码
嵌入式软件组件
有问题的API的使用情况
由于手动分析耗时费力，企业还应该部署自动源代码分析工具作为补充(但是不能替代手动审查的作用)。
