梁广泰:华为云软件分析Lab技术专家/Team

菏泽炫佑科技

梁广泰:华为云软件分析Lab技术专家/Team

本文以技术文章的形式回顾了梁老师在SIG-程序分析技术沙龙上的分享。 评测视频也已上传至B站，欢迎朋友们点击观看。

大家好，非常感谢您今天来到我们的技术沙龙。 我是华为云软件分析实验室的梁光泰。 今天我给大家分享的主题是基于软件分析的新业务、新技术的智能化开发。

#技术趋势分析#

我们先来看看行业内的相关技术趋势。 我从一个云服务厂商的角度，给大家介绍一下业界目前在这个领域所做的事情。

#缺陷检测与修复领域

我们先来看看缺陷检测与修复领域。

## -

推出了一款名为[1]的工具，其主要功能是通过全面的缺陷检测和扫描，帮助程序员更快地识别有问题的代码，并提供代码修复的智能建议。

：自动进行代码审查，持续监控性能并识别低效代码，提供智能建议以提高代码质量，降低整体代码维护和运营成本[1]

这提供了两个子服务：

顾名思义，该子服务实际上是利用机器学习，通过自动推理算法提供智能代码审查服务，帮助程序员进行各类代码搜索并提供代码修复建议。

与之对应的另一个子服务是。 该服务利用插桩技术来监控程序运行时的状态，包括内存消耗、CPU使用情况等，通过分析运行时数据，提高程序的运行效率，甚至可以帮助程序员找到昂贵的代码行跑步。

##-天蓝色

我们再看一下微软Azure。

代码

作为代码托管平台，它也是全球*大的代码数据中心之一。 围绕这个中心，开发了各种代码分析服务。 微软收购后，Azure和微软已经全面整合，包括代码[2]服务，可以提供对Azure上高风险文件的扫描能力。

如下图所示自动化软件开发，在代码提交页面，Code会自动将识别出的缺陷警告显示在页面上，帮助程序员更快地发现问题，并在代码入库之前拦截这些问题。

代码[2]

此外，Azure[3]还支持配置各类扫码任务。 与其他云厂商不同的是，微软的缺陷分析工具并不是微软自己提供的，用户可以自由配置外部的。 例如，用户可以在本地部署一些静态分析服务，并在Azure中配置相关链接，包括扫描命令等，从而将本地和云端有机结合起来。

支持设置扫码任务，覆盖主流缺陷检测工具[3]

与此同时，微软继续开发其代码分析能力。 如下图所示，提供了一些监控方法，帮助程序员更快地识别程序中潜在的问题，并提供更新提示。 这其实和刚才提到的类似。

通过监控识别潜在的性能问题并给出优化建议[4]

##阿里云-

阿里云还通过其[5]代码托管平台继续扩展其软件分析能力。

依靠 PMD 和 Sonar 插件完成合规性检查

主要依靠开源代码扫描工具PMD（）[6]和Sonar插件（主要用于代码库的全自动扫描阶段）来完成相关的合规性检查。

代码质量-协议检测P3C[7]

集成AI提供自动修复/敏感信息检查/智能审核

阿里云在 ICSE-SEIP'20 上发布了自动代码修复技术[8]梁广泰:华为云软件分析Lab技术专家/Team，可以基于数据挖掘进行模式挖掘，提供代码修复能力。

代码质量 - [7]

提供多层敏感信息检测工具。

代码安全-敏感信息检测[7]

提供智能代码审查，提高程序员研发效率。

提升研发效率——智能审核[7]

＃＃ 平台

[9]该平台（腾讯全资子公司腾云口鼎科技有限公司）也提供扫码功能。 目前，其内部集成了多种代码扫描工具和数千条规则，为多种主流编程语言提供漏洞检测和修复能力。 它还支持用户配置解决方案和外部工具的集成。

提供分支代码质量分析功能，可以帮助管理者快速了解分支的代码质量，例如：

分公司概况

圈复杂度

查看文档以了解有关代码扫描功能的更多信息：

##总结#开源组件治理领域

在本节中，我们介绍开源组件（即 Open-[10]）治理。 前面提到的缺陷分析领域更多的是分析程序员自己开发的代码，看看其中是否存在各类问题。 开源组件主要集中在开发过程中可能被程序员大量复用的外部第三方开源组件。

现代软件开发中开源组件的使用日益增多，业界也越来越重视。 那么，结合开源组件的代码质量应该如何保证呢？ 其实这也需要通过一系列的智能开发服务或者软件分析服务来实现。

那么，在开源组件治理领域，相关云服务厂商都在做哪些实践呢？

## 天蓝色 -

我们先来看看微软Azure。 微软使用[11]服务来扫描代码仓库中使用的第三方库组件。 具体来说，它会首先扫描出代码仓库依赖了哪些第三方库组件，然后对顶级或一些已知的漏洞列表进行漏洞关联和预警。

在这个过程中，结合漏洞扫描数据，还可以推荐一些漏洞修复建议，指导程序员更快地修复存在漏洞的库。

##阿里云-

阿里云也在做类似的事情。

目前主要关注系统层面的中间件层面的组件分析，比如服务器层面的基础设施是否存在安全风险。 代码级别的工作尚未开展。 如果特定中间件的特定版本存在漏洞，则会及时发出警告。 这也是阿里云整个基础设施的一个关键功能，可以保障客户层面和虚拟机层面的安全能力。

网络扫描仪

仅支持检测云安全中心保护范围内（即已安装云安全中心代理）可访问公网的服务器，支持阿里云和非阿里云服务器。

网络扫描仪

服务器组件分析

支持云安全中心保护范围内的阿里云及非阿里云服务器的检测； 保护范围非常有限，能力还处于起步阶段。

服务器组件分析

##腾讯云-产品扫描

腾讯云[12]提供了扫描产品的能力，扫描的对象多为已编译的编译包。

产品仓库当前支持的产品类型

通过检查和定位解压后的二进制组件，我们可以找出每个组件来自哪个开源项目。 定位到组件后，会将漏洞与组件进行关联，并对高危和部分中危漏洞进行提示，帮助程序员更快地发现组件中的漏洞信息，并及时修复。

产品扫描支持产品类型，以Maven为例

##总结#华为云相关技术实践#

梳理完相关技术，我们再来看看华为云在做哪些技术实践。

#缺陷检测与修复##

华为云结合华为通用编程规范和安全编码规范，构建三级巡检+三层运行巡检修复体系。

三级检查机制

首先，我们需要有一些与公司编码标准相对应的能力或者工具集，帮助程序员进行符合公司编码标准的检查。 所以我们围绕这个需求建立了一个平台。 它已经在全公司范围内实施，这意味着每个华为程序员在提交代码入库时都会经过系统的扫描和诊断。

如上图所示，为代码检测提供了多方位、多角度的支持，包括：

以上三个阶段相辅相成，全面保证华为内部项目代码的质量。

在不同的阶段，分析有不同的要求：

三级运营机制

它还提供了一个3层操作系统：

目前已通过华为云向公司外部用户开放。 您可以尝试相关服务：

##

我们在平台上也做了很多探索，其中之一就是我们与俄罗斯团队在 2020 年合作打造的静态分析工具——[15]。 该工具主要旨在提供轻量级的代码分析。 。

主要原理是对接收到的源代码执行一系列 AST 扫描。 这里我们使用PSI结构，通过模式进行遍历来支持代码风格的整改和一些公共规则的检查。

原理概述

PSI结构示例

另外，以往的静态分析工具均依赖于Type-，其分析成本较高，且使用效率较低。 不同的是提供了No-Type-，它使用一些启发式规则进行无类型分析。

实验证明它可以对多种任务进行有效的分析，包括代码风格分析、基于规则的检测、代码不良气味检查等。

发表于ISSRE 2021[16]。

我们将项目开源在互联网上，目前有280个star，越来越多的开发者参与项目贡献。 您可以在以下地址获取源代码：

另外，经过短短半年的工作，已经被社区采纳。 从静态分析网站[17]可以看出，它已经成为官方认可的三大主要工具之一。

#开源治理：第三方库移植（升级/替换）

接下来，围绕开源治理方面。 我简单介绍一下我们做了哪些探索。

我们目前的重点是诊断和修复与第三方库相关的问题，即当第三方库由于漏洞或者其他问题而无法在项目中使用时，如何快速升级或替换。

##移动应用智能移植（从GMS到HMS）

背景挑战

我们先来看看初步的尝试。

由于一些市场因素，华为终端需要构建HMS（即）生态系统。 在这个过程中，有一个问题，就是海外市场的应用大部分都是基于GMS（ie）开发的，那么现有的应用如何快速迁移到HMS上呢？ 我们不能要求程序员重写一套应用程序，所以我们希望为开发者提供一个相对快速高效的工具，帮助他们快速将基于GMS的应用程序迁移到HMS生态中。

问题分析及解决方案

针对这一问题场景，我们联合华为内部多个部门共同打造了移动应用智能移植应用。 应用程序的主要架构如下图所示。 假设我们有一个GMS应用程序需要转换。 **步是识别其在应用内调用了哪些GMS接口，然后在GMS SDK层面自动将调用的接口映射到HMS SDK。 并自动适配HMS SDK上相应的API到应用程序的接口调用点，完成整个转换。

完成结果

作为HMS的核心能力之一，该应用已于2020年正式发布，帮助我们更快地构建HMS生态。 欢迎访问以下地址详细了解并试用：

全面开放51个服务、885个API

##不可信第三方库的智能移植

GMS到HMS只是库的移植。 我们可以将前期工作的移植能力推广到开源第三方库的治理上，为有风险的第三方库提供自动化修复能力。 这就是我们目前正在做的事情。

我们从开源项目代码仓库中收集了大量的数据，并根据这些代码仓库的原始数据构建了开源项目的知识图谱。 比如某个项目已经发布了哪些版本，哪个版本对应哪个版本，每个版本都包含哪些API，这个项目中有哪些API。 使用了哪些第三方库等等，一旦建立了所有代码仓库之间的关系，我们就可以对其进行大量的数据挖掘工作。 例如，我们可以挖掘一些业界主流库的低级或有漏洞的版本，看看社区是如何修复漏洞的，或者用哪些库来替代这些有风险的库。

###核心技术点1：开源库替换模式挖掘技术

这是我们正在做的**个工作，就是找出库之间的替换模式，从而为后续有风险的第三方库的替换和修复带来一些见解。

我们的总体思路如下所示。 对每个开源项目的历史进行挖掘和过滤，计算出每个项目的三方库演化历史（即项目的依赖变化顺序）。 获得变化序列后，引入序列模式挖掘算法。 在这个过程中，我们会结合一定的指标对结果进行过滤，包括热门库识别、时间修正等，以保证模型的准确性。

开源库替换模式挖掘技术

目前我们已经发现了1400多个有效的替代模式，这项工作在2020年中国软件大会上获得了三等奖。

我们在 SANER 2021 上发布了“A Multi-for”。在之前的工作思路基础上，我们引入了更多的数据过滤指标。 下图是这项工作的实现：

多用途 [18]

开源世界的数据非常庞大。 如何有效地过滤和发现真正有价值的数据，实际上是一件非常具有挑战性的事情。 我们在过滤过程中进行了深入的探索，引入了很多指标来帮助过滤。 这些指标被汇总到一个洞察库中。 基于库，我们孵化了一个网站：

下图展示了 目前的进展情况。 正如您所看到的，这个洞察库一直在不断发展和增强，网站页面将实时显示已确认的建议。 用户可以在这个网站上查看一些已知有风险的第三方库，以及业内大多数人都迁移到了哪些第三方库。 我们通过数据挖掘为您提供一些建议，以提高开发者修复有风险的第三方库的效率。

###核心技术点2：库替换场景API适配模式挖掘技术

仅有替换模式还不够。 当你用库B替换库A时，问题就出现了。 两个库之间的 API 可能不兼容。 这种情况我们应该怎么办呢？ 在前期挖掘工作的基础上，我们进行了进一步的探索，即库替换场景下的API适配模式挖掘。

这项工作还需要基于历史数据进行挖掘，即当库发生变更和迁移时，我们尽量提取上层代码的变更记录，利用形式化方法的技术去除API适配模型。 我们将这样的模式进行挖掘并以图形结构记录到系统中。 下图是一个简单的例子。 您可以阅读我们和俄罗斯团队在ISSRE 2021上联合发表的*新论文[19]，了解更复杂的实现细节。

库替换场景API适配模式挖掘技术[19]

下图是这项工作的内容。 当有变化动作时，我们会进行一系列的数据挖掘过程，包括数据分割、*小化、聚类、净化等，*终得到一个模式集，保证*终结果的有效性。

下面是从 org.json 替换为 .code.gson 的具体示例。 我们对这个例子中的代码转换进行了一系列的处理和挖掘，得到了右边的两个。 如果将来程序员遇到类似库替换的场景，我们可以通过应用程序自动适配代码。

可以看到，用不同的节点来记录变化，包括一些代码的增加和删除，都在这个结构体中进行了描述。

我们对一些典型的开源场景进行了实验，结果表明我们的方法可以挖掘出很多有效的，如下图左侧所示。 我们将挖掘的数据恢复到实例中并评估质量（主要是覆盖率）。 结果如下图右侧所示。 我们的方法在很多场景下仍然很有价值。 在大多数场景下，自适应准确率可以达到70%以上。

我们将以上工作整合到了，并于近期发布了IDEA插件的试用版（目前仅支持maven项目）。 欢迎大家尝试和体验：

下图是插件使用的示例。

安装插件：打开IDEA插件市场离线安装界面，选择安装包并点击。

扫描项目依赖：右键单击项目根目录或构建文件，点击->检查第三方库，查看项目所有易受攻击的依赖项。

查看关联漏洞：左键单击表格第二列，查看具体漏洞信息。 漏洞信息由内部漏洞收集平台提供，并经过内部审核。

库修复预览：选择修复建议后，点击按钮预览自动适配。

库修复适配：点击Apply按钮应用选择的适配（目前仅支持构建文件的自动适配）。

在IDEA中安装完插件后，右键maven项目，可以看到->Check Third-Party Libs菜单选项。 该选项用于检查maven项目中应用的第三方库。 触发该选项后，后台会自动分析项目，匹配漏洞库的数据，并对匹配的第三方库进行预警。

在上面的例子中，在项目依赖的第三方库中检测到了一系列漏洞。 用户可以点击查看漏洞详情。 用户确认为漏洞后，可用于自动/半自动修复漏洞。 我们提供修复前后的功能预览，Apply 功能将修复建议应用到项目中，以及回滚修复更改的功能。

# 代码智能合并

接下来简单介绍一下我们的代码智能合并创新工作，这是我们19年与北京大学研究团队联合研究的成果[20]。

##

现代软件开发越来越涉及团队，团队的代码需要定期同步、合并和提交。 尤其是在大型企业中，程序员会面临非常复杂的合并场景。 首先，团队规模越来越大。 其次，大量开源代码可能在项目中被复用。

比如华为的EMUI系统就基于做了一系列的开发和定制。 开发过程与并行。 然而，当项目进展到一定程度时，需要与开源的代码进行合并。 在这种合并场景中，冲突量将会非常巨大。 因此，大型企业的合并问题是一个非常令人痛苦的痛点。

我们围绕上述场景进行了一系列研究。 我们发现已经提供了一些合并功能来支持程序员在多个分支之间合并代码。 但它并不理解代码本身，而是更多地将代码视为文本来判断合并是否存在冲突以及如何合并。

行业技术

学术界在融合技术方面做了大量工作，越来越多的人关注这一领域：

当遇见

调查发现，传统并购技术仍存在许多问题需要解决。 以重构为例。

在大型项目中，我们会以一定的频率重构代码，整个代码的改动会非常大。 你甚至可能将一个方法抽象到它的父类中，或者移动一个方法，但实际上整个代码的语义并没有改变。 传统的合并技术不理解代码级操作，因此无法确定更改前后的语义是否等效。

因此，我们会发现，在重建场景下，传统的Merge算法会失败，尤其是应用*广泛的一种。 这将导致非常糟糕的合并结果。 合并后的代码很可能存在一定的语义问题（False），未解决的冲突不一定是真正的冲突（False）。

-意识到的

我们提出了“-Aware”的概念来尝试理解代码的变化来判断代码是否被重构。

如果发生重构，我们将使用代码理解技术来推断重构行为。 比如代码变化是上移（下推）还是下移（上拉），或者的代码()？ 当识别出重构的行为时，我们对同一代码片段执行更细粒度的匹配。 匹配完成后，对代码片段应用传统的合并算法，以更准确地合并代码。

##

下图是我们工作的总体思路：

：基于图形和感知的 java 半工具。[24]

##

这是这项工作的实验结果。

对于冲突代码块（ ），实验结果表明我们的方法可以显着减少潜在冲突块的数量。

对于合并后的代码（部分），相对于准确度有一定的下降，但有所提升（帮助程序员自动尽可能合并更多的代码块）。 因此，总体而言，好处更大，节省了程序员大量时间，同时精度损失很小。

自动编码的三个工具的 和 。

我们已经开源了这个作品，大家可以关注一下：

注：sum的计算公式如下

# 代码提交智能拆分

*后，我们想介绍一下我们在代码提交智能拆分方面的研究成果[25]。 我们在*近的 FSE 2021 会议上对此进行了报道，并很荣幸获得*佳论文奖。

##

如今，在企业内部提交代码时，程序员往往没有有效的提交代码控制工具来判断自己的提交是否符合高内聚、低耦合的原则。

我们希望代码的每次提交只能做一件事。 例如，仅在本次提交中修复某个错误，或者仅支持某个新的。

这就是我们的期望：

高凝聚力承诺

事实上，我们对公司内外的很多项目做了很多研究和分析，发现历史记录中实际上包含大量所谓的合并提交，即一个包含多个任务。 据统计，此类提交记录占11%~40%（MSR13/15为open-，for），这将大大增加项目的维护成本。

这是我们不提倡的：

合并提交

##

基于这个场景，我们希望能够智能理解用户提交并判断是否混有多个开发任务。 基于代码分析的技术将其拆分为多个原子或。 鼓励程序员单独提交每个组。 （我们也围绕这个工作做了扩展，比如程序员提交的时候应该怎么写？应该怎么写，更规范？应该归类为/bug修复/new？）

将代码分析技术和图匹配算法集成到图拆分算法中，将为程序员提供拆分建议，并尽量使每一个都满足高内聚和低耦合的原则。 下图是实现思路。

##

基于以上实现思路，我们提供了一个公共系统，源码已公开于：

我们把这个系统实现为一个工具，可以通过图形界面清晰地给程序员提示。 比如目前有很多开发任务混在一起，每个任务是什么，每个任务对应什么。 程序员可以通过这个工具快速确认。 如果他们不同意该工具的某些拆分，他们还可以手动集成一些组。 调整完成后，工具可以自动提交这些。 这样，一个几乎会自动分裂成多个满足高内聚原则的。

##

我们使用混合方法进行实验评估：

实地考察：我们对华为的两个内部项目进行了近9个月的实验。 我们邀请华为内部的程序员使用这个工具，同时监控程序员对工具结果的反馈，看看他们是否采纳了工具给出的建议。 ，并根据建议进行修改。

开放——我们在开源项目上也做了一些实验。

并通过三角测量分析提高我们对实验结果的信心[26]：

精度结果如下：

实地考察

打开-

事实证明，该工具给出的建议可能不是完全正确的，并且通常需要程序员进行一些微调。 但是工具可以为程序员提供更好的起点，并可以快速指导程序员制作更标准化的提交。

＃各个人＃＃

*后，围绕智能和值得信赖的软件开发主题，让我们谈谈我们软件分析实验室的一些当前思想。

实际上，程序分析技术可以嵌入软件开发的许多方面，例如：

编码过程包括常见的注释生成，程序生成，代码搜索等，以及API迁移，代码检查和维修，开源组件管理等。

我们还围绕单元测试的这一方面进行了一些探索，希望自动生成一些单元测试案例以提高研发效率。

代码检查通常与代码检查和代码维修结合

智能合并和冲突解决代码合并，智能提交，智能同步和智能选项

系统操作和维护智能补丁筛选，等等。

实际上，在软件开发的整个生命周期中，计划分析技术发挥了非常关键的作用，甚至逐渐发挥了根技术的作用。 我很高兴拥有这样的技术沙龙，我希望它可以吸引更多的老师，同学和行业同事讨论有关计划分析的更多主题。

就是我的报告，谢谢大家。

参考

[1] - 自动代码审核服务 - AWS云服务

[2]：

[3] Azure | 天蓝色

[4]与Azure -Azure进行调试| 文档

[5] 代码管理代码托管企业级代码管理平台- Cloud

[6] PMD-横码。

[7]阿里巴巴自行开发的代码管理平台技术的解密-Zhihu

[8] Zhang，Zhu，Yi Li，Guo，Lihua Liu和。 ：通过-patch对大规模补丁。 ACM/IEEE 42nd：in，ICSE-SEIP'20，第41-50页，纽约，纽约，美国，2020年。

[9] - 一站式软件研发管理平台

[10]根据法律开放

[11]修复 - ＃ - 固定 - 与 -

[12] | 独立部署和高效的产品管理服务

[13] - 2020年

[14]数据中的前10名和2020 -％253A％252F％252F %%

[15]| 对于代码，代码样式和错误的一组规则

[16]：for。 （Co.，Ltd），PETR（Co.，Ltd），（Co.，Ltd）和Liang（Co.，Ltd）

[17]（SAST）工具的列表，文件，构建工具等。

[18] h。 He，Y。Xu，Y。Ma，Y。Xu，G。Liang和M. Zhou，“多福”，“ 2021 IEEE”，以及（Saner），2021年，第72-83页，DOI：10.1109/ .2021.00016。

[19]第32届（ISSRE 2021）

[20] Bo Shen，Wei Zhang，Zhao，Liang，Zhi Jin和。 ：一个 - 意识。 proc.acm。 Lang。，3（），2019年。

[21] GIT合并

[22]，Paulo Borba和Paola。 2017年。合并。 1，（2017年）的ACM，59。

[23]朱和菲。 2018年。用于通过空间合并。 2，（2018年）的ACM，166。

[24] Bo Shen，Wei Zhang，Zhao，Liang，Zhi Jin和。 ：一个 - 意识。 proc.acm。 Lang。，3（），2019年。

[25] Bo Shen，Wei Zhang，Zhao，Zhao Wei，Liang和Zhi Jin。 ：基于图的 - 。 在第29届ACM关节上，ESEC/FSE 2021，第379–390页，纽约，纽约，美国，2021年。

[26]。 2004.：和混合：和混合约翰·W·西奇（John W Sage）320英镑29英镑。 护士12，1（2004年9月），82-83。

炫佑科技专注互联网开发小程序开发-app开发-软件开发-网站制作等