代码审查

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

1 级代码审查

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

SSG 随机对高风险应用程序执行特别代码审查,例如在设计审查之后执行代码审查,查找安全问题。这种非正式的目标查找通常会演变成一种系统的方法。SSG 审查可以涉及使用特定工具和服务,或者可以采用人工方式,但必须纳入前瞻性流程中。在新技术涌现时,就需要制定新的代码审查方法。

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

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

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

对于 SSG 权限下的所有项目,代码审查都是强制执行的,缺少代码审查或不合格的结果会导致发布停止、减慢或召回。所有项目都必须接受代码审查,但不同种类的项目可能会接受不同的流程。例如,对低风险项目的审查可能更多地依靠自动化等方式,而高风险项目,对审查人员花费的时间可能没有上限。一套可接受的最低标准可以迫使那些未通过的项目接受修复和重新评估。关闭几乎所有规则的代码审查工具(例如,为了能够以 CI/CD 自动化速度运行),无法充分覆盖所有缺陷。同样,关注质量和风格的同行代码评审也不会提供有用的安全结果。

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

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

2 级代码审查

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

为开发人员提供导师,展示如何充分利用代码审查工具。如果 SSG 最擅长使用这些工具,则可以利用办公时间或其它延伸时间来帮助开发人员建立正确的配置或引导解读审查结果。或者,SSG 人员可以全程陪同开发团队执行他们的第一次审查。利用工具导师,可以将集中使用的工具逐渐分散到开发组织或工具链中,但是提供集中工具的安装说明和 URL 并不等同于工具导师。在许多组织中,卫星成员会发挥工具导师作用。

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

定制静态分析以提高效率并减少误报。添加自定义规则可以帮助发现特定于组织的编码标准或其使用的基于框架或云提供的中间件的安全缺陷。提供工具指导的同一团队有可能领导定制。定制规则可以做加法,明确地与正确使用技术栈相关联,也可以做减法,消除公司代码库中经常遇到的错误。为了减少每个人的工作量,许多组织还创建规则来删除重复的误报并关闭不相关的检查。

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

SSG 保留了一份随时更新的列表,其中列明了 SSG 希望在组织代码中消除的最重要的缺陷种类,并以此推动作出改变。许多组织都是从公共资源中提取的通用列表开始的,但是像 OWASP Top 10 这样的列表很少反映组织的缺陷优先级。这份列表的价值在于它是特定于组织的,是基于代码审查、测试、软件组合分析和实际事件中收集的真实数据制作的,并且为预防工作确定了优先级。只是按照当天发生次数排列缺陷数据不会产生令人满意的列表,因为这些数据常常变化不定。为了增加吸引力,SSG 可能会在更新列表之后定期发布“最想要的”报告。重大缺陷列表的一个潜在陷阱是,它往往只包含已知的问题。当然,仅仅制作这份列表并不能取得任何成果;而应当做到每个人都必须切实地用它来消灭缺陷。

 

 

3 级代码审查

[CR3.2: 7] 建立整合评估结果的能力。

合并评估结果,将多种分析技术馈入同一报告和补救流程。分析技术可能包括静态分析、动态分析、软件组件分析、容器扫描等等。SSG 可能会编写脚本用于自动收集数据,并将结果合并为可供同一套下游检查和报告解决方案使用的格式。这个活动中棘手的部分是对来源不同、术语有冲突的漏洞信息进行规范化。有时,标准化分类法(例如,CWE 类方法)可以帮助实现标准化。合并多个来源有助于作出更加明智的风险缓解决定。

[CR3.3: 1] 从整个代码库中清除特定的缺陷。

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

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

自动代码审查用于识别内部开发人员或外包提供商恶意编写的危险代码。审查可能针对的恶意代码包括后门、逻辑炸弹、定时炸弹、恶意通信通道、混淆程序逻辑和动态代码注入。虽然成品自动化可能会识别出一些一般的恶意构造,但是很快就会需要采用静态分析工具的定制规则,在组织代码库中编码可接受和不可接受代码模式。针对恶意代码执行人工代码审查是一个良好的开端,但不足以规模化完成这项活动。虽然并不是所有的后门或类似的代码在编写时都是恶意的(例如,在测试期间避开身份验证的开发人员功能),但是这些事物往往保留在已部署的代码中,在未证明无害之前都应该被视为恶意代码。

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

组织的安全编码标准通常是从一个简单的禁止功能列表开始强制执行的,违反这些标准就足以成为驳回一段代码的理由。其他有用的编码标准主题可能包括正确使用云 API、使用经过批准的密码学技术、内存清理等。必须客观地审查标准的代码:它不应该演变成关于不兼容代码是否可利用的争论。有时,开发人员的编码标准是专门针对技术栈发布的,然后在代码审查过程中或直接在 IDE 中执行。标准可以是肯定的(“就这么做”)或否定的(“不要使用这个 API”),但是必须得到执行才能发挥作用。