基于分类器的 VP 系统针对上游项目中的高风险代码更改

链接表

摘要

I. 引言

II. 背景

III. 设计

• 定义
• 设计目标
• 框架
• 扩展

IV. 建模

• 分类器
• 特征

V. 数据收集

VI. 特性分析

• 漏洞修复延迟
• 漏洞修复变更分析
• 漏洞引入变更分析

VII. 结果

• N折验证
• 使用在线部署模式的评估

VIII. 讨论

• 对多项目的影响
• 对安卓安全工作的影响
• 有效性威胁
• 替代方法

IX. 相关工作

结论和参考文献

\ \

III. 设计

本节概述了VP（漏洞预防）框架的设计。该设计基于对其基本设计需求的分析。

A. 定义

让我们定义本研究中的安全代码审查点和代码变更分类法。

==安全代码审查点。== 它显示了可用于自动触发我们的分类器的三种事件类型：

(1) 代码变更最初被发送进行代码审查（或标记为准备好审查或提交前测试）；

(2) 发送了新的补丁集；

(3) 代码变更被提交。其使用可以通过额外条件进行细化（例如，仅在指定审查者时触发）。分类器也可以通过多种方式手动触发（例如，通过在变更描述中添加标签，点击代码审查服务中的UI按钮或复选框，或为代码审查服务中可用的特定代码变更执行shell命令）。

\ ==代码变更分类==。在本研究中，我们将代码变更分为以下几类：

ViC（漏洞引入变更）指最初引入漏洞的代码变更。

VfC（漏洞修复变更）指修复现有漏洞的代码变更。

LNC（可能正常变更）指不太可能引入漏洞的代码变更。值得注意的是，它包括在分析时尚未被识别为已知ViC的变更。

此外，VfLs（漏洞修复行）是由VfC编辑的源代码行的特定子集，其中编辑对解决漏洞至关重要。

\ B. 设计目标

我们的方法是为满足以下条件的用例设计的：

目标项目经常出现软件漏洞，且潜在后果严重（例如，昂贵的修复成本、产品声誉损害和对用户的影响）。

目标项目作为下游软件项目的上游源，用于构建许多集成的终端用户产品或服务（例如，用于Android智能手机和电视的AOSP）。

下游项目由于相关成本、技术专业知识和工具限制，往往缺乏严格的安全测试（例如，使用动态分析器的系统模糊测试[19]）。

\ 通过在上游目标项目中检测和阻止易受攻击的代码变更，下游项目的安全工程成本得以降低。这种降低鼓励继续使用上游项目并吸引更多下游采用，激励上游项目所有者投资于漏洞预防实践。

\ 在目标条件下，估计给定代码变更中漏洞可能性的分类器被证明是有效的。当估计的可能性超过阈值时，相应的代码变更会被标记为需要通过安全代码审查或严格的安全测试进行进一步审查。我们的方法有助于检测易受攻击的代码变更（例如，安全测试失败的变更），从而防止它们集成到存储库中。

\ 我们的方法还提供了与提交后安全代码审查过程的无缝集成。被分类器标记的代码变更会由安全工程师或领域专家进行额外的离线审查。这增加了在这些变更中检测漏洞的可能性。通过在提交后但发布前应用分类器，有针对性的安全审查可以集中在最高风险的代码变更上（基于估计的可能性）。因此，我们的方法优化了安全代码审查过程，降低了整体安全成本，同时保持了强大的安全态势。

\ 考虑到这些用例，分类器的关键设计目标设定如下：

合理的召回率（ViCs > 75%）。 它确保大多数（> 75%）易受攻击的代码变更被检测到，从而大大降低整体安全风险。

高精确度（ViCs > 90%）。 由于易受攻击的代码变更很少见，对安全审查员来说，每10个代码变更中错误标记1个通常是可接受的。

低误报率（< 2%）。 正常代码变更很少被标记，以便为开发人员维持流畅的审查过程。

快速推理时间（例如，< 1分钟）。 这是为了实现与代码审查服务的顺畅集成，而不会导致开发人员可见的延迟。

低推理成本。 为了在典型的开源项目安全基础设施和工具预算范围内运行，推理应该在不需要使用强大或专门的ML硬件设备的情况下完成。

不频繁的重新训练。 因为模型重新训练的成本也很重要，每月对多达约一百万个样本进行重新训练被认为是可接受的。这是为了平衡准确性维护（与每日重新训练相比）与大多数开源项目的可负担性。

\ C. 框架

我们的VP框架适用于三种不同的用例：

==提交前安全审查== 是利用VP评估发送进行代码审查的每个代码变更，并识别可能易受攻击的代码变更，以便安全领域专家进行额外的安全代码审查。

==提交前安全测试== 是使用VP评估发送进行代码审查的每个代码变更，并识别可能易受攻击的代码变更，以便在提交前进行额外的安全测试（例如，静态分析、动态分析或模糊测试）。

==提交后安全审查== 是将VP应用于在预定义期间（例如，每天或每周）内提交的所有代码变更，并隔离一组可能易受攻击的代码变更，以便安全领域专家进行额外的深入安全代码检查。这个用例与现有的提交后时间安全测试不同。

\ 提交前安全审查用例场景具有最高的复杂性。与提交后用例相比，提交前用例对推理时间和在线重新训练有更严格的要求（例如，代码变更作者直接可见与质量保证团队相比）。与提交前安全测试用例相比，提交前安全审查用例有更严格的准确性要求

（例如，安全测试的误报主要意味着额外的测试成本）。因此，它被用作框架设计的主要目标。为了解决所选用例，VP（漏洞预防）框架利用其以下关键子系统，如图1所示：

\ ==代码审查服务。== 作者通过将其代码变更上传到指定的代码审查服务来启动代码审查过程。然后，他们为其变更分配审查者（见图1中的步骤1）。审查服务会根据作者或审查者的请求，或当上传的代码变更满足预定义条件时，自动触发一个或多个审查机器人。

\ ==审查机器人。== 被触发的审查机器人访问源代码变更所做的特定编辑，以及代码变更的相关元数据和基线源代码。为了进行深入分析，机器人通常利用后端服务来编译、分析和测试相对于基线的变更。新的VP审查机器人利用这些功能并将收集的数据转发给分类器服务。然后，分类器服务确定给定的源代码变更是否可能易受攻击。

\ ==分类器服务。== 当分类器服务被触发时，它利用特征提取器和来自VP审查机器人的数据来提取给定代码变更的相关特征。随后，它使用模型执行推理，以估计代码变更具有漏洞的可能性。

\ 分类器模型使用提取的特征作为输入，并生成二进制输出信号（即，'1'表示可能易受攻击，'0'表示可能正常）。输出信号指导是否对代码变更进行额外的安全审查（或安全测试）是有益的。分类器服务可以选择使用多个模型，结合它们的结果（例如，通过逻辑运算符或多数投票）以获得更好的准确性。

\ ==通知服务==。当代码变更被分类为可能易受攻击的变更时，通知服务会在代码审查服务中的代码变更上发布评论。该评论提醒代码变更作者和现有审查者可能存在漏洞，敦促额外审查。

\ 如果目标项目维护专门的安全审查者池，通知服务可以自动将池中的成员分配为目标代码变更的必要审查者。所选审查者可以是轮值的主要工程师，或通过启发式方法（例如，轮询）选择，以平衡分配安全审查工作量。

\ D. 扩展

VP框架支持安全测试和提交后用例的扩展：

==选择性安全测试。== 为了扩展VP框架以进行选择性的提交前安全测试，进一步采用了异步测试执行服务。执行服务将给定的代码变更补丁到基线代码中，构建工件（例如，二进制文件），并对构建工件执行相关的安全测试。

\ 执行服务支持安全测试配置的定制，包括参数调整以针对特定功能并调整最大测试时间。在实现中，审查机器人被扩展以生成定制的测试参数。扩展的机器人利用目标代码变更的源代码增量和目标项目的漏洞统计数据。由此产生的数据驱动方法允许机器人使用默认参数值或动态生成新值，帮助优化安全测试覆盖率和相关成本之间的平衡。

\ ==提交后用例。== 为了扩展VP框架以用于提交后时间用例，需要一个重放机制来处理已提交的代码变更，并使用相关输入数据调用VP审查机器人。特别是，如果使用的版本控制系统是git，则需要从git提交哈希中跟踪代码变更标识符。它使用分类结果选择代码变更的子集进行进一步的全面安全审查。

:::info 作者：

1. Keun Soo Yim

:::

:::info 本论文可在arxiv上获取，遵循CC by 4.0 Deed（署名4.0国际）许可。

:::

\