代码审查

代码审查实践包括使用代码审查工具、开发量身定制的规则、针对不同职务(例如开发人员与审计人员)自定义工具使用的配置文件、人工分析以及跟踪/测量结果。

1 级代码审查

[CR1.2: 82] 安排 SSG 执行特别审查。

SSG 随机对高风险应用程序执行特别代码审查,例如在高风险应用程序的设计审查之后执行代码审查。在更高的成熟度级别,可将这种不正式的方式替换为系统方法。SSG 审查可以涉及使用特定工具和服务,或者可以采用人工方式,但必须具有前瞻性。在新技术涌现时,就需要制定新的代码审查方法。

[CR1.4: 76] 使用自动化工具与人工审查相结合

在代码审查流程加入静态分析,使代码审查更加高效稳定。自动化并不能取代人为的判断,但它确实为不是安全专家的审查人员提供了审查流程和安全专业知识。请注意,只靠一个特定的工具可能无法覆盖整个组合,特别是在涉及新的语言时,但这不能成为不审查代码的借口。公司可以雇用外部服务提供商参与正式的软件安全代码审查流程,但是该服务应当明确地衔接在软件开发过程中应用的更大的 SSDL,而不只是用来在部署路径上“勾选安全选项框”。

[CR1.5: 40] 在所有项目中强制执行代码审查。

代码审查是 SSG 管辖范围内针对所有项目的强制性发布关卡。未接受代码审查或结果不合格的发布将遭到中止或延迟。所有项目都必须接受代码审查,但不同种类的项目可能会接受不同的审查流程。例如,对低风险项目的审查可能更多地依靠自动化等方式,而高风险项目,对审查人员花费的时间可能没有上限。在多数情况下,一个具有最低可接受标准的代码审查关卡会迫使那些未通过的项目在发货之前完成修复或重新评估。为了能够以 CI/CD 自动化速度运行而关闭几乎所有规则的代码审查工具,无法充分覆盖所有缺陷。

[CR1.6: 44] 使用集中报告闭合知识循环并促进开展培训。

代码审查中发现的缺陷会在中央存储库中得到追踪,从而可以为组织提供汇总报告和趋势报告。代码审查信息可以合并到 CISO 级面板中,面板还包含来自安全组织其他部门的信息流(例如,渗透测试、安全测试、黑盒测试和白盒测试)。SSG 还可以使用报告展示进度并促进开展培训课程(参见 [SM2.5 确定指标并以此促进制定预算])。个别缺陷可以成为典型的培训实例。

2 级代码审查

[CR2.5: 28] 指定工具导师。

为开发人员提供导师,展示如何充分利用代码审查工具。如果 SSG 最擅长使用这些工具,则可以利用办公时间来帮助开发人员建立正确的配置或引导解读审查结果。或者,SSG 人员可以全程陪同开发团队执行他们的第一次审查。借助工具导师,可以逐渐将集中使用的工具分配到开发组织中去。提供集中式工具的安装说明和 URL 不可视为指导。

[CR2.6: 20] 使用具有定制规则的自动化工具。

定制静态分析以提高效率并减少误报。使用定制规则查找组织编码标准,或定制中间件特有的错误。关闭不相关的检查。提供工具指导的同一团队有可能领导定制。定制规则可以做加法,明确地与正确使用技术栈相关联,也可以做减法,消除公司代码库中经常遇到的错误。

[CR2.7: 25] 利用重大缺陷列表(推荐使用真实数据)。

SSG 保留了一份列表,其中列明了 SSG 希望在组织代码中消除的最重要的缺陷种类,并以此推动作出改变。可以首先从公共资源抽取一个一般列表,但是利用代码审查、测试和实际事件中收集的真实数据构建的,专门针对组织的列表会更有价值。SSG 可能会定期更新列表并发布“最想要的”报告。(如需了解使用该列表的其他方法,请参见 [T1.6 创建并利用针对公司历史的材料])。有些公司利用多种工具和真实代码库数据构建重大缺陷清单,不把自己限制在特定的服务或工具上。使用重大缺陷清单易犯的错误是“只在路灯下找钥匙”,也就是说,清单只包含已知问题。例如,OWASP Top 10 列表很少反映组织的缺陷优先级。只是按照当天发生次数排列缺陷数据不能产生令人满意的重大缺陷列表,因为这些数据常常变化不定。应采用重大缺陷列表确保消除这些缺陷。

 

 

3 级代码审查

[CR3.2: 4] 构建一座车间。

合并评估结果,将多种分析技术馈入同一报告和补救流程。SSG 可能会编写脚本来自动调用多种检测技术,并将结果合并为可供同一套下游检查和报告解决方案使用的格式。分析引擎可以结合静态和动态分析,而且可以利用一个车间将移动和标准方法等不同的审查流程统一起来。这个活动中棘手的部分是对来源不同、术语有冲突的漏洞信息进行规范化。有时,标准化分类法(最好是 CWE 类方法)可以帮助实现标准化。合并多个来源有助于作出更加明智的风险缓解决定。

[CR3.3: 1] 构建消除整个代码库特定缺陷的职能。

发现一种新缺陷时,SSG 会编写该缺陷的查找规则,并使用规则标识 整个代码库中出现的新缺陷。无需等到所有项目都到达生命周期中的代码审核阶段,就有可能彻底根除这种缺陷。只有少量软件应用程序的公司要比拥有大量大型应用程序的公司容易执行这一活动。

[CR3.4: 4] 自动检测恶意代码。

自动代码审查用于识别内部开发人员或外包提供商恶意编写的危险代码。审查可能针对的恶意代码包括后门、逻辑炸弹、定时炸弹、恶意通信通道、混淆程序逻辑和动态代码注入。虽然成品自动化可能会识别出一些一般的恶意构造,但是很快就会需要采用静态分析工具的定制规则,在组织代码库中编码可接受和不可接受代码模式。针对恶意代码执行人工代码审查是一个良好的开端,但不足以完成这项活动。

[CR3.5: 3] 强制执行编码标准。

违反组织的安全编码标准是驳回一段代码的充分理由。代码审查具有主观性——它不应该转化为关于代码是否可被利用的争论。标准的强制执行部分可以和禁止功能列表一样简单。有时,开发人员的编码标准是专门针对技术栈(例如,C ++,Spring 或Swift 指南)发布的,然后在代码审查过程中或直接在 IDE 中执行。标准可以是肯定的(“就这么做”)或否定的(“不要使用这个 API”)。