Detecting Security Patches via Behavioral Data in Code Repositories
Tel-Aviv University（特拉维夫大学）
当今绝大多数软件都是使用协作版本控制工具（如Git）协作开发的。通常的做法是，一旦发现并修复了漏洞，软件背后的开发人员就会发布一个常见漏洞和暴露或CVE记录，以提醒用户社区注意安全隐患，并敦促他们集成安全补丁。然而，有些公司可能不会披露他们的漏洞，只是更新他们的存储库。因此，用户不知道该漏洞，并可能仍然暴露。在本文中，我们提出了一个系统来自动识别安全补丁，只使用Git存储库中的开发人员行为，而不分析代码本身或伴随修复的注释（提交消息）。我们可以发现隐藏的安全补丁，准确率为88.3%，F1得分为89.8%。这是第一次提出一个语言无关的解决方案。
2023-02-04 cs.CR cs.LG cs.SE
STYLE-ANALYZER: fixing code style inconsistencies with interpretable unsupervised algorithms
source { d }；Madrid, Spain（西班牙马德里（注：原文本中“Madrid, Spain”为地点信息，非机构名称，此处可能为笔误或格式问题，根据提取规则仅提取明确机构名，若仅保留“source { d }”则符合要求））
源代码审查是手动的，耗时且昂贵。人的参与应该集中在分析程序最相关的方面，比如逻辑和可维护性，而不是修改风格、语法或格式缺陷。一些具有linting功能的工具可以自动格式化代码，并报告支持的程序设计语言的各种样式冲突。它们基于领域专家编写的规则，因此，它们的配置通常是繁琐的，并且给定的规则集覆盖所有可能的角落情况是不切实际的。存在一些基于机器学习的解决方案，但它们仍然是不可解释的黑箱。本文介绍了STYLE-ANALYZER，一个新的开源工具，使用决策树森林模型自动修复代码格式违规，该模型适用于每个代码库，完全无监督。STYLE-ANALYZER构建在我们新颖的辅助代码审查框架Lookout之上。它准确地挖掘每个分析的Git存储库的格式样式，并使用紧凑的人类可读规则表达发现的格式模式。然后STYLE-ANALYZER可以以代码评审注释的形式建议风格不一致的修复。我们评估的输出质量和实际相关性的风格分析，证明它可以重现原始风格的高精度，测量19个流行的JavaScript项目，并显示它产生有前途的结果，在修复真正的风格错误。STYLE-ANALYZER包括一个Web应用程序，用于可视化规则是如何触发的。我们在GitHub上发布STYLE-ANALYZER作为可重用和可扩展的开源软件包，以造福社区。
2019-04-01 cs.LG cs.SE stat.ML
Typify: A Lightweight Usage-driven Static Analyzer for Precise Python Type Inference
University of Windsor（温莎大学）；University of Manitoba（曼尼托巴大学）
本文提出Typify，一种轻量级静态分析器，通过符号执行和迭代固定点分析推断Python代码中的类型信息，无需依赖统计学习或大数据集，有效提升类型推断的准确性和可解释性。
2026-04-06 cs.SE
Relationship Maintenance in Software Language Repositories
这项研究的背景是测试和构建软件系统，特别是软件语言库（SLR），即，包含语言处理组件的存储库（解释器、翻译器、分析器、Transformers、漂亮的打印机等）。SLR通常用于开发和使用元编程系统、语言工作台、语言定义框架、可执行语义框架和建模框架。这项工作是调查测试和建设SLR的方式，仓库被视为一个集合的语言类型的工件被相关的应用程序的语言类型的功能或关系，服务于语言处理。语言的概念在广义上被用来包括基于文本、树、图的语言以及基于交换格式的表示和用于序列化的专有格式。这项研究的总体方法是由一个复杂的案例研究驱动的语言设计，即，一个特定的SLR具有大量的处理语言和语言处理器，以及在表示类型和实现语言方面值得注意的异质性。通过我们的研究所获得的知识是最好的理解为一个声明性的语言设计的回归测试和构建管理，我们介绍了相应的语言Ueber与可执行的语义，保持语言类型的工件之间的关系在SLR。研究报告的基础是全面的、正式的、可执行的Ueber语言的（基于逻辑编程的）定义及其在SLR YAS管理中的系统应用，该管理由数百种语言定义和处理组件组成（如解释器和转换）超过30种语言（不包括不同的表示类型），Prolog，Haskell，Java和Python被用作实现语言。这项工作的重要性源于回归测试和构建管理所隐含的巨大成本，以及SLR的复杂性，这需要帮助理解的方法。
2017-01-27 cs.PL cs.SE
Understanding and Detecting Annotation-Induced Faults of Static Analyzers
本文首次系统研究静态分析器中的注解诱发故障，分析六个主流工具的246个问题并提出检测修复指南，同时开发AnnaTester框架发现43个新故障，其中20个已修复。
2024-02-22 cs.SE
A Quantitative Study of Security Bug Fixes of GitHub Repositories
软件容易出现错误和故障。安全漏洞是那些违反软件要求而暴露或共享特权信息和访问的漏洞。考虑到安全漏洞的严重性，存在用于跨多个产品支持和跟踪这些漏洞的集中机制，其中一种机制是通用漏洞和暴露（CVE）ID描述。当一个bug获得一个CVE时，它是通过它的CVE ID引用的。因此，我们在Github上探索了数千个自由/自由开源软件（FLOSS）项目，以确定开发人员是否在他们的代码，提交和问题中引用或讨论CVE。CVE通常会引用项目的第三方软件依赖项，因此错误不会出现在实际产品本身中。我们研究这些引用中有多少是故意的CVE引用，以及有多少是项目本身的相关错误。我们研究如何修复引用CVE的错误以及修复这些错误需要多长时间。我们对250个错误报告进行手动分类的结果显示，88个（35%）、32个（13%）和130个（52%）被分类为“版本更新”、“修复代码”和“讨论”。为了了解修复这些错误需要多长时间，我们比较了两个时间段，报告期，CVE存储库中漏洞信息的披露日期和项目中错误报告的创建日期之间的时间段，以及修复期，错误报告的创建日期和错误报告的修复日期之间的时间段。我们发现，44%的bug报告被归类为“版本更新”或“修复代码”，报告期比修复期长。这表明，那些提交CVE的人应该更直接地通知受影响的项目。
2020-12-15 cs.SE
StaAgent: An Agentic Framework for Testing Static Analyzers
StaAgent 提出一个由四个专门化智能体组成的 LLM 驱动框架，通过种子生成、验证、语义等价变异和蜕变测试系统性地评估静态分析器规则，在五个主流分析器上发现 64 条有问题的规则，其中 53 个缺陷无法被现有基线检测到。
2025-07-20 cs.SE
DeepDebug: Fixing Python Bugs Using Stack Traces, Backtranslation, and Code Skeletons
Microsoft Cloud and AI（微软云与人工智能部门）
缺陷定位和程序修复的联合任务是软件开发过程中不可或缺的一部分。在这项工作中，我们提出了Deepcraft，一种使用大型预训练Transformers进行自动调试的方法。我们首先在反向提交数据上训练一个错误创建模型，以生成合成错误。我们把这些合成的虫子应用到两个方面。首先，我们直接对来自20万存储库的所有函数进行反向翻译模型的训练。接下来，我们将关注10K存储库，我们可以对这些存储库执行测试，并在这些存储库中创建通过测试的所有函数的错误版本。这为我们提供了丰富的调试信息，如堆栈跟踪和打印语句，我们使用这些信息来微调我们在原始源代码上预训练的模型。最后，我们通过将上下文窗口扩展到有缺陷的函数本身之外，并添加由该函数的父类、导入、签名、文档字符串和方法体（按优先级顺序）组成的骨架来增强所有模型。在菜Bugs基准测试中，我们将发现的修复总数增加了50%以上，同时将误报率从35%降低到5%，并将超时时间从6小时减少到1分钟。在我们自己的可执行测试基准上，我们的模型在不使用跟踪的情况下第一次尝试就修复了68%的错误，在添加跟踪后，它在第一次尝试时修复了75%的错误。我们将开源我们的框架和验证集，用于评估可执行测试。
2021-05-19 cs.LG cs.SE
Loop-Based Slicing and Input-Driven Concretization: An Empirical Study of Termination and Non-Termination Analysis
University of Nebraska–Lincoln（内布拉斯加大学林肯分校）；Waseda University（早稻田大学）；Tohoku University（东北大学）
研究针对实际C程序中终止和非终止验证难的问题，实现FocusTNT工具，用基于循环的切片和输入驱动具体化进行预处理，在多个程序上评估六种分析器，发现预处理效果因多种因素而异，为开发者提供实用指导。
2026-07-13 cs.SE
SWE-Bench++: A Framework for the Scalable Generation of Software Engineering Benchmarks from Open-Source Repositories
Research & Development, Turing（研发与图灵）
SWE-Bench++通过自动化生成多语言软件工程基准，提升仓库级代码生成的评估与改进
2025-12-19 cs.AI cs.CL cs.LG
Getafix: Learning to Fix Bugs Automatically
静态分析器通过对反复出现的bug类别发出警告来帮助早期发现bug。虽然修复这些bug在实践中仍然是一项主要的手动任务，但我们观察到，对特定bug类别的修复通常是重复的。本文讨论了通过从过去的修复中学习来自动修复常见错误的问题。我们提出Getafix，一种方法，产生类似人类的修复，同时足够快，建议修复的时间成比例的时间，需要获得静态分析结果摆在首位。Getafix是基于一种新的层次聚类算法，总结修复模式到一个层次结构，从一般到特定的模式。Getafix使用一种简单而有效的排名技术，使用代码更改的上下文来为给定的错误选择最合适的修复，而不是对潜在的大空间候选修复进行计算上昂贵的探索。我们的评估将Getafix应用于流行的Java静态分析器报告的六个错误类别的1，268个错误修复，包括空引用，不正确的API调用和特定语言结构的误用。该方法准确地预测了人类编写的修复程序在12%到91%的时间内是最重要的建议，这取决于bug类别。排名前5位的建议包含1，268个错误中的526个。此外，我们还报告了在Facebook内部部署该方法的情况，该方法有助于提高数十亿人使用的软件的可靠性。据我们所知，Getafix是第一个工业部署的自动化错误修复工具，它从过去的人类编写的修复程序中学习修复模式，以产生类似人类的修复程序。
2019-11-20 cs.SE
Who Finishes the Job? A Study of Follow-Up Fixes and Commit Authorship on AI Coding Agent Pull Requests
Applied AI Initiatives (A2I2), Deakin University（迪肯大学）
本研究分析5个AI编码智能体的6774个合并PR，发现其后续修复几率是人类的1.62倍，但69.6%修复由原智能体完成，76.4%修复PR全提交为智能体撰写，表明智能体基本能自我完善。
2026-09-25 cs.SE
ToolRosella: Translating Code Repositories into Standardized Tools for Scientific Agents
Southeast University（东南大学）；Sun Yat-sen University（中山大学）；Rensselaer Polytechnic Institute（伦斯勒理工学院）；Zhejiang Normal University（浙江师范大学）
提出ToolRosella框架，通过仓库分析、工具接口构建、执行测试和迭代修复，自动将异构科学代码仓库转化为标准化、可被智能体调用的工具，在122个仓库上达到61.5%的转换成功率，下游任务成功率为84.0%。
2026-06-09 cs.CE cs.MA cs.SE
Scalable Source Code Similarity Detection in Large Code Repositories
源代码相似性越来越多地用于应用程序开发中，以识别克隆，隔离错误和发现版权侵犯。由于原始代码中的错误必须在每个副本中修复，因此类似的代码片段可能非常有问题。其他维护更改（如扩展或修补程序）必须多次应用。此外，编码风格的多样性和现代语言的灵活性使得手动检查大型代码库变得困难且成本低。因此，检测只能通过自动技术进行。本文提出了一种基于源代码控制流图指纹识别的相似代码片段识别方法。处理源代码以生成控制流图，然后对控制流图进行散列以创建捕获语义以及语法相似性的代码的唯一指纹。然后可以有效地存储和检索指纹以执行代码片段之间的相似性搜索。我们的原型实现的实验结果支持我们的方法的有效性，并显示其有效性和效率与其他解决方案相比。
2019-07-26 cs.IR cs.PL cs.SE
KNighter: Transforming Static Analysis with LLM-Synthesized Checkers
University of Illinois Urbana-Champaign（伊利诺伊大学厄巴纳-香槟分校）；Zhejiang University（浙江大学）；Shanghai Jiao Tong University（上海交通大学）
针对静态分析工具开发难、LLM直接扫描大型系统不现实的问题，提出KNighter方法，利用LLM基于历史漏洞模式合成专用静态检查器，经多阶段验证优化，在Linux内核中发现大量长期潜伏的关键漏洞，建立了可扩展的LLM静态分析新范式。
2025-09-03 cs.AI cs.CR cs.OS
PR-SZZ: How pull requests can support the tracing of defects in software repositories
SZZ算法代表了一种标准的方法来识别bug修复提交以及诱导对应提交。它构成了许多实证研究中使用的数据集的基础。自创建以来，已提出多个扩展以提高其性能。由于历史原因，相关的工作依赖于提交消息来将错误票据映射到可能相关的代码，而没有额外的数据用于跟踪这些修复引起的提交。因此，我们提出了一个更新版本的SZZ利用拉请求，这是广泛采用的今天。我们评估我们的方法相比，现有的SZZ变种进行实验和分析使用的拉请求，内部提交，合并策略。我们的结果基于6个开源项目，超过50k提交和35k拉取请求。关于bug修复提交，平均18%的bug票据可以额外映射到修复提交，导致整体F分数为0.75，提高了40个百分点。通过选择诱导提交，我们设法减少了误报，并与现有方法相比平均提高了16个百分点的精度。
2022-06-20 cs.SE
A Manually-Curated Dataset of Fixes to Vulnerabilities of Open-Source Software
SAP Security Research（SAP安全研究部门）
本文发布人工整理的开源 Java 漏洞与修复提交数据集，含624个漏洞、205个项目和1282个提交，并提供脚本支持数据获取、扩充及安全提交分类器训练。
2019-03-19 cs.CR cs.LG cs.SE
Test Suites as a Source of Training Data for Static Analysis Alert Classifiers
Software Engineering Institute Carnegie Mellon University（卡内基梅隆大学软件工程研究所）
缺陷查找静态分析工具通常会生成大量的代码缺陷警报，包括许多误报。为了节省对这些警报进行分类的人力，大量工作尝试使用机器学习来对警报进行分类和优先级排序。然而，识别一组有用的训练数据仍然是在许多情况下开发这种分类器的基本挑战。我们建议使用静态分析测试套件（即，“基准”程序的存储库，其被专门构建以测试静态分析工具的覆盖率和精度）作为训练数据的新来源。在一个案例研究中，我们通过在Juliet C/C++测试套件上执行各种静态分析器来生成大量警报，并且通过引用Juliet测试套件元数据来自动导出这些警报的地面实况标签。最后，我们使用这些数据来训练分类器，以预测警报是否是误报。我们的分类器获得了较高的精度（90.2%）和召回率（88.2%）的大量的代码缺陷类型的保留测试集。这个初步结果表明，在测试套件数据上预先训练分类器可以帮助在数据有限的上下文中快速启动静态分析警报分类。
2021-05-07 cs.LG cs.SE
PyGress: Tool for Analyzing the Progression of Code Proficiency in Python OSS Projects
PyGress是一个基于Web的工具，利用pycefr自动评估Python OSS项目中开发者的代码熟练度，通过分析提交历史生成个人与项目级别的CEFR对齐可视化，从而帮助理解贡献者编码水平和项目熟练度演进。
2025-11-08 cs.SE
Checkification: A Practical Approach for Testing Static Analysis Truths
本文提出一种基于Ciao断言框架的静态/动态混合检查方法，通过组合静态分析器、运行时断言检查、随机测试生成和单元测试来测试抽象解释静态分析器，并在CiaoPP上成功发现并修复多个缺陷。
2025-05-07 cs.PL cs.SE
9.6 Million Links in Source Code Comments: Purpose, Evolution, and Decay
链接是万维网的基本特征，源代码库也不例外。然而，尽管有许多无可争议的好处，链接可能会受到衰减，版本控制不足和缺乏双向可追溯性的影响。在本文中，我们调查的作用，包含在源代码注释链接从这些角度来看。我们对大约960万个链接进行了大规模研究，以确定它们的流行程度，我们使用混合方法来确定链接的目标，目的，衰变和进化方面。我们发现，链接在源代码存储库中很普遍，许可证，软件主页和规范是常见的链接目标类型，并且通常包含链接以提供元数据或属性。链接很少更新，但许多链接目标会演变。在源代码注释中包含的链接中，几乎有10%是死的。然后，我们向开源软件仓库提交了一批链接修复拉取请求，导致我们的大多数修复成功合并。我们的研究结果表明，源代码注释中的链接确实是脆弱的，我们的工作为未来解决这些问题开辟了途径。
2019-02-15 cs.SE
SWE-Explore: Benchmarking How Coding Agents Explore Repositories
Shanghai Jiao Tong University（上海交通大学）；Xinjiang University（新疆大学）；University of Illinois at Urbana-Champaign（伊利诺伊大学厄巴纳-香槟分校）；Independent Researcher（独立研究者）；The Chinese University of Hong Kong（香港中文大学）
提出SWE-Explore基准，通过评估编码智能体在给定代码仓库和问题下返回相关代码区域排名列表的能力，衡量其仓库探索性能，覆盖10种编程语言和203个仓库的848个问题。
2026-06-05 cs.CL cs.SE
Tracing Vulnerable Code Lineage
本文介绍了来自MSR 2021 Hackcraft的结果。我们的团队调查包含已知安全漏洞的文件/项目，以及它们在开源软件中的存储库中的分布情况。这些安全漏洞可能通过代码重用传播，即使在不同版本的代码中修复了漏洞。我们利用World of Code基础设施从几乎完整的开源软件集合中发现文件级代码重复。本文描述了一种方法和一组工具，用于查找使用已知易受攻击文件的所有开源项目以及这些文件的任何以前版本。
2021-03-23 cs.CR cs.SE
Bug Destiny Prediction in Large Open-Source Software Repositories through Sentiment Analysis and BERT Topic Modeling
University of Wisconsin-La Crosse（威斯康星大学拉克罗斯分校）
本研究利用Bugzilla Eclipse项目数据，结合情感分析与BERTopic主题建模，通过CNN和MLP预测Bug的解决时间、修复时间及最终状态，发现情感分析对预测Bug是否被修复尤为有效。
2025-04-22 cs.AI cs.SE
Can we learn from developer mistakes? Learning to localize and repair real bugs from real bug fixes
University of Oldenburg（奥尔登堡大学）
在开源仓库中找到的真正的bug修复似乎是学习本地化和修复真正bug的完美来源。然而，由于缺乏大规模的bug修复集合，过去很难在训练较大的神经模型时有效地利用真正的bug修复。相比之下，人工bug--通过改变现有源代码产生--可以很容易地以足够的规模获得，因此在现有方法的训练中通常是首选的。尽管如此，在人工错误上训练的本地化和修复模型在面对真正的错误时通常表现不佳。这就提出了一个问题，即在真实的bug修复上训练的bug定位和修复模型在定位和修复真实的bug方面是否更有效。我们通过引入RealIT来解决这个问题，这是一种预训练和微调方法，可以有效地学习从真正的错误修复中定位和修复真正的错误。RealiT首先在传统变异算子产生的大量人工bug上进行预训练，然后在较小的一组真实bug修复上进行微调。微调不需要任何修改的学习算法，因此可以很容易地采用在各种训练场景的缺陷定位或修复（即使当真正的训练数据是稀缺的）。此外，我们发现，使用Realit对真实错误修复进行训练的经验非常强大，可以将现有模型对真实错误的本地化性能提高近一倍，同时保持甚至提高修复性能。
2022-07-01 cs.LG cs.SE
On the Footprints of Reviewer Bots Feedback on Agentic Pull Requests in OSS GitHub Repositories
Lahore University of Management Sciences（拉合尔管理科学大学）
研究探讨审查员机器人反馈质量与数量对代理拉取请求接受和解决时间的影响，发现反馈质量下降与评论数量增加相关，建议优先提供高相关性反馈。
2026-04-27 cs.SE
CommitDistill: A Lightweight Knowledge-Centric Memory Layer for Software Repositories
Microsoft Corporation（微软公司）
本文提出CommitDistill，一种轻量级的知识导向内存层，通过确定性正则表达式从本地git历史中提取类型化知识单元，并通过TF-IDF检索器进行检索，以提高软件仓库中历史信息的利用率。
2026-05-18 cs.AI cs.SE
CVEfixes: Automated Collection of Vulnerabilities and Their Fixes from Open-Source Software
Simula Research Laboratory（西莫拉研究实验室）
对源代码中安全漏洞的自动发现和修复进行数据驱动的研究需要真实易受攻击的代码及其修复的全面数据集。为了帮助这样的研究，我们提出了一种方法来自动收集和策划一个全面的漏洞数据集，从公共的国家漏洞数据库（NVD）中的常见漏洞和暴露（CVE）记录。我们在一个完全自动化的数据集收集工具中实现了我们的方法，并分享了名为CVEfixes的漏洞数据集的初始版本。CVEfixes收集工具自动从NVD获取所有可用的CVE记录，从相关的开源存储库收集易受攻击的代码和相应的修复程序，并将收集到的信息组织到关系数据库中。此外，数据集还包含了诸如程序设计语言等元数据，以及五个抽象级别的详细代码和安全度量。该集合可以很容易地重复，以保持最新的新发现或修补的漏洞。CVE修复的初始版本涵盖了截至2021年6月9日的所有已发布的CVE，涵盖了1754个开源项目的5365条CVE记录，这些项目在总共5495次漏洞修复提交中得到了解决。CVEfixes支持各种类型的数据驱动的软件安全研究，例如漏洞预测，漏洞分类，漏洞严重性预测，分析与安全性相关的代码更改以及自动漏洞修复。
2021-07-19 cs.AI cs.CR cs.LG
AdaRepair-Mem: Adaptive Experience Orchestration for Repository-Level Program Repair
Zhejiang University（浙江大学）；Tencent（腾讯）
针对仓库级程序修复中记忆不平衡、冗余和阶段错配问题，提出自适应经验检索框架，通过覆盖感知、质量选择和阶段路由提升修复性能。
2026-09-18 cs.AI cs.SE
Towards Generating Functionally Correct Code Edits from Natural Language Issue Descriptions
Microsoft Research（微软研究院）
大语言模型（LLM），如OpenAI的Codex，已经证明了它们在各种编程任务中从自然语言描述生成代码的潜力。最近出现了几个基准来评估LLM从自然语言意图生成功能正确的代码的能力，这些代码是关于一组隐藏的测试用例的。这使研究界能够确定LLM能力的重大和可复制的进步。然而，目前缺乏基准数据集来评估LLM基于意图更改的自然语言描述生成功能正确的代码编辑的能力。本文旨在通过激发NL 2Fix将代码更改的自然语言描述（即存储库中问题报告中描述的错误修复）转换为正确的代码修复的问题来解决这一差距。为此，我们引入了Defects 4J-NL 2Fix，这是一个包含283个Java程序的数据集，来自流行的Defects 4J数据集，并增加了对错误修复的高级描述，并根据经验评估了几个最先进的LLM的性能。结果表明，这些LLMS能够为64.6%的错误生成合理的修复，最好的基于LLMS的技术可以在此基准测试中实现高达21.20%的前1和35.68%的前5准确度。
2023-04-07 cs.LG cs.SE
VELVET: a noVel Ensemble Learning approach to automatically locate VulnErable sTatements
Columbia University（哥伦比亚大学）；IBM Research（IBM研究院）
自动定位源代码中的易受攻击语句对于保证软件安全和减轻开发人员的调试工作至关重要。这在当今的软件生态系统中变得更加重要，脆弱的代码可以在GitHub等软件存储库内和跨软件存储库轻松且无意地流动。在这样数百万行代码中，传统的静态和动态方法难以扩展。尽管现有的基于机器学习的方法在这样的环境中看起来很有前途，但大多数工作都是在更高的粒度上检测易受攻击的代码-在方法或文件级别。因此，开发人员仍然需要检查大量的代码来定位需要修复的易受攻击的语句。本文提出了VELVET，一种新的集成学习方法来定位脆弱语句。我们的模型结合了基于图和基于序列的神经网络，成功地捕捉程序图的局部和全局上下文，并有效地理解代码语义和脆弱模式。为了研究VELVET的有效性，我们使用了现成的合成数据集和最近发表的真实世界数据集。在静态分析设置中，没有提前检测到易受攻击的函数，VELVET在实际数据上的性能比基线静态分析器高4.5倍。对于孤立的漏洞本地化任务，我们假设一个功能的漏洞是已知的，而具体的脆弱的语句是未知的，我们比较VELVET与几个神经网络，也出席本地和全球范围内的代码。VELVET在合成数据和真实世界数据上分别实现了99.6%和43.6%的top-1准确率，比基线深度学习模型高出5.3- 29.0%。
2022-01-13 cs.LG cs.SE
LinkAnchor: An Autonomous LLM-Based Agent for Issue-to-Commit Link Recovery
Bowling Green State University（伯灵顿州立大学）；University of Nebraska-Lincoln（内布拉斯加大学林肯分校）；University of Zurich（苏黎世大学）
针对软件仓库中问题到提交链接恢复的挑战，本文提出LinkAnchor，通过懒惰访问架构动态检索相关数据，提升链接恢复的准确性和效率。
2026-06-29 cs.AI cs.SE
LightSys: Lightweight and Efficient CI System for Improving Integration Speed of Software
软件的复杂性和大小的增加延长了开发人员等待代码分析和代码合并的延迟。随着软件越来越大，越来越复杂，现在越来越多的开发人员正在开发具有大型源代码存储库的软件。软件平台立即用特征更新和错误修复来更新软件包的趋势是一个重大障碍。在软件包的积极开发过程中，持续集成系统可能有助于防止软件缺陷，即使是在频繁部署和更新的情况下。在这里，我们提出了一个便携式和模块化的代码审查自动化系统，检查传入的代码更改，如代码格式和风格，性能回归，静态分析，构建和部署测试，并在合并和更改代码之前的动态分析。所提出的机制是足够轻量级的，即使对于许多开发人员来说，也可以托管在常规的台式计算机上。由此产生的成本降低允许开发人员将所提出的机制应用于许多源代码存储库。实验结果表明，该机制大大减少了开销，并提高了可用性相比，传统的机制：执行时间（6倍快），CPU使用（40%），内存消耗（1/180），和没有内存不足的发生。
2021-01-29 cs.SE
An Annotated Dataset of Stack Overflow Post Edits
为了改进软件工程，已经挖掘软件存储库以获得代码片段和错误修复。通常，这种挖掘发生在文件或提交级别。为了能够更深入地挖掘并以更高的分辨率提取见解，我们在此提供了一个带注释的数据集，其中包含Stack Overflow上超过700万次的代码和文本编辑。我们的初步研究表明，这些编辑可能是挖掘细粒度补丁信息的宝库，例如，用于优化非功能特性。
2020-05-06 cs.NE cs.SE
An Empirical Study on Learning Bug-Fixing Patches in the Wild via Neural Machine Translation
代码库中有数百万个修复了许多bug的开源项目。可以利用软件开发历史的这种扩散来学习如何修复常见的编程错误。为了探索这种潜力，我们进行了一项实证研究，以评估使用神经机器翻译技术学习错误修复补丁的可行性。首先，我们从GitHub上托管的项目的更改历史中挖掘数百万个错误修复，以提取此类错误修复的有意义的示例。接着，我们抽象出错误代码和相应的固定代码，并使用它们来训练一个编码器-解码器模型，该模型能够将错误代码翻译成其固定版本。在我们的实证调查中，我们发现这样的模型能够在野外修复数千种独特的错误方法。总的来说，这个模型能够在9-50%的情况下预测开发人员生成的固定补丁，这取决于我们允许它生成的候选补丁的数量。此外，该模型能够模拟各种不同的抽象树操作，并在一瞬间生成候选补丁。
2019-05-21 cs.SE
Did You Forkget It? Detecting One-Day Vulnerabilities in Open-source ForksWith Global History Analysis
University of Rennes（雷恩大学）；Inria（法国国家信息与自动化研究所）
本文提出一种全球历史分析方法，用于检测开源fork中的单日漏洞，通过传播漏洞信息和自动化影响分析，发现135个高严重性漏洞。
2026-10-08 cs.CR cs.SE
SWT-Bench: Testing and Validating Real-World Bug-Fixes with Code Agents
ETH Zurich（苏黎世联邦理工学院）
本文提出SWT-Bench基准，利用基于LLM的代码智能体将真实GitHub问题转化为测试用例，并证明生成的测试能有效过滤代码修复，使SWE-Agent精确率翻倍。
2025-02-07 cs.AI cs.LG cs.SE
SequenceR: Sequence-to-Sequence Learning for End-to-End Program Repair
KTH Royal Institute of Technology（瑞典皇家理工学院）；Colorado State University（科罗拉多州立大学）；The College of William and Mary（威廉与玛丽学院）
提出了一种基于序列到序列学习的端到端程序修复方法。我们设计，实现和评估一个系统，称为SequenceR，用于修复基于序列到序列学习源代码的错误。这种方法使用复制机制来克服大型代码中出现的无限词汇表问题。我们的系统是数据驱动的;我们用35,578个样本对它进行训练，这些样本是从提交到开源存储库中精心挑选的。我们评估了4，711个独立的真实错误修复，以及用于程序修复研究的Defects 4J基准。SequenceR能够完美地预测950/4711测试样本的固定线，并为Defects 4J中的14个bug找到正确的补丁。它捕获了广泛的修复操作符，而没有任何特定于域的自顶向下设计。
2019-09-09 cs.LG cs.SE stat.ML
ABSENTIA: Detecting Broken Access Control Vulnerabilities in Web Applications
Carnegie Mellon University（卡内基梅隆大学）；Instituto Superior Técnico（技术高等研究所）；Faculdade de Engenharia do Porto（波尔图工程学院）
针对Web应用失效的访问控制漏洞，提出安全脚手架ABSENTIA，引导LLM智能体通过路由映射和不变式反驳实现系统性检测，并发布BAC-Bench基准，召回19/30漏洞，优于现有工具。
2026-10-02 cs.CR cs.SE
Beyond Bug Fixes: An Empirical Investigation of Post-Merge Code Quality Issues in Agent-Generated Pull Requests
University of Saskatchewan（萨斯喀彻温大学）
本研究通过分析代理生成的bug修复PR合并后代码质量问题，发现代码异味主导，且合并成功不等于代码质量高，需系统化质量检查。
2026-01-27 cs.SE
Demystifying Regular Expression Bugs: A comprehensive study on regular expression bug causes, fixes, and testing
正则表达式会导致与字符串相关的错误和DOS攻击的开放安全漏洞。然而，除了ReDoS（正则表达式拒绝服务）之外，人们对正则表达式问题影响软件开发的程度以及如何在实践中解决这些问题知之甚少。我们对来自Apache，Mozilla，Facebook和Google GitHub存储库的356个合并regex相关的pull request bug进行了实证研究。我们识别正则表达式问题的性质、修复以及测试代码中的相关更改并对其进行分类。本文最重要的发现如下：1）不正确的正则表达式行为是正则表达式错误的主要根源（165/356，46.3%）。其余的根本原因是不正确的API使用（9.3%）和其他需要在修复中更改正则表达式的代码问题（29.5%），2）修复正则表达式错误并不简单，因为与一般的拉取请求相比，修复正则表达式错误需要更多的时间和更多的代码行，3）大多数（51%）与正则表达式相关的拉取请求不包含测试代码更改。某些正则表达式错误类型（例如，编译错误，性能问题，正则表达式表示）不太可能包括测试代码更改，4）在正则表达式相关的拉取请求中，测试代码更改的主要类型是测试用例添加（75%）。本研究的结果有助于更广泛地理解开发人员在使用、修复和测试正则表达式时所面临的实际问题。
2021-04-19 cs.SE
Favia: Forensic Agent for Vulnerability-fix Identification and Analysis
Norwegian University of Science and Technology（挪威科技大学）；CSIRO’s Data61（澳大利亚联邦科学与工业研究组织数据61研究所）
Favia通过结合可扩展的候选排名与深入语义推理，有效识别漏洞修复，优于传统和LLM基方法。
2026-02-13 cs.AI cs.CR cs.SE
The Sound of Silence: Mining Security Vulnerabilities from Secret Integration Channels in Open-Source Projects
公共开发过程是开源项目的一个关键特征。然而，漏洞的修复通常是在一小群受信任的维护者之间私下讨论的，并且在没有事先公开参与的情况下进行集成。这是为了防止早期披露，并应对禁运和保密协议（NDA）规则。虽然常规的开发活动会留下公开可用的痕迹，但绕过标准流程的漏洞修复程序不会。我们提出了一个基于数据挖掘的方法来检测代码片段，从这种侵犯标准的过程。通过系统地将公共开发工件映射到源代码存储库，我们可以排除常规的过程活动，并推断出源于非公共集成渠道的违规行为。对于Linux内核，许多系统中最关键的组件，我们将我们的方法应用于Linux 5.4发布前的七个月。我们发现29个提交解决了12个漏洞。对于这些漏洞，我们的方法提供了2到179天的时间优势，可以在公开披露之前设计漏洞，并推出修复程序。在开放开发过程中建立的负责任的披露方法应该限制安全漏洞的过早可见性。然而，我们的方法表明，相反，它们打开了更多的可能性，以揭示这种改变，挫败了这个前提。最后，我们讨论的影响和部分对策。
2020-09-03 cs.SE
Fixseeker: An Empirical Driven Graph-based Approach for Detecting Silent Vulnerability Fixes in Open Source Software
针对静默漏洞修复检测问题，提出基于图的Fixseeker方法，利用hunk间相关性建模修复模式，在多种语言上优于现有方法，F1达0.8404。
2025-03-26 cs.SE
GDPR-Bench-Android: A Benchmark for Evaluating Automated GDPR Compliance Detection in Android
本文提出首个用于评估Android应用中自动化GDPR合规性检测的综合基准GDPR-Bench-Android，包含1951个违规实例，并基于多粒度违规定位和多标签分类任务评估了11种方法，揭示了不同自动化范式的任务依赖性优势。
2025-11-01 cs.SE
A Unified Issue Resolution Benchmark for Requirement Clarification, Planning, and Code Generation for Coding Agents
Singapore Management University（新加坡管理大学）；Monash University Malaysia（马来西亚莫纳什大学）；Daegu Gyeongbuk Institute of Science and Technology (DGIST)（大邱庆北科学技术院）；The Chinese University of Hong Kong（香港中文大学）；North Carolina State University（北卡罗来纳州立大学）；City University of Hong Kong（香港城市大学）；The Hong Kong University of Science and Technology（香港科技大学）；The University of Hong Kong（香港大学）
该研究推出SWE-RPG编码智能体基准，评估发现主流编码智能体在该基准上平均解决率仅31.5%，隐性需求恢复是主要瓶颈，为改进编码智能体提供了方向。
2026-08-11 cs.AI cs.SE
REEF: A Framework for Collecting Real-World Vulnerabilities and Fixes
针对现有自动程序修复基准规模小、语言单一且漏洞解释质量低的问题，提出自动化收集框架REEF，通过多语言爬虫与神经语言模型生成高质量漏洞-修复对及解释，构建了涵盖7种语言、4466个CVE的大规模数据集。
2023-09-15 cs.SE
Bug-Fix Variants: Visualizing Unique Source Code Changes across GitHub Forks
分叉是开发人员在现有项目上进行构建时的常见做法。这些分叉创建了变体，这些变体具有共同的代码基础，但随后在不同的方向上发展代码，这是特定于分叉的项目需求的。拥有多个fork的一个有趣的副作用是能够在代码的不同演化方向之间进行选择，这是基于开发人员修复代码库中的bug。然而，关键问题在于，这种分散的信息形式很难分析。在这项研究中，我们提出了一个可视化来分析尚未合并回原始项目的fork存储库中的活动更改。我们的可视化显示了多个fork中的代码提交活动，突出显示了fork历史中的bug修复提交。虽然每个存储库的提交活动的可视化类似于GitHub的代码频率视图，但我们的视图仅显示fork存储库独有的提交。为了说明我们的可视化的有效性，我们将我们的视图应用于两个用例：从不再维护的存储库中识别fork，以及在fork中识别bug修复。在第一种情况下，我们识别了一个名为Obfuscator-LLVM的挂起项目的分支。我们的视图显示了原始存储库及其最活跃的分支，这些分支在顶部继续开发。在第二种情况下，我们在Clipy项目的一个分支中发现了一个bug修复。我们的视图显示，最活跃的分支有自己的bug修复;我们可以很容易地为视图中突出显示的bug识别补丁。作为一个新的想法论文，我们提出了我们的三个研究问题的大纲，以激发现实世界的用例和目标，我们的可视化有可能发现。我们的可视化原型可在\textcolor{…
2022-08-05 cs.SE
Documentation-Guided Agentic Codebase Migration from C to Rust
FPT Software AI Center（FPT软件人工智能中心）；University of Melbourne（墨尔本大学）；Center of AI Research, VinUniversity（Vin大学人工智能研究中心）
提出 RustPrint 框架，通过文档引导的智能体协调，实现仓库级别的 C 到 Rust 迁移，在编译性、特征保留和测试通过率上显著优于现有方法。
2026-05-22 cs.SE
Skeleton-Guided-Translation: A Benchmarking Framework for Code Repository Translation with Fine-Grained Quality Evaluation
Microsoft（微软）；Peking University（北京大学）；Zhejiang University（浙江大学）；Tongji University（同济大学）
针对现有代码翻译基准忽略仓库级复杂性的问题，提出基于骨架引导的Java到C#仓库翻译框架及细粒度评估基准TRANSREPO-BENCH，通过两步翻译和测试用例级指标提升评估准确性与自动化。
2025-01-27 cs.AI cs.SE
Detecting Outdated Code Element References in Software Repository Documentation
过时的文档是软件开发中的一个普遍问题，它妨碍了软件的有效使用，并误导了用户和开发人员。我们认为，文档如此容易变得不同步的一个可能原因是开发人员不知道他们的源代码修改何时会使文档过时。确保文档始终与源代码同步需要相当大的努力，特别是对于大型代码库。为了解决这种情况，我们提出了一种方法，可以自动检测代码元素引用后，所有的源代码实例已被删除的文档中生存。在这项工作中，我们分析了3,000多个GitHub项目，发现大多数项目在其历史的某个时刻至少包含一个过时的代码元素引用。我们将GitHub问题提交给现实世界的项目，其中包含我们的方法检测到的过时引用，其中一些已经导致文档修复。作为保持软件存储库中文档最新的一项举措，我们已经为开发人员提供了我们的实现，以扫描他们的GitHub项目以查找过时的代码元素引用。
2022-12-02 cs.SE
Revizor: A Data-Driven Approach to Automate Frequent Code Changes Based on Graph Matching
开发人员在其项目中所做的许多代码更改都是重复的，并构成了经常性的更改模式。从开放源代码库的版本历史中收集这些模式并建议其中最有用的模式作为快速修复是很有意义的。在本文中，我们介绍了Revizor-一个旨在为流行的Python IDE PyCharm构建自定义插件的工具。基于Revizer的插件可以采用更改模式，并在开发人员的代码编辑器中突出显示其应用程序的潜在位置。如果开发人员接受快速修复，插件会自动执行编辑。我们的方法使用基于图形的代码更改表示，这使得它能够支持复杂的分布式代码模式。经验丰富的开发人员也积极评价了这种基于Revizer的插件的可用性和性能。该工具的源代码和测试插件原型可在GitHub上获得：www.example.com。带有简短工具描述的演示视频可以在YouTube上找到：www.example.com。
2021-08-25 cs.SE
Debt Behind the AI Boom: A Large-Scale Empirical Study of AI-Generated Code in the Wild
Adelaide University（阿德莱德大学）；University of Victoria（维多利亚大学）；Huazhong University of Science and Technology（华中科技大学）；Singapore Management University（新加坡管理大学）
本文研究了AI生成代码在真实软件项目中的技术债务影响，发现代码异味是最常见的问题，且部分问题长期存在，凸显了AI辅助开发中质量保障的必要性。
2026-10-13 cs.SE
Learning to Catch Security Patches
及时修补对于保护用户和维护人员免受恶意攻击的可怕后果至关重要。在实践中，修补的优先级取决于在代码存储库中提交的代码更改的性质。当这样的改变被标记为与安全相关时，即，在修复漏洞时，维护者迅速传播改变，并且通知用户需要更新到库或应用程序的新版本。不幸的是，通常情况下，一些与安全相关的更改会被忽视，因为它们代表了对漏洞的无声修复。在本文中，我们提出了一种基于Co-Training的方法来捕获安全补丁，作为代码库自动监控服务的一部分。利用不同类别的功能，我们的经验表明，这种自动化是可行的，可以在识别安全补丁时产生超过90%的准确率，前所未有的召回率超过80%。除了使用地面真实数据进行基准测试（这表明了对最先进技术的改进）之外，我们还证实了我们的方法可以帮助捕获未报告的安全补丁。
2020-01-24 cs.SE
