ICSE 2024 PaperList1

1. 勒索软件攻击造成的数据破坏的实证研究

An Empirical Study of Data Disruption by Ransomware Attacks

近年来，勒索软件对软件生态系统的威胁日益令人担忧，这就提出了对大规模、全面的勒索软件分析的需求，以帮助针对未知攻击制定更有效的对策。在本文中，我们首先收集了一个由 7,796 个活跃勒索软件样本组成的真实数据集，并分析了它们破坏受害者系统数据的行为。所有样本均在隔离的测试床中执行，收集API调用、I/O访问、网络流量等六类运行时行为的全视角，总日志量高达1.98 TiB。通过评估收集到的行为，我们在勒索软件的数据侦察、数据篡改和数据泄露阶段提出了六个关键发现。根据我们的发现，我们提出了三种相应的缓解策略来在每个阶段检测勒索软件。实验结果表明，它们可以增强最先进的反勒索软件工具的能力。我们报告的初步结果是检测率提高了 41%-69%，并且没有额外的误报，这表明我们的见解是有用的。

2. 深度学习还是经典机器学习？基于日志的异常检测的实证研究

Deep Learning or Classical Machine Learning? An Empirical Study on Log-Based Anomaly Detection

虽然深度学习 (DL) 已成为一种强大的技术，但必须仔细考虑其优势与计算成本的关系。具体来说，虽然深度学习方法在日志异常检测方面取得了很强的性能，但它们通常需要延长日志预处理和模型训练的时间，这阻碍了它们在需要快速构建和推理日志异常检测的分布式云系统中的采用。

本文研究了深度学习方法与日志异常检测中更简单的技术相比的优越性。我们在五个公共日志异常检测数据集（例如 HDFS）上评估基本算法（例如 KNN、SLFN）和深度学习方法（例如 CNN、NeuralLog）。我们的研究结果表明，简单的算法在时间效率和准确性方面都优于深度学习方法。例如，在 Thunderbird 数据集上，K 最近邻算法的训练速度比 NeuralLog 快 1,000 倍，同时 F1 分数提高了 0.0625。我们还确定了导致这种现象的三个因素，它们是：（1）冗余日志预处理策略，（2）数据集简单性，以及（3）日志异常检测中二元分类的性质。为了评估 DL 的必要性，我们提出了 LightAD，这是一种优化训练时间、推理时间和性能得分的架构。通过自动超参数调整，LightAD 可以在日志异常检测模型之间进行公平比较，使工程师能够评估复杂深度学习方法的适用性。

我们的研究结果对日志异常检测社区来说是一个警示，强调在采用深度学习方法之前需要批判性地分析数据集和研究任务。提出计算成本高昂的模型的研究人员应该将他们的工作与轻量级算法进行基准测试，以确保进行全面的评估。

3. 新颖性带来流行，但限制了参与——Python开源生态系统的宏观视角 

Novelty Begets Popularity, But Curbs Participation - A Macroscopic View of the Python Open-Source Ecosystem

卡内基梅隆大学

谁创建了最具创新性的开源软件项目？这些项目的命运又会如何呢？基于理解商业和其他领域创新的悠久研究历史，以及从科学领域科学建模创新的最新进展，在本文中，我们采用创新的类比，即从新颖的重组中产生的创新现有的知识点。因此，我们认为以新颖的方式重新组合现有软件库的软件项目是创新的，即那些构建在从导入语句中提取的非典型包组合之上的软件项目。然后，我们报告了对 Python 开源软件生态系统创新的大规模定量研究。我们的结果表明，较高水平的创新性在统计上与较高的 GitHub star 和 PyPI 包注册表下载计数相关，即新颖性会引起流行。与此同时，我们发现更具创新性的项目往往涉及较小的贡献者团队，并且从长远来看被放弃的风险更高。我们的结论是，创新和开源可持续性密切相关，但在某种程度上是对立的。

4. ModuleGuard：理解和检测 Python 生态系统中的模块冲突

ModuleGuard: Understanding and Detecting Module Conflicts in Python Ecosystem

由于其简单性、可读性和多功能性，Python 已成为最流行的软件开发编程语言之一。随着 Python 生态系统的发展，开发人员在避免模块冲突方面面临着越来越多的挑战，当不同的包具有相同的命名空间模块时就会发生这种情况。不幸的是，现有的工作既没有全面研究模块冲突，也没有提供检测冲突的工具。因此，本文系统地研究了模块冲突问题及其对Python生态系统的影响。我们提出了一种名为 InstSimulator 的新技术，它利用语义和安装模拟来实现准确高效的模块提取。基于此，我们实现了一个名为 ModuleGuard 的工具来检测 Python 生态系统的模块冲突。

在本研究中，我们首先在 GitHub 上收集了 97 个 MC 问题，对这些 MC 问题的特征和原因进行了分类，总结了三种不同的冲突模式，并分析了它们的潜在威胁。然后我们对整个 PyPI 生态系统（420 万个包）和 GitHub 热门项目（3,711 个项目）进行大规模分析，以检测每个 MC 模式并分析其潜在影响。我们发现模块冲突仍然影响 PyPI 中的众多开源软件包。我们的工作揭示了Python在处理命名冲突方面的缺点，并为开发人员检测冲突提供了工具和指南。

5. 挖掘拉取请求以检测开源软件开发中的流程异常

Mining Pull Requests to Detect Process Anomalies in Open Source Software Development

值得信赖的开源软件 (OSS) 开发流程是确保软件项目和产品长期可信的基础。为了调查 Pull Request (PR) 流程（OSS 社区协作开发的常见模型）的可信度，我们利用流程挖掘来识别和分析 PR 流程的正常和异常模式，并提出识别异常的方法从控制流和语义两个方面，然后分析和综合已识别异常的根本原因。我们分析了 GitHub 上 18 个 OSS 项目的 17531 个 PR，提取了 26 个控制流异常的根本原因和 19 个语义异常的根本原因。我们发现大多数 PR 很难同时包含语义异常和控制流异常，项目内部的自定义规则可能是导致异常 PR 的关键原因。我们进一步发现并分析正常公关流程的模式。我们发现，非分叉模型中的 PR（42%）比分叉模型中的 PR（5%）更有可能绕过审核流程，这表明潜在风险更高。此外，我们还分析了9个中毒项目，其公关做法确实较差。鉴于OSS社区中复杂多样的PR流程，所提出的方法不仅可以帮助识别和理解异常PR，还可以帮助识别和理解正常PR，从而为OSS供应链提供可疑事件（例如中毒）的早期风险指示。

6. Docker 气味对镜像大小影响的实证研究

Empirical Study of the Docker Smells Impact on the Image Size

Docker 是一种广泛采用的打包和部署应用程序的工具，它利用 Dockerfile 来构建映像。然而，创建最佳的 Dockerfile 可能具有挑战性，通常会导致“Docker 异味”或偏离最佳实践。本文研究了 14 种 Docker 气味对 Docker 镜像大小的影响。为了评估 Docker 气味的大小影响，我们从 11 313 个开源 Docker 文件中识别并修复了 16 145 个 Docker 气味。我们观察到，气味导致每个有气味的图像平均增加 48,06 MB (4,6 %)。根据气味类型，尺寸增加最多可达 10%，对于某些特定情况，气味可以代表图像尺寸的 89%。有趣的是，最有影响力的气味与常见的包管理器有关，并且相对容易修复。为了收集开发人员对 Docker 异味大小影响的看法，我们提交了 34 个修复异味的拉取请求，并向开发人员报告了它们对 Docker 镜像的影响。 26/34 (76.5%) 的拉取请求已合并，有助于节省 3.46 GB (16.4%)。即使拉取请求被拒绝，开发人员的评论也表明了他们对解决这些 Docker 异味的积极兴趣。

7. 通过静态分析生成REST API规范

Generating REST API Specifications through Static Analysis

Web 应用程序编程接口 (API) 允许通过网络访问服务。 RESTful（或 REST）API 使用 REpresentation State Transfer (REST) 协议，是一种流行的 Web API 类型。为了使用或测试 REST API，开发人员使用 OpenAPI 等标准编写的规范。然而，创建和维护这些规范既耗时又容易出错，尤其是随着软件的发展，会导致规范不完整或不一致，从而对 API 的使用和测试产生负面影响。为了解决这个问题，我们提出了 Respector（REST API 规范生成器），这是第一种采用静态和符号程序分析从源代码生成 REST API 规范的技术。我们在 15 个真实世界的 API 上评估了 Respector，在推断端点方法、端点参数、方法响应和参数属性（包括导致成功 HTTP 响应或错误的约束）方面的精度和召回率方面取得了可喜的结果。此外，这些结果可以通过额外的工程进一步改进。将 Respector 生成的规范与开发人员提供的规范进行比较表明，Respector 能够识别许多缺失的端点方法、参数、约束和响应，以及开发人员提供的规范和 API 实现之间的一些不一致之处。最后，Respector 优于多种从 API 实现中的注释或通过调用 API 推断规范的技术。