文章目录

CENTRIS: A Precise and Scalable Approach for Identifying Modified Open-Source Software Reuse
- abstract
- introduction
- Terminology and motivation
- - Terminology
  - Motivation
- Design of center
- - P1
  - P2
  - - 检测组件数据库中的主要OSS：
    - 提取应用代码：
    - 识别组件：
- Implement
- Evaluation
- - 指标评估
  - 对比试验
  - 可扩展
  - 重用模式的发现与学习
- Discussion
- - 软件漏洞管理

CENTRIS: A Precise and Scalable Approach for Identifying Modified Open-Source Software Reuse

ICSE 软件工程A会

abstract

Open-source software(OSS) is widely reused as it provides convenience and efficiency in software development.

Despite evident benefits, unmanaged OSS components can introduce threats, such as vulnerability propagation and license violation.
非托管开源软件的组件可能会引入威胁，例如漏洞传播和许可证违规。

Unfortunately, however identifying reused OSS components is a challenge as the reused OSS is predominantly modified and nested.

不幸的是，由于复用的开源软件被修改和嵌套，识别重用的开源组件是挑战。

By segmenting an OSS code base and detecting the reuse of a unique part of the OSS only, CENTRIS is capable of precisely identifying modified OSS reuse in the presence of nested OSS components.

通过分割开源软件代码库和进检测独特的开源软件重用部分，centris可以在嵌套开源组件的情况下精准识别修改后的开源软件重用。

For scalability, CENTRIS eliminates redundant code comparisons and accelerates the search using hash functions.

When we applied CENTRIS on 10,241 widely-employed Github projects, comprising 229,326 versions and 80 billion lines of code, we observed that modified OSS reuse is a norm in software development, occurring 20 times more frequently than exact reuse.

修改后的代码重用在软件开发中是一种常见现象，并且发生频率是精确重用的20倍。

Nonetheless, CENTRIS identified reused OSS components with 91% precision and 94% recall in less than a minute per application on average, whereas a recent clone detection technique, which does not take into account modified and nested OSS reuse, hardly reached 10% precision and 40% recall.

尽管如此，centris识别重用开源组件的精确率是91，召回是94，每个应用上的识别时间均小于1分钟；而最近的克隆检测技术几乎达不到10%的精确率和40的召回。

introduction

开源软件的数量急剧增加，在软件开发中使用OSS通常会提高可靠性，因为OSS一般会受到多方的公开审查。然而如果在没有适当管理的情况下重用OSS会损害软件的可维护性和安全性。

防止这种不良情况的一种有效解决方案是software composition analysis(SCA) 软件成分分析，SCA的目的是有效识别目标程序中包含的OSS组件，使用SCA可以有效跟踪OSS组件在软件中重用的方式和内容，从而可以通过修补已知漏洞减轻安全威胁，并避免潜在的许可证违规情况。

然而不幸的是，精确识别目标软件的OSS组件变得越来越有挑战性，主要由于当前OSS开发的最新趋势：

修改后的OSS重用：开发人员通常并不重用现有的OSS，而是只使用其中一部分，或者修改源代码或结构。
嵌套OSS组件：复用的OSS组件可能包含若干子OSS组件。
OSS项目和代码量的迅速增长。

上述因素共同影响SCA的准确性和可扩展性。

现有的SCA技术假设重用的OSS基本上没有修改或仅以有限的方式修改，因此识别修改后的重用时会产生误报。例如OSSPolice无法识别目录结构被修改后软件中的OSS组件，克隆检测技术无法识别嵌套的OSS项目，并且上述两种技术都很难应用于大型OSS代码库，没有可扩展性。

CENTRIS是一种旨在克服上述缺陷的SCA技术，即使在任意嵌套的情况下，CENTRIS也能精确的有效检测修改后的OSS重用。对于可扩展性，CEN使用了冗余消除的技术，即首先收集一个所有版本的所有函数，然后去除跨版本的函数中的所有冗余函数。这种方法在降低空间复杂度方面极其有效，因为跨版本的增量代码明显小于原项目的代码库大小。

为了识别修改的OSS，采用代码分段技术，即使用松散匹配来检查目标软件和OSS之间的代码相似度是否大于预定义的阈值，但是在嵌套OSS时简单的使用这种方法会产生误报。因此作者将OSS分为应用代码（OSS的唯一部分）和借用代码（嵌套的第三方软件的一部分），去掉借用代码，之分析应用代码的复用模式进行组件识别。

使用Github上10，241个公共C/C++存储库，包括229，326个版本和800亿行代码（Line of code， Loc），在交叉比较实验中，作者发现存在95%的检测的组件在修改后被重复使用。尽管如此，CEN仍以91的准确率和94的召回率成功识别出重复使用的组件。

Terminology and motivation

Terminology

目标软件：表示要从中识别重用OSS组件的软件
OSS组件是指整个OSS包，有时也指OSS中包含的函数，简称组件
OSS重用是指利用全部或部分OSS函数
软件项目指应用程序和借用代码的组合集
借用代码表示由重用的OSS组成的部分，即第三方软件
应用代码指软件项目的原始部分，不包括来自其他OSS的代码
OSS重用模式：根据代码和结构变化分为四类
- 精确重用(E)：整个OSS在步做修改的情况下被重用
- 部分重用§：仅重用OSS某些部分
- 结构改变重用(SC)：在目标软件中结构被改变，即改变原始文件或目录的名称或位置，例如代码合并
- 代码更改重用(CC)：通过源码更改并重用OSS的情况

后三种均属于修改重用，可以同时发生。

Motivation

假设要是别ArangoDB中重用的OSS组件，CEN识别出总共29个OSS组件，修改后的重用模式在该目标软件中异常突出，有22个被修改，其中重用的函数与原始OSS在不同的目录中，例如GoogleTest，或者代码库被部分更新，例如Curl。下图详细说明了五个已识别的OSS组件。此外还有21个组件以嵌套组件的形式被重用，例如TZ被V8重用，V8又被ArangoDB重用。

下图为CEN与SCA和克隆检测方法的对对比说明：

Design of center

CEN包括两个步骤：

P1构建OSS组件数据库
P2识别目标软件中重用的OSS组件

P1中使用一种称为冗余消除的技术，实现可扩展的组件识别；通过消除每个OSS项目版本之间的冗余来降低组件识别的空间复杂性。一个OSS项目中所有函数都被转换为OSS签名存储在数据库中。

P2中使用代码分割技术，仅分析OSS的应用程序代码在目标软件中的重用模式，以最大限度的减小组件检测中的误报。

设计假设：CEN旨在识别源代码级别的OSS组件，以函数作为单元识别。CEN使用函数解析器在数据集中所有版本的OSS中提取函数，并执行轻量级文本预处理以通过删除注释、\t、\n和空格来规范化函数。

P1

OSS在更新时并不是所有代码都是新开发的，因此对不同版本的一些通用部分与目标软件进行了冗余比较。生成OSS签名的流程如下：

首先提取所有版本的OSS中的所有函数
创建于OSS版本总数一样多的bin
当一个特定的函数出现在i个不同版本的OSS中时，该函数联通该函数所属的版本信息以及每个版本的路径信息都会存贮在第i个bin中

所有函数都根据设计假设进行了文本预处理，使用LSH局部敏感哈希应用计算签名，支持测量两个哈希之间的相似性。

P2

在此阶段，CEN识别目标软件中重用的OSS组件。

通过预定义截止值来测量两个软件项目之间每个函数对的距离，表明两个输入函数之间的句法差异。

距离=0，完全相同
0<距离<=截止值，相似
距离>截止值，不同

公共函数：两个项目之间相似且相同的函数对被确定为公共函数。

基于相似度阈值的松散匹配：当发生OSS嵌套或目标软件中仅包含OSS的借用代码时，可能存在误报。提出两个概念：

主要OSS：指不包括任何第三方软件的OSS。
代码分段：如果在组件识别中只考虑OSS的应用程序代码，则不会出现第三方OSS的误报。

组件识别步骤：
0. 提取目标软件的所有函数，文本预处理和LSH算法计算

检测组件数据库中的主要OSS（应用OSS）
从所有OSS项目中提取应用代码
识别目标软件中的组件

检测组件数据库中的主要OSS：

设S为要检查是否包含第三方软件的OSS，检测S与组件数据库中的每个OSS之间的公共函数，如果有有一个OSS项目于S有一个或多个公共函数，则可以确定S和X的关系属于下述四个类别之一：

S和X共享广泛使用的代码
S和X同时重用其他一些OSS项目
S重用X
X重用S

R2和R3意味着S至少包含一个第三方软件，而R1和R4则可以确定S是主要OSS。

事实上，R1与其他三个关系相反，因为S和X之间的公共函数很少。因此确定S是否为主要OSS的主要挑战是区分R4与（R2和R3）.

如何区分：关注S和X之间公共函数何时首次出现在每个OSS中，并将之定义为函数的诞生时间，假设X重用S，那么特定重用函数f在S中的诞生时间将早于在X中的诞生时间。时间的先后顺序确定谁重用谁

相似度得分公式：

仅考虑在X中出现早于S的公共函数来衡量相似度分数，已识别R2和R3关系。将一个函数的所有记录版本中最早版本的发布日期指定为该函数在OSS的诞生时间。此外广泛使用的通用代码，例如散列函数或错误处理例程，可以同时存在于S和X中，作者将⊙用作阈值，最后如果X满足以下条件，确定X属于R2或R3关系：

作者将满足等式1的每个X都视为S的可能成员，并存储；否则S是主要的OSS。

提取应用代码：

算法如下，

识别组件：

令T为目标软件，S为组件数据库中的OSS，为了识别S是否为T的正确组件，需要计算T和S之间的代码相似度得分。如果S是主要OSS，则SA=S。相似度得分计算公式：

T和S之间可能存在通用的代码，如R1关系，因此使用阈值过滤；当相似度大于等于阈值时，则S为正确复用OSS，在所有OSS中循环即可得到目标软件的一组OSS组件。

CEN的优点：

在识别阶段不依赖结构信息，无论结构如何变化都可以识别组件；
无论OSS是否嵌套，只要代码复用率大于阈值，就可以识别；
代码分段可以减少误报，还有助于识别严重修改的组件；

版本标识：为了识别每个组件的重用版本，关注OSS组件的重用函数。在修改重用中，可以在目标软件中重用多个版本的函数。因此需要为每个重用函数分配一个权重，使用TF-IDF加权算法，将较大权重分配给较少版本的函数。TF指某个函数在特定版本中出现的频率，IDF指包含该函数的版本数量的倒数。

n为OSS的版本总数，V(f)为特定函数f的所属版本，权重函数W=log(n/V(f))。在对所有函数进行评分后，确定得分最高的使用版本。

重用模式分析：通过LSH的距离测量重用模式，是否被更改。分析重用函数与原始函数的路径差异来衡量结构变化。

Implement

CEN包含三个模块：OSS收集器，预处理器和组件检测器。

收集器：收集流行的OSS项目的源代码
预处理器：通过去冗余生成OSS签名，通过代码切分提取OSS的应用代码
组件检测器：对目标软件执行实际的组件识别

大约1000行py代码，不包括外部库。

收集了所有超过100颗star的存储库，包括linux内核，Openssl，tensorflow等。

解析器使用的通用Ctags，快速且准确的基于开源正则表达式的解析器。

LSH算法使用TLSH会产生较少的误报，并且具有合理的散列和比较速度以及输入大小的低影响。截止值设为30.

Evaluation

方法：首先对所有存储库进行交叉比较实验，选择每个OSS的代表性版本（即函数最多的版本），由于在一个OSS的不同版本中重用的组件大多相似，因此仅识别每个OSS的代表版本的组件，并测量检测精度。使用TP、FP、FN、precision和recall评估。

ground truth建立：利用以下3个因素验证检测结果：

path，重用函数的文件路径（检测到的组件名称包含在重用函数路径中的情况）
头文件：配置OSS名称的头文件
元数据文件：OSS顶层目录的README、LICENSE和COPYING文件之一

如果检测到的OSS的上述因素之一包含在目标软件中，则确定检测到的OSS为目标软件的正确组件。

多级验证：首先通过上述3个因素自动验证是否出现，而后对于剩余结果手动分析，例如注释中是否包含了识别的指定OSS名称。

通过交叉验证选择合适的值来评估每个验证的结果。当小于0.1时，检测到的成分中的正确成分的比例显著下降。总体结果表明，广泛使用的代码通常在不同的OSS项目之间共享，并且只占每个OSS项目的一小部分（通常不到10%），作者以0.1平衡召回率和精度。如下图所示

指标评估

在交叉比较结果中，自动验证通过了8066个结果，剩余6931使用手工验证分析，手动查看了路径，头文件和元数据文件以及源代码中复用的源代码和注释，以确定识别OSS是否为正确的组件。

版本识别：

对比试验

与DejaVu进行对比，DejaVu基于代码克隆技术的通过检测项目级克隆来分析GitHub存储库之间的软件依赖关系。对比结果如下：

可扩展

所有版本的函数总数为2205896465个，消除冗余后仅剩49330494个（2.2%），表明比较空间的大小与所有函数相比可以减少45倍。

CEN处理每个目标应用程序平均花费不到1分钟。

与DejaVu进行时间对比评估可扩展性

重用模式的发现与学习

在实验结果中发现44%的OSS项目正在重用至少一个其他的OSS，修改后的重用占所有检测结果的95%。

两个关键观察：

部分重用占所有下修改重用的97%，开发人员大多只重用他们所需的部分OSS代码库。
代码和结构变化时常发生，53%更改至少一项原始功能，26%更改了原始结构。主要是开发人员试图将重用的功能调整到他们的软件，例如更改变量名称，修复从重用的OSS传播的软件漏洞等。

此外OSS的重用功能通常合并在一个文件中，而不是分散在不同的结构中。

Discussion

软件漏洞管理

通过参考国家漏洞数据库NVD，可以获得每个报告的漏洞的受影响的软件和版本信息，即通用平台枚举CPE。CEN发现了572个OSS项目至少包含一个其他易受攻击的OSS组件，其中有27个OSS仍在对最新版本的OSS进行重用。例如Godot重用了JPEG压缩器的jpgd.cpp文件。

基于NLP的软件安全研究（一）相关推荐

基于NLP的软件安全研究（三）
文章目录 jTrans: Jump-Aware Transformer for Binary Code Similarity Detection background Problem definiti ...
基于NLP的软件安全研究（二）
文章目录 Cross-Language Binary-Source Code Matching with Intermediate Representations abstract introduct ...
基于NLP处理企业家传记文档
基于NLP处理中国企业家文档 1. 实验环境本次技术采用Python编程,Python可以从官网https://www.python.org/下载,选出适合用户操作系统的二进制发行版后,按提示一步一 ...
matlab 基于GUI的PID研究
基于GUI的PID研究本例子中设计一个PID控制器来研究不同参数对输出结果的影响,PID控制器由比例单元 P.积分单元 I 和微分单元 D 组成.PID 控制器是一个在工业控制应用中常见的反馈回路部 ...
直播 | 彩云科技CEO袁行远：NLP与冒险游戏研究一览
「PW Live」是由 PaperWeekly 和 biendata 共同发起的学术直播间,旨在帮助更多的青年学者宣传其最新科研成果.我们一直认为,单向地输出知识并不是一个最好的方式,而有效地反馈和交 ...
微软开源基于云的生理学研究工具
Bio Model Analyzer是一款微软基于云的生理学研究工具,可以用于对化细胞交互和通信进行建模,现已经在GitHub上开源,在MIT许可之下. 研究人员使用Bio Model Analyze ...
基于支持向量机的谐波分析研究与实现
基于支持向量机的谐波分析研究与实现-附Matlab源码文章目录基于支持向量机的谐波分析研究与实现-附Matlab源码前言一.支持向量机分析电力谐波的原理二.基于 SVM 的电力谐波分析与仿真 ...
基于NLP的书法字体分析、统计及可视化
基于NLP对书法字体进行分析.统计.可视化选题3: 对十二个"一"的文艺创作作业进行文本分析.统计和可视化任务主题: 对全体同学的文艺创作进行文本 ...
基于无线信号的手势识别研究现状调查
摘要:进入21世纪以来,人机交互技术持续发展,手势识别是代表之一.2013年,华盛顿大学的研究人员提出了使用无线信号进行手势识别的方法,给传统的手势识别技术带来的一定的挑战,但是这一技术并不是很成熟, ...

基于NLP的软件安全研究（一）