漏洞自动修复研究综述

软件漏洞是计算机软件系统安全方面的缺陷, 给现代软件及其应用数据的完整性、安全性和可靠性带来巨大威胁. 人工治理漏洞费时且易错, 为了更好应对漏洞治理挑战, 研究者提出多种自动化漏洞治理方案, 其中漏洞自动修复方法近来得到研究者广泛关注. 漏洞自动修复技术旨在辅助开发人员修复漏洞, 涵盖漏洞根因定位、补丁生成、补丁验证等功能. 现有工作缺乏对漏洞修复技术系统性的分类与讨论, 为了促进漏洞修复技术发展, 加深研究人员对漏洞修复问题的认知理解, 对现有漏洞修复方法技术的理论、实践、适用场景和优缺点进行全面洞察, 并撰写了漏洞自动修复技术的研究综述. 主要内容包括: (1)按照修复漏洞类型不同整理归纳特定类型漏洞的修复方法以及通用类型漏洞的修复方法; (2)按照所采用的技术原理将不同修复方法进行分类与总结; (3)归纳漏洞修复主要挑战; (4)展望漏洞修复未来发展方向.     

漏洞类型聚类的层次化漏洞修复模型

针对传统漏洞修复策略存在难以确定同一危害等级漏洞修复优先次序的问题,提出了一种基于漏洞类型聚类的层次化漏洞修复(vulnerability remediation based on vulnerability type clustering,VR-VTC)模型。首先,运用PSO-K-means(particle swarm optimization K-means)算法对漏洞信息进行聚类分析,再根据每种漏洞类型高危、中危、低危各个危害等级的百分比,计算每种漏洞类型的威胁因子;然后,将目标主机漏洞划分为主机、漏洞类型威胁等级、漏洞类型和漏洞4个层次,再采用"自下而上、先局部后整体"的漏洞修复策略,提出一种基于漏洞类型的层次化漏洞修复方法。实验结果表明,VR-VTC模型可为用户提供细粒度的漏洞修复策略。     

面向项目版本差异性的漏洞识别技术研究

开源代码托管平台为软件开发行业带来了活力和机遇,但存在诸多安全隐患。开源代码的不规范性、项目依赖库的复杂性、漏洞披露平台收集漏洞的被动性等问题都影响着开源项目及引入开源组件的闭源项目的安全,大部分漏洞修复行为无法及时被察觉和识别,进而将各类项目的安全风险直接暴露给攻击者。为了全面且及时地发现开源项目中的漏洞修复行为,设计并实现了基于项目版本差异性的漏洞识别系统—VpatchFinder。系统自动获取开源项目中的更新代码及内容数据,对更新前后代码和文本描述信息进行提取分析。提出了基于安全行为与代码特征的差异性特征,提取了包括项目注释信息特征组、页面统计特征组、代码统计特征组以及漏洞类型特征组的共40个特征构建特征集,采用随机森林算法来训练可识别漏洞的分类器。通过真实漏洞数据进行测试,VpatchFinder的精确率为84.35%,准确率为85.46%,召回率为85.09%,优于其他常见的机器学习算法模型。进一步通过整理的历年部分开源软件CVE漏洞数据进行实验,其结果表明68.07%的软件漏洞能够提前被VpatchFinder发现。该研究结果可以为软件安全架构设计、开发及成分分析等领域提供...     

收益与代价相结合的漏洞修复模型

漏洞修复是增强网络安全性的重要方法,选择性地修复网络中漏洞具有现实意义.提出一种收益与代价相结合的漏洞修复模型BCVRM.漏洞修复收益评价算法基于简化的攻击图生成算法,对比漏洞修复前后网络整体及相关各类型主机安全状态的提升,给出漏洞修复的总收益.漏洞修复代价评分系统基于CVSS对漏洞属性信息的描述,给出单个漏洞修复代价的评分规则,然后结合漏洞所属主机类型及漏洞分布情况给出网络漏洞修复代价.实例网络分析表明,该模型能够为网络管理人员提供一个切实可行的网络漏洞修复策略.     

基于软件漏洞的克隆代码稳定性评估

针对克隆代码与非克隆代码产生"漏洞"倾向性的问题进行了研究,基于"漏洞"对不同类型克隆和非克隆代码进行了比较分析。首先提取软件系统中具有漏洞的代码,并使用克隆检测工具检测出软件的克隆代码;其次分别提取能够产生"漏洞"的克隆和非克隆代码,并分别计算不同克隆类型和非克隆的BOC漏洞密度和LOC漏洞密度;最后对type-1、pure type-2、pure-type3的克隆和非克隆漏洞密度进行了对比分析,并对代码中产生的"漏洞"类型进行分类分析,使用曼—惠特尼检验(WMM)验证了结果的有效性。实验结果表明type-1类型的克隆更容易产生"漏洞",pure type-3类型的克隆引入漏洞的几率相对较小。研究还得出在克隆和非克隆代码中分别存在出现频率较高的"漏洞"集合,增加了对克隆特性的理解,帮助软件设计和开发人员减少代码克隆对软件造成的负面影响。     

Web应用中代码注入漏洞的测试方法

研究Web应用中的代码注入漏洞,总结分析该类漏洞的特征,修正并扩展其定义,把漏洞的产生原因归纳为2类编码错误。提出一套通过识别2类编码错误发现Web应用中代码注入漏洞的测试方法。实验结果证明,该方法可减少测试工作量,能全面有效地测试Web应用中的代码注入漏洞和潜在的风险点。     

基于关键路径测试的安全补丁存在性检测

漏洞的修复对于应用软件的安全至关重要。为了能够及时地修复所有已知漏洞,安全防护人员需要准确地检测一个安全补丁是否被应用。提出一个基于关键路径的语义层面的漏洞补丁存在性检测工具PatchChecker,通过找寻一条在漏洞修复前后发生改变的路径,分析其语义特征,生成能代表漏洞补丁的签名信息;利用这一签名信息,在目标程序中找出对应路径进行比较,判断漏洞补丁的应用情况。PatchChecker通过聚焦于单一路径,在提升对细节变化检测能力的同时,避免了未知代码修改带来的干扰。实验表明,PatchChecker能够以较高的准确率检测漏洞补丁是否被应用。     

主动式漏洞检测与修复系统的设计与实现

针对内部网络与互联网物理隔离补丁升级实时性不强、自主研发系统的漏洞较多、复杂关联的代码共享所造成的软件漏洞等问题,文章提出一种新的网络安全漏洞检测与修复系统.该系统由控制台、检测引擎、插件和数据库四大模块组成,其中检测引擎根据用户定制的检测任务信息调度相应检测插件执行并返回结果,插件具体完成信息探测、渗透测试和漏洞修复功能.该系统在结构设计上采取了分层式设计思想,该结构不仅可扩展性强,又保证了系统的稳定性和容错能力;在功能上设计上基于构件化、可定制的思想,确保系统部署使用高效灵活.     

基于CVE-2012-0158的软件漏洞分析与利用

软件漏洞是引起计算机安全问题的重要根源之一。以CVE-2012-0158漏洞为例,探索了漏洞产生的原理及利用方式。通过动态分析方法简要地描述该漏洞被触发时,程序所执行的代码及函数调用情况,从本质上解析了漏洞产生的原因及危害,从而引起人们对安全开发、避免产生漏洞的重视。给出了通过基于安全性的软件开发方式,可以从根源上减少软件漏洞引起的计算机安全问题,从而提升系统和软件的安全性能。     

基于增强AST的图神经网络函数级代码漏洞检测方法

软件漏洞逐年递增，安全问题愈发严重。在软件项目的交付阶段对原始代码进行漏洞检测可以有效避免后期运行时的安全漏洞，而代码漏洞检测依赖于有效的代码表征。传统的基于软件度量的表征方法与漏洞关联性较弱，难以对漏洞信息进行有效表征。近年来，机器学习为漏洞的智能化发现提供了新的思路，但该方法同样可能遗漏关键的代码特征信息。针对以上问题，文中在传统抽象语法树(AST)上增加控制依赖、数据依赖和语句序列边生成增强抽象语法树(EXAST)图结构，对原始代码进行表征以更好地处理代码结构化信息，并采用词向量嵌入算法(Word2Vec)将代码信息初始化为机器能够识别和学习的数值向量。同时，在传统的图神经网络(GNN)中引入门控循环单元(GRU),构建图识别模型，以缓解梯度消失并加强图结构中长期信息的传播，从而增强了代码执行的时序关系，提高了漏洞检测的准确度。最后在SARD公开数据集上对模型进行对比测试，实现了函数粒度的代码漏洞检测，相比传统的漏洞检测方法，准确率和F1分值分别最大提高了32.54%和44.99,实验结果证明了所提方法对代码漏洞检测的有效性。     

Experience report: investigating bug fixes in machine learning frameworks/libraries

Machine learning (ML) techniques and algorithms have been successfully and widely used in various areas including software engineering tasks. Like other software projects, bugs are also common in ML projects and libraries. In order to more deeply understand the features related to bug fixing in ML projects, we conduct an empirical study with 939 bugs from five ML projects by manually examining the bug categories, fixing patterns, fixing scale, fixing duration, and types of maintenance. The results show that (1) there are commonly seven types of bugs in ML programs; (2) twelve fixing patterns are typically used to fix the bugs in ML programs; (3) 68.80% of the patches belong to micro-scale-fix and small-scale-fix; (4) 66.77% of the bugs in ML programs can be fixed within one month; (5) 45.90% of the bug fixes belong to corrective activity from the perspective of software maintenance. Moreover, we perform a questionnaire survey and send them to developers or users of ML projects to validate the results in our empirical study. The results of our empirical study are basically consistent with the feedback from developers. The findings from the empirical study provide useful guidance and insights for developers and users to effectively detect and fix bugs in MLprojects.     

面向软件安全性缺陷的开发者推荐方法

软件开发与维护过程中常会出现一些安全性缺陷,这些安全性缺陷会给软件和用户带来很大的风险.安全性缺陷在修复过程中,其修复级别和质量要求往往高于一般性的缺陷,因此,推荐出富有安全性经验的开发者及时有效地修复这些安全性缺陷非常重要.现有的开发者推荐技术在推荐开发者时仅仅考虑了开发者的历史开发内容,很少考虑到开发人员的安全性缺陷修复经验和修复质量等因素,所以这些技术不适用于安全性缺陷的开发者推荐.本文针对安全性缺陷的修复提出了一种有效的软件开发者推荐方法SecDR.SecDR在推荐开发者时不仅考虑了开发者的历史开发内容（与安全性相关）,还分析了开发者的修复质量和历史修复缺陷的复杂度等因素.此外,SecDR还实现了开发者的多经验级别推荐：推荐初级开发者修复简单的安全性缺陷,高级开发者修复复杂的安全性缺陷.本文在三个开源项目（Mozilla,Libgdx,ElasticSearch）上分别对SecDR推荐开发者进行有效性验证.通过对比实验证明,SecDR针对安全性缺陷推荐开发者相比于其他方法（如：DR_PSF）的推荐精度平均高出19%~42%.另外,实验对比了SecDR与实际开发人员的分配情况,结果显示SecDR可以更好地规避不合理的软件开发者的推荐.     

基于高斯过程的缺陷定位方法

在软件系统中,缺陷定位是缺陷修复的一个关键环节,如果能将缺陷自动定位到很小的范围,将会极大地降低缺陷修复的难度.基于高斯过程提出了一种缺陷定位方法（GPBL）,即针对每个缺陷,向开发人员推荐这个缺陷可能存在于哪些源文件中,从而帮助开发人员快速修复缺陷.为了验证方法的有效性,采集了开源软件Eclipse 和Argouml 中的数据,实验结果表明,高斯过程缺陷定位的查全率和查准率平均分别为87.16%和78.90%.与基于LDA的缺陷定位方法进行比较,表明高斯过程更能准确定位缺陷的位置.     

Firefox缺陷跟踪系统中的用户反馈

缺陷追踪是软件项目管理的一个重要环节，是保证现代大规模开源软件开发顺利进行并持续提高软件质量的必要手段.目前，大部分开源软件都使用开放的缺陷跟踪系统进行软件缺陷的管理.它允许用户向开发者提交系统故障（即defect类型缺陷）以及系统改进建议（即enhancement类型缺陷），但是这些用户的反馈所起的作用尚未得到充分研究.针对这一问题，对Firefox的缺陷跟踪系统进行实证研究，收集了2018年和2019年提交的19 474份Firefox Desktop以及3 057份Firefox for Android缺陷报告.在此基础上，对比分析了普通用户和核心开发者提交的缺陷在数量、严重性、组件分布、修复率、修复速度以及修复者上的差别，并调查了缺陷报告的撰写质量与缺陷处理结果和修复时间的关系.主要发现包括：（1）当前缺陷追踪系统中普通用户人数众多，但参与程度较浅，86%的用户只提交过一个缺陷，其中，高严重等级的缺陷不超过3%；（2）普通用户提交的缺陷主要分布在和用户交互相关的UI组件上（例如地址栏、音频/视频等），然而还有43%的缺陷由于缺乏充分描述信息而难以准确地定位到具体的关联组件；（3）在缺陷处理结果上，由于查重系统以及缺陷填报系统在设计上过于简单，致使普通用户提交的大量缺陷被处理为“无用”缺陷，缺陷修复率低于10%；（4）在缺陷修复流程上，由于普通用户难以准确、充分地描述缺陷，导致系统对其重视程度不足，普通用户提交缺陷的处理流程也比核心开发者提交的复杂，平均需要多花至少8天的时间进行修复.上述研究结果揭示了当前缺陷追踪系统在用户参与激励机制、缺陷自动查重以及缺陷报告填写智能辅助等方面的不足，能够为缺陷跟踪系统开发者和管理者改进系统、提高普通用户对开源软件的贡献提供参考.     

SMTLOC: 基于多源频谱的SMT求解器缺陷定位

SMT求解器作为重要的基础软件, 其存在的缺陷可能会导致依赖于它的软件功能失效, 甚至带来安全事故. 然而, 修复SMT求解器缺陷是一个十分耗时的任务, 因为开发者需要花费大量的时间和精力来理解并找到缺陷的根本原因. 虽然已有许多软件缺陷定位方面的研究, 但尚未有系统的工作研究如何自动定位SMT求解器缺陷. 因此, 提出一种基于多源频谱的SMT求解器缺陷定位方法SMTLOC. 首先, 对于给定的SMT求解器缺陷, SMTLOC提出一种枚举算法, 用以对触发该缺陷的公式进行变异, 从而生成一组不触发缺陷, 但与触发缺陷的公式具有相似执行路径的证人公式. 然后, SMTLOC根据证人公式的执行路径以及SMT求解器的源码信息, 提出一种融合覆盖频谱和历史频谱的文件可疑度计算方法, 从而定位可能存在缺陷的文件. 为了验证SMTLOC的有效性, 收集60个SMT求解器缺陷. 实验结果表明, SMTLOC的缺陷定位效果明显优于传统的频谱缺陷定位方法, SMTLOC可以将46.67%的缺陷定位在TOP-5的文件内, 定位效果提升了133.33%.     

ChangeLocator: locate crash-inducing changes based on crash reports

Software crashes are severe manifestations of software bugs. Debugging crashing bugs is tedious and time-consuming. Understanding software changes that induce a crashing bug can provide useful contextual information for bug fixing and is highly demanded by developers. Locating the bug inducing changes is also useful for automatic program repair, since it narrows down the root causes and reduces the search space of bug fix location. However, currently there are no systematic studies on locating the software changes to a source code repository that induce a crashing bug reflected by a bucket of crash reports. To tackle this problem, we first conducted an empirical study on characterizing the bug inducing changes for crashing bugs (denoted as crash-inducing changes). We also propose ChangeLocator, a method to automatically locate crash-inducing changes for a given bucket of crash reports. We base our approach on a learning model that uses features originated from our empirical study and train the model using the data from the historical fixed crashes. We evaluated ChangeLocator with six release versions of Netbeans project. The results show that it can locate the crash-inducing changes for 44.7%, 68.5%, and 74.5% of the bugs by examining only top 1, 5 and 10 changes in the recommended list, respectively. It significantly outperforms the existing state-of-the-art approach.     

A study on the changes of dynamic feature code when fixing bugs: towards the benefits and costs of Python dynamic features

Dynamic features in programming languages support the modification of the execution status at runtime, which is often considered helpful in rapid development and prototyping. However, it was also reported that some dynamic feature code tends to be change-prone or error-prone. We present the first study that analyzes the changes of dynamic feature code and the roles of dynamic features in bug-fix activities for the Python language. We used an AST-based differencing tool to capture fine-grained source code changes from 17926 bug-fix commits in 17 Python projects. Using this data, we conducted an empirical study on the changes of dynamic feature code when fixing bugs in Python. First, we investigated the characteristics of dynamic feature code changes, by comparing the changes between dynamic feature code and non-dynamic feature code when fixing bugs, and comparing dynamic feature changes between bug-fix and non-bugfix activities. Second, we explored 226 bug-fix commits to investigate the motivation and behaviors of dynamic feature changes when fixing bugs. The study results reveal that (1) the changes of dynamic feature code are significantly related to bug-fix activities rather than non-bugfix activities; (2) compared with non-dynamic feature code, dynamic feature code is inserted or updated more frequently when fixing bugs; (3) developers often insert dynamic feature code as type checks or attribute checks to fix type errors and attribute errors; (4) the misuse of dynamic features introduces bugs in dynamic feature code, and the bugs are often fixed by adding a check or adding an exception handling. As a benefit of this paper, we gain insights into the manner in which developers and researchers handle the changes of dynamic feature code when fixing bugs.     

Just-in-time defect prediction for software hunks

Just-in-time defect prediction can remind software developers and managers to verify and fix bugs at the moment they appeared, thus improving the effectiveness and validity of bug fixing. Existing studies mainly focus on just-in-time prediction for software files (JIT-F). JIT-F is a binary classification problem, which classifies (hence predicts) a file change as buggy or clean. This article provides a detailed analysis of just-in-time defect prediction for software hunks (JIT-H), which predicts bugs at a finer level of granularity, and hence further improves the efficiency of bug fixing. Classification is performed using the ensemble technique of bagging—aggregated combinations of random under sampling plus multiple classifiers (J48 and Random Forest). An empirical study with 10 open source projects was conducted to validate the effectiveness of JIT-H. Experimental results show that JIT-H is effective at predicting defects in software hunk changes. Compared with JIT-F, JIT-H is more cost effective. Additionally, analysis on the change features indicates that Text Vector features and hunk change level features are of more importance than features in other groups and levels.     

Understanding the triaging and fixing processes of long lived bugs

ContextBug fixing is an integral part of software development and maintenance. A large number of bugs often indicate poor software quality, since buggy behavior not only causes failures that may be costly but also has a detrimental effect on the user’s overall experience with the software product. The impact of long lived bugs can be even more critical since experiencing the same bug version after version can be particularly frustrating for user. While there are many studies that investigate factors affecting bug fixing time for entire bug repositories, to the best of our knowledge, none of these studies investigates the extent and reasons of long lived bugs.ObjectiveIn this paper, we investigate the triaging and fixing processes of long lived bugs so that we can identify the reasons for delay and improve the overall bug fixing process.MethodologyWe mine the bug repositories of popular open source projects, and analyze long lived bugs from five different perspectives: their proportion, severity, assignment, reasons, as well as the nature of fixes.ResultsOur study on seven open-source projects shows that there are a considerable number of long lived bugs in each system and over 90% of them adversely affect the user’s experience. The reasons for these long lived bugs are diverse including long assignment time, not understanding their importance in advance, etc. However, many bug-fixes were delayed without any specific reasons. Furthermore, 40% of long lived bugs need only small fixes.ConclusionOur overall results suggest that a significant number of long lived bugs may be minimized through careful triaging and prioritization if developers could predict their severity, change effort, and change impact in advance. We believe our results will help both developers and researchers better to understand factors behind delays, improve the overall bug fixing process, and investigate analytical approaches for prioritizing bugs based on bug severity as well as expected bug fixing effort.     

Do bugs foreshadow vulnerabilities? An in-depth study of the chromium project

As developers face an ever-increasing pressure to engineer secure software, researchers are building an understanding of security-sensitive bugs (i.e. vulnerabilities). Research into mining software repositories has greatly increased our understanding of software quality via empirical study of bugs. Conceptually, however, vulnerabilities differ from bugs: they represent an abuse of functionality as opposed to insufficient functionality commonly associated with traditional, non-security bugs. We performed an in-depth analysis of the Chromium project to empirically examine the relationship between bugs and vulnerabilities. We mined 374,686 bugs and 703 post-release vulnerabilities over five Chromium releases that span six years of development. We used logistic regression analysis, ranking analysis, bug type classifications, developer experience, and vulnerability severity metrics to examine the overarching question: are bugs and vulnerabilities in the same files? While we found statistically significant correlations between pre-release bugs and post-release vulnerabilities, we found the association to be weak. Number of features, source lines of code, and pre-release security bugs are, in general, more closely associated with post-release vulnerabilities than any of our non-security bug categories. In further analysis, we examined sub-types of bugs, such as stability-related bugs, and the associations did not improve. Even the files with the most severe vulnerabilities (by measure of CVSS or bounty payouts) did not show strong correlations with number of bugs. These results indicate that bugs and vulnerabilities are empirically dissimilar groups, motivating the need for security engineering research to target vulnerabilities specifically.