A Preliminary Study on Self-Contained Libraries in the NPM Ecosystem
本文分析 2763 个 NPM 库，揭示自包含库的比例、依赖移除趋势及主要动因，为减少依赖和改进软件开发实践提供依据。
2024-06-17 cs.SE
Understanding npm Developers' Practices, Challenges, and Recommendations for Secure Package Development
University of Hawai‘i at Mānoa（夏威夷大学马诺阿分校）
本研究通过调查75名npm开发者，探讨其在安全包开发中的实践、挑战及改进建议，揭示了安全工具不足、依赖项弃用等问题。
2026-01-28 cs.SE
Demystifying the Vulnerability Propagation and Its Evolution via Dependency Trees in the NPM Ecosystem
具有丰富功能的第三方库促进了Node.js软件的快速开发，但也带来了新的安全威胁，即可能通过依赖关系引入漏洞。特别是，这些威胁可能会被传递依赖性过度放大。现有的研究要么考虑直接依赖，要么基于可达性分析推理传递依赖，忽略了NPM特定的依赖解决规则，导致错误解决的依赖。因此，进一步的细粒度分析，如脆弱性传播及其在依赖关系中的演变，无法大规模精确地进行，也无法为依赖关系中的脆弱性得出全生态系统的解决方案。为了填补这一空白，我们提出了一种基于知识图谱的依赖关系解析，它将依赖关系的依赖关系解析为树（即，依赖关系树），并调查了大规模依赖关系树中漏洞的安全威胁。我们首先构建了一个完整的依赖-脆弱性知识图谱（DVGraph），它捕获了整个NPM生态系统（超过1000万个库版本和6000万个良好解析的依赖关系）。在此基础上，我们提出DTResolver静态和精确地解决依赖树，以及传递的漏洞传播路径，通过考虑官方的依赖解决规则。在此基础上，我们对依赖树中的脆弱性传播及其演变进行了全生态系统的实证研究。我们的研究揭示了许多有用的发现，我们进一步讨论了不同利益相关者减轻NPM脆弱性影响的经验教训和解决方案。例如，我们为NPM包实现了一个基于依赖树的漏洞修复方法（DTReme），并且获得了比官方工具（npm审计修复）更好的性能。
2022-02-09 cs.SE
Detecting and Characterizing Low and No Functionality Packages in the NPM Ecosystem
本研究针对npm生态系统中低功能/无功能包的安全风险问题，完善相关定义并提出纯数据包概念，开发基于规则的静态分析检测工具，在2025年npm生态中验证其94%的准确率，为降低依赖管理中的技术债务与安全风险提供支持。
2025-10-06 cs.SE
An Exploration of npm Package Co-Usage Examples from Stack Overflow: A Case Study
使用第三方软件包已经成为当代软件开发中的一种常见做法。开发人员经常面临不同的挑战，包括选择正确的库，安装错误，差异，设置环境，以及在软件开发过程中构建失败。维护第三方软件包的风险是众所周知的，但不清楚来自Stack Overflow（SO）的信息如何有用。本文对SO中的npm共用现象进行了实证研究。从超过30，000个SO帖子中，我们提取了2，100个与npm相关的SO帖子，并将它们与217，934个npm库包进行了匹配。我们发现，流行的和高度使用的库并没有经常在SO中讨论。然而，我们可以看到，被接受的答案可能是有用的，因为我们相信使用示例和可执行命令可以被重用为工具支持。
2022-02-28 cs.SE
Understanding and Detecting Peer Dependency Resolving Loop in npm Ecosystem
本文首次系统研究 npm 生态中的 PeerSpin 无限循环问题，提出基于 Node-Replacement-Conflict 的检测技术并开发 PeerChecker 工具，在 NPM 全生态中发现 5,662 个包受影响，并开源全部实现与数据。
2025-05-20 cs.SE
Where to Go Now? Finding Alternatives for Declining Packages in the npm Ecosystem
本文提出一种基于 npm 生态中真实依赖迁移模式的方法，自动识别衰退软件包并推荐替代方案，实验显示替代建议准确率达 96%，且获 67% 专业 JavaScript 开发者认可。
2023-08-16 cs.SE
Towards Better Comprehension of Breaking Changes in the NPM Ecosystem
针对NPM生态系统破坏性变更带来的高昂维护成本，本文构建了381个项目的数据集，系统分类了语法与行为破坏性变更及其成因，并为自动化检测与重命名技术提供了改进建议。
2024-10-14 cs.SE
An Empirical Comparison of Developer Retention in the RubyGems and npm Software Ecosystems
软件生态系统可以被看作是由技术组件（软件包）和维护技术组件的社会组件（开发人员社区）组成的社会技术网络。随着时间的推移，生态系统通过社会技术变化而演变，这些变化可能会极大地影响生态系统的可持续性。像开发人员流动这样的社会变化可能会导致技术退化。这激发了识别导致开发人员放弃的那些因素的需要，以便自动化识别具有高放弃风险的开发人员的过程。本文比较了两个软件包生态系统RubyGems和npm的这些因素。我们分析了他们在GitHub上托管的软件包的演变，考虑了提交方面的开发活动，以及与其他开发人员在提交、问题或拉取请求相关的评论方面的社交互动。我们分析了RubyGems和npm分别超过3万和6万开发人员的社会技术活动。我们使用生存分析来确定哪些因素与较低的生存概率相一致。我们的研究结果表明，开发人员放弃生态系统的可能性更高：不与其他开发人员进行讨论;没有很强的社交和技术活动强度;沟通或提交频率较低;并且长时间不参与技术和社交活动。这些观察结果可用于自动识别放弃生态系统的可能性很高的开发人员，从而降低与知识损失相关的风险。
2017-08-08 cs.SE
A Large Scale Analysis of Semantic Versioning in NPM
本文构建大规模数据集和时间旅行依赖解析器分析NPM中语义版本控制的使用，发现正确使用时90.09%的关键更新能快速流向下游，但不完美使用会导致更新延迟。
2023-04-01 cs.SE
Opportunities and Security Risks of Technical Leverage: A Replication Study on the NPM Ecosystem
该研究复现现有技术杠杆相关工作，扩展分析NPM生态的一级传递依赖，发现其技术杠杆的机遇与风险均被放大，高杠杆可加快发布但漏洞风险更高。
2024-12-09 cs.SE
On the Diversity of Software Package Popularity Metrics: An Empirical Study of npm
软件系统通常利用开源软件库来重用功能。这样的库可以通过软件包管理器（如JavaScript的npm）轻松获得。由于在这样的包分发中可用的包的巨大数量，开发者通常基于其流行度来决定依赖于或贡献于软件包。此外，研究人员通常依赖流行度指标进行数据采样并为他们的研究选择合适的候选人。然而，受欢迎程度的含义是相对的，可以以多种方式定义和测量，即使在考虑相同的研究时，也可能产生不同的结果。在本文中，我们展示了在软件工程研究中流行的意义是如何不同的证据。此外，我们实证分析了不同的软件流行性措施之间的关系。作为一个案例研究，对于175 k npm包的大型数据集，我们从三个开源跟踪系统（libraries.io，npmjs.com和GitHub）中计算并提取了9个不同的流行度指标。我们发现，实际上流行度可以用不同的无关指标来衡量，每个指标都可以在特定的上下文中定义。这表明需要一个通用的框架，将使用一个投资组合的流行度度量从不同的概念。
2019-01-14 cs.SE
What makes a good Node.js package? Investigating Users, Contributors, and Runnability
Node.js包管理器（即，npm）归档存储库是JavaScript社区的重要组成部分，有助于支持世界上最大的开发者生态系统之一。然而，作为开发人员，选择一个合适的npm包来使用或贡献可能很困难。为了了解用户和贡献者在搜索一个好的npm包时认为哪些功能是重要的，我们进行了一项调查，要求Node.js开发人员评估从现有工作中派生的30个功能的重要性，包括GitHub活动，软件可用性以及存储库和文档的属性。我们确定，用户和贡献者的观点，他们使用哪些功能来评估软件包的质量有着相似的看法。然后，我们从104，364个npm包中提取了30个功能，并分析了它们之间的相关性，包括三个衡量包"可运行性”的软件功能;安装，构建和执行单元测试的能力。我们确定哪些功能与运行相关的功能呈负相关，并发现预测软件包的运行能力是可行的。我们的研究为未来理解用户和贡献者如何选择合适的npm包奠定了基础。
2021-06-23 cs.SE
On the evolution of technical lag in the npm package dependency network
通过包管理器开发和分发的软件包广泛依赖于其他包。这些依赖关系会定期更新，例如添加新功能，解决错误或修复安全问题。为了充分利用这种类型的重用的好处，开发人员应该通过依赖最新的版本来保持他们的依赖关系。然而，在实践中，这并不总是可能的，并且软件包会落后于其依赖项的最新版本。这种现象在文献中被描述为技术滞后。在本文中，我们对npm依赖网络中的技术滞后进行了实证研究，研究了12万个软件包的140多万个版本的演变，以及这些版本之间的800万个依赖关系。我们将探讨技术滞后如何随着时间的推移而增加，同时考虑到发布类型和包依赖约束的使用。我们还讨论了如何通过依赖语义版本化策略来减少技术滞后。
2018-06-13 cs.SE
Containing Malicious Package Updates in npm with a Lightweight Permission System
在快速发展的软件生态系统中，大量的第三方软件包（如Node.js/npm）使攻击者能够通过将恶意更新推送到其软件包依赖关系中来危害应用程序。通过研究npm存储库，我们发现Node.js应用程序中使用的npm存储库中的许多包只执行简单的计算，不需要访问文件系统或网络API。这提供了对每个包强制执行最小特权设计的机会，从而保护应用程序和包依赖项免受恶意更新的影响。我们提出了一个轻量级的权限系统，通过在运行时强制执行包权限来保护Node.js应用程序。我们讨论了解决方案的设计空间，并表明我们的系统使得大量的软件包更难被利用，几乎是免费的。
2021-03-08 cs.CR cs.SE
Ecosystem-wide influences on pull request decisions: insights from NPM
University of Groningen（格罗宁根大学）；Linköping University（林雪平大学）
本研究通过分析NPM生态系统中180万拉取请求，发现生态系统范围因素（如跨项目经验）显著影响拉取请求接受决策，结合这些因素预测结果F1达0.92，并识别出开发者涉及生态系统的具体原因。
2025-03-10 cs.SE
Effect of Technical and Social Factors on Pull Request Quality for the NPM Ecosystem
基于拉取请求（PR）的开发是社交编码平台的规范，需要评估来自开源生态系统的开发人员（通常是不熟悉的）的贡献，相反，向不熟悉的维护人员提交项目的贡献。以前的研究表明，接受或拒绝PR的决定可能会受到一组不同的技术和社会因素的影响，但往往集中在相对较少的项目，不考虑生态系统范围内的措施，或可能的非单调关系的预测和PR接受概率。我们的目标是揭示这一重要的决策过程，通过测试的措施显着影响PR接受的概率在一个大的生态系统的一个显着的部分，排名他们在预测PR接受的相对重要性，并确定形状的功能，每个预测映射到PR接受。我们提出了七个假设，技术和社会因素可能会影响公关接受，并创建了17个措施，根据他们。我们的数据集由来自3349个流行NPM包的470，925个PR和79，128个创建这些PR的GitHub用户组成。我们测试了哪些措施会影响公关接受度，并根据其在预测模型中的重要性对重要措施进行了排名。我们的预测模型的AUC为0.94，发现17项措施中有15项是重要的，包括5项新的生态系统范围的措施。描述提交到存储库的PR数量的度量以及其中被接受的比例，以及PR审查阶段的信号是最重要的。我们还发现，只有四个预测PR接受概率的线性影响，而其他人表现出更复杂的反应。
2020-07-20 cs.SE
Systematic literature review of the trust reinforcement mechanisms exist in package ecosystems
本文通过系统性文献综述梳理npm安全与信任工具现状，分析开发者选择第三方包的动机、告警响应及安全认知，并识别SECO集成复杂性与研究空白。
2024-06-26 cs.SE
Towards Sustainable and Secure Reuse in Dependency Supply Chains: Initial Analysis of NPM packages at the End of the Chain
本文初步分析 NPM 中无外部依赖的链路末端包，发现其占关键依赖链逾半数且特征多样，为平衡复用收益与安全可持续实践提供启示。
2025-10-06 cs.SE
How Deep Does Your Dependency Tree Go? An Empirical Study of Dependency Amplification Across 10 Package Ecosystems
Auburn University（奥本大学）
本研究通过分析10个软件生态系统的依赖放大现象，发现Maven的平均放大率显著高于其他生态系统，揭示了依赖管理对供应链安全的影响。
2025-12-12 cs.SE
Killing Two Birds with One Stone: Malicious Package Detection in NPM and PyPI using a Single Model of Malicious Behavior Sequence
Fudan University（复旦大学）；Tongji University（同济大学）
本文提出Cerebro模型，通过统一多语言恶意包知识和序列建模技术，有效检测NPM和PyPI中的恶意包，实现高效准确的恶意包识别。
2025-05-02 cs.CR cs.SE
Towards Using Package Centrality Trend to Identify Packages in Decline
由于其日益增加的复杂性，今天的软件系统经常通过利用库和包形式的可重用代码来构建。软件生态系统（例如，npm）是这种代码重用的主要推动者，为开发人员提供了一个共享自己代码和使用他人代码的平台。这些生态系统发展迅速：开发人员每天都添加新的软件包来解决新的问题或提供替代的解决方案，导致过时的软件包对社区的重要性下降。开发人员应该避免依赖于下降的包，因为随着时间的推移，这些包的重用率越来越低，维护频率也越来越低。然而，当前流行度度量（例如，Stars和Downloads）不适合向开发人员提供这些信息，因为它们的语义不能恰当地捕捉社区兴趣的变化。在本文中，我们提出了一种可扩展的方法，使用包在生态系统中的中心地位来识别下降的包。我们使用npm生态系统评估了我们的方法，并表明随着时间的推移，中心性的趋势可以正确区分ROC-AUC为0.9的软件包。该方法可以捕获87%的软件包下降，平均18个月前的趋势显示在目前使用的软件包流行度指标。我们在一个工具中实现了这种方法，该工具可用于增强npm指标，并帮助开发人员在重用npm中的包时避免包下降。
2021-10-19 cs.SE
Which Pull Requests Get Accepted and Why? A study of popular NPM Packages
背景资料：Pull Request（PR）集成商经常面临多个并发PR的挑战，因此衡量哪些PR将被接受的能力可以帮助他们平衡工作负载。公关创作者将受益于了解他们的公关的某些特征是否会增加接受的机会。目的：我们使用随机森林模型对PR在创建后一个月内被接受的概率进行了建模，该模型利用了50个预测因子，这些预测因子代表了作者、PR和PR提交到的项目的属性。方法：我们分析了来自4218个流行NPM包的483，988个PR，并选择了一个14个预测因子的子集，足以使调整后的随机森林模型达到高精度。结果：AUC-ROC值为0.95，预测PR接受。排除提交后发生变化的PR属性的模型给出的AUC-ROC值为0.89。我们通过使用NPM包\textit{bootstrap}的历史数据对其进行训练，并预测未来提交的PR是否会被接受，来测试我们的模型在实际场景中的实用性。这给了我们所有14个预测因子的AUC-ROC值为0.94，排除PR属性在其创建后发生变化，则为0.77。结论：PR集成商可以使用我们的模型对开放PR的质量进行高度准确的评估，PR创建者可以通过了解从集成商的角度来看他们的PR的哪些特性可能是不期望的来从模型中受益。该模型可以实现为一个工具，我们计划这样做，作为未来的工作。
2020-03-02 cs.SE
InEx-Bug: A Human Annotated Dataset of Intrinsic and Extrinsic Bugs in the NPM Ecosystem
University of British Columbia（不列颠哥伦比亚大学）
InEx-Bug数据集通过人工标注区分NPM生态系统中内在与外在bug，提供丰富的元数据用于研究缺陷特性及解决模式。
2026-02-13 cs.PL cs.SE
Extracting Insights from the Topology of the JavaScript Package Ecosystem
软件生态系统对计算和社会产生了巨大的影响，吸引了企业、研究人员和政策制定者的关注。像JavaScript节点包管理器（npm）这样的大规模生态系统就是软件项目如何容易使用包的证据。由于软件生态系统的高维性和复杂性，其分析方法受到了限制。在本文中，我们利用拓扑方法可视化软件生态系统的高维数据集。拓扑数据分析（TDA）是一种新兴的分析高维数据集的技术，它使我们能够研究数据的形状。我们生成了npm软件生态系统拓扑，通过研究其位置来揭示现有库的见解和提取模式。我们的真实世界的例子揭示了许多有趣的见解和模式，描述了软件生态系统的形状。
2017-10-02 cs.SE
On the Feasibility of Cross-Language Detection of Malicious Packages in npm and PyPI
本研究提出一种基于语言无关特征的跨语言恶意包检测方法，通过训练模型捕捉 npm 和 PyPI 中恶意包的共性，成功检测出58个未知恶意包。
2023-10-14 cs.CR cs.SE
Flexible and Optimal Dependency Management via Max-SMT
针对NPM依赖求解器贪心策略导致的版本滞后、依赖臃肿、漏洞修复不佳等问题，提出基于Max-SMT的可定制依赖求解框架PacSolve，构建替代工具MaxNPM，在漏洞修复、版本新旧、依赖数量上均优于NPM。
2023-08-24 cs.SE
What About Our Bug? A Study on the Responsiveness of NPM Package Maintainers
University of British Columbia（不列颠哥伦比亚大学）；University of Osaka（大阪大学）
本文通过分析 500 个最受依赖 npm 包中 30,340 份 bug 报告，研究维护者响应性，发现中位响应率为 70%，并归纳了未解决 bug 的原因分类法，为改进开源生态提供依据。
2025-11-07 cs.SE
What are Weak Links in the npm Supply Chain?
现代软件开发经常使用第三方软件包，这引发了对供应链安全攻击的担忧。许多攻击者针对流行的包管理器，如npm，以及他们的用户进行供应链攻击。2021年，利用开源软件供应链进行的安全攻击同比增长650%。需要主动的方法来预测高风险供应链攻击的软件包漏洞。这项工作的目标是帮助软件开发人员和安全专家通过实证研究npm包元数据来测量npm供应链薄弱环节信号，以防止未来的供应链攻击。在本文中，我们分析了163万个JavaScript npm包的元数据。我们提出了软件供应链中安全漏洞的六个信号，例如安装脚本的存在，与过期的电子邮件域相关的维护者帐户，以及不活动的软件包与不活动的维护者。我们的一个案例研究从安装脚本信号中识别出11个恶意软件包。我们还发现了2，818个与过期域名相关的维护者电子邮件地址，允许攻击者通过接管npm帐户来劫持8，494个软件包。我们通过470名npm软件包开发人员的调查获得了关于我们弱链接信号的反馈。大多数开发人员支持我们提出的六个弱链接信号中的三个。开发人员还表示，他们希望在使用第三方软件包之前获得有关弱链接信号的通知。此外，我们还讨论了软件包开发人员建议的八个新信号。
2022-02-14 cs.CR cs.CY cs.SE
A Survey on Common Threats in npm and PyPi Registries
软件工程师经常使用JavaScript和Python来完成前端和后端自动化任务。除了JavaScript和Python之外，还有几个框架可以进一步促进自动化任务。其中一些框架是节点管理器包（npm）和Python包索引（PyPi），它们是开源（OS）包库。npm和PyPi用于托管包的公共注册表允许任何具有验证电子邮件的用户发布代码。在向注册表发布时缺乏全面的扫描工具会产生安全问题。用户可以在注册表上报告恶意代码;然而，攻击者仍然可以造成损害，直到他们从平台上删除他们的工具。此外，多个包相互依赖，使得它们更容易受到依赖树中坏包的影响。大量的代码重用产生了开发人员必须考虑的安全构件，比如包的范围。这个项目将说明与操作系统注册表和包依赖结构相关的常见风险的高级概述。在操作系统软件包注册表中，有几种攻击类型，例如拼写错误和组合抢注。过时的软件包会带来安全风险，我们将研究npm环境中存在的技术滞后程度。在本文中，我们的主要贡献包括在OS注册表中的常见威胁的调查。之后，我们将提出对策，以减轻所提出的风险。这些补救措施将主要集中在机器学习（ML）的应用上，以检测可疑活动。据我们所知，以ML为重点的对策是针对所列安全问题首次提出的可能解决方案。此外，该项目是第一个对npm和PyPi威胁的调查，尽管有几项研究关注的是威胁的一个子集。
2021-08-21 cs.CR cs.SE
Understanding the Role of External Pull Requests in the NPM Ecosystem
在软件应用程序中使用第三方库的风险在于，非常需要的维护工作仅由库维护人员执行。这些库可能依赖于一个核心的维护团队（他们可能是一个没有报酬和过度工作的维护者）来服务于庞大的客户端用户群。另一方面，开源的好处是接收贡献（以外部PR的形式），以帮助修复bug和添加新功能。在本文中，我们调查的作用，外部PR（贡献的核心团队以外的维护者）有助于一个库。通过初步分析，我们发现外部PR是普遍存在的，并且与维护者PR一样可能被接受。我们发现，提交的外部PR中有26.75%解决了现有问题。此外，修复也属于诸如破坏性更改、紧急和等待等标签。与内部PR不同，外部PR涵盖文档变更（384个PR中的44个），而没有那么多的重构（384个PR中的34个）。另一方面，外部PR还涵盖了新功能（384个PR中的380个）和错误（384个PR中的120个）。我们的研究结果为理解维护人员如何决定他们选择哪些外部贡献来发展他们的库以及他们在减少工作量方面扮演什么角色奠定了基础。
2022-07-08 cs.SE
How Effective Are NPM Malicious Package Detectors? A Large-Scale Empirical Study
Nanyang Technological University（南洋理工大学）；Sichuan University（四川大学）；Imperial Global Singapore（帝国理工学院新加坡）；Nankai University（南开大学）；Singapore Management University（新加坡管理大学）
本文基于基准测试分析NPM恶意软件包检测，构建包含6420个恶意和7288个良性包的数据集，评估8种工具的性能，揭示工具精度-召回率由代码意图解析决定，GuardDog达到93.32% F1，SAP_DT检测率提升至79.3%。
2026-08-06 cs.SE
CHRONO-RESOLUTION: A Dependency Resolution Dataset at Release Points for npm, PyPI, and crates.io Packages
North Carolina State University（北卡罗来纳州立大学）
本文旨在借助丰富数据集助从业者和研究者分析软件包发布点的生态系统依赖图，提出构建软件生态系统包发布点依赖项解析的方法，融入漏洞数据构建CHRONO-RESOLUTION数据集并发布，以推动相关研究。
2026-07-20 cs.CR cs.SE
Practical Automated Detection of Malicious npm Packages
npm注册表是JavaScript和TypeScript生态系统的支柱之一，托管了超过170万个包，从简单的实用程序库到复杂的框架和整个应用程序。由于npm的压倒性流行，它已成为恶意行为者的主要目标，他们发布新的包或破坏现有的包，以引入恶意软件，篡改或暴露安装这些包或任何（过渡性）依赖于它们的包的用户的敏感数据。防御此类攻击对于维护软件供应链的完整性至关重要，但软件包更新的绝对数量使得全面的手动审查变得不可行。我们提出了Amalfi，一种基于机器学习的方法，用于自动检测由三种互补技术组成的潜在恶意软件包。我们从已知的恶意和良性软件包的例子训练分类器开始。如果一个软件包被分类器标记为恶意软件，我们就会检查它是否包含有关其源代码库的元数据，如果包含，则检查该软件包是否可以从其源代码中复制。可从源代码复制的包通常不是恶意的，因此这一步允许我们剔除误报。最后，我们还采用了一个简单的文本克隆检测技术来识别可能被分类器错过的恶意软件包的副本，减少了误报的数量。Amalfi改进了现有技术，因为它是轻量级的，每个包只需要几秒钟就可以提取特征并运行分类器，并且在实践中取得了良好的效果：在一周内发布的96287个包版本上运行它，我们能够识别95个以前未知的恶意软件样本，误报数量可控。
2022-02-28 cs.CR cs.SE
ProfMalPlus: Agent-Coordinated Detection of Malicious NPM Packages via Static-Dynamic Analysis Synergy
Fudan University（复旦大学）
研究针对NPM包恶意代码检测问题，提出ProfMalPlus，结合对象敏感行为图与大语言模型推理，经多步骤提取安全切片并评估，对不确定情况增强证据后再评估，最终定位恶意代码，F1分数高且发现多个未知恶意包，性能优于现有检测器。
2026-07-16 cs.CR cs.SE
On the Threat of npm Vulnerable Dependencies in Node.js Applications
软件漏洞对我们日常依赖的软件系统有很大的负面影响。有关软件漏洞的报告总是描绘出一幅严峻的画面，一些报告显示，83%的组织依赖于易受攻击的软件。然而，我们的经验使我们相信，在宏伟的计划中，这些软件漏洞的影响可能比报告的要小。因此，我们进行了一项研究，以更好地了解Node.js应用程序中使用的npm漏洞包的威胁。我们根据软件包的生命周期为软件包中的漏洞定义了三个威胁级别，其中，如果软件包漏洞在依赖应用程序中使用时被隐藏或仍然未知，则将其分配为低威胁级别（t），如果漏洞在t时被报告但尚未发布，则为中等威胁级别，如果在t时公开宣布，则为高威胁级别。然后，我们进行了一项实证研究，涉及6，673个真实世界，活跃和成熟的开源Node.js应用程序。我们的研究结果显示，虽然67.93%的受检查的应用程序依赖于至少一个易受攻击的软件包，但这些受影响的应用程序中94.91%的易受攻击的软件包被归类为具有低威胁。此外，我们发现，在被归类为具有高威胁的易受攻击的软件包的情况下，正是应用程序缺乏更新使得它们易受攻击，即，真正的问题并不是脆弱性的存在。此外，我们在应用程序生命周期的不同阶段验证了我们的研究结果，发现我们的研究结果仍然成立。我们的研究认为，当涉及到软件漏洞时，事情可能并不像看起来那么糟糕，考虑漏洞威胁是关键。
2020-09-18 cs.SE
A Machine Learning Approach to Determine the Semantic Versioning Type of npm Packages Releases
语义版本控制策略被广泛用于指示软件包发布中的更改级别。不幸的是，在许多情况下，开发人员不尊重语义版本策略，导致依赖应用程序的破坏。为了减少这种情况，我们提出使用机器学习（ML）技术来有效地预测新的发布类型，即，补丁、次要、主要，以便正确地确定语义版本化类型。为了执行我们的预测，我们挖掘并使用了关于发布的许多特性，例如更改代码的复杂性，更改类型和开发活动。然后我们使用了四个ML分类器。为了评估所提出的ML分类器的性能，我们对31个JavaScript包进行了实证研究，这些包总共包含大约6，260个版本。我们首先从包的源代码和存储库的历史数据中提取了41个发布级别的特性。然后，我们使用了四个机器学习分类器，即XGBoost，随机森林，决策树和Logistic回归。我们发现XGBoost分类器表现最好，主要、次要和补丁释放的中位ROC AUC值分别为0.78、0.69和0.74。我们还发现，在确定语义版本控制类型时，与版本中的更改类型相关的功能是功能组的最佳预测因子。最后，我们研究了通过应用跨包验证确定语义版本类型的通用性。我们的研究结果表明，一般分类器实现的主要，次要和补丁释放的中位ROC AUC值为0.76，0.69和0.75。
2022-04-12 cs.SE
Not All Dependencies are Equal: An Empirical Study on Production Dependencies in NPM
现代软件系统通常是通过利用其他人以库和包的形式编写的代码来构建的，以加速其开发。虽然使用第三方软件包有很多好处，但软件项目往往依赖于大量的软件包。因此，开发人员面临着通过保持项目依赖性的最新和无安全漏洞来维护项目依赖性的艰巨挑战。然而，在生产环境中，项目依赖关系会对项目的安全性构成威胁，这种情况有多频繁？我们使用Node Package Manager（npm）对100个JavaScript项目进行了实证研究，以量化项目依赖关系发布到生产环境的频率，并分析其特征及其对安全性的影响。我们的结果表明，只有不到1%的已安装依赖项被发布到生产环境。我们的分析表明，软件包的功能不足以决定它是否会被发布到生产环境。事实上，59%的已安装依赖配置为运行时依赖，并没有在生产中使用，而28.2%的依赖配置为开发依赖在生产中使用，揭穿了依赖管理的两个常见假设。调查结果还表明，大多数安全警报针对的是生产中未使用的依赖项，这使得它们极不可能对软件的安全性构成风险。我们的研究揭示了依赖管理更复杂的一面：并非所有的依赖都是平等的。生产中使用的安全性对安全性暴露更敏感，应优先考虑。然而，当前的工具在识别生产依赖性方面缺乏适当的支持。
2022-08-29 cs.SE
Analyzing the Accessibility of GitHub Repositories for PyPI and NPM Libraries
本研究通过 PageRank 算法分析 PyPI 和 NPM 库的 GitHub 仓库可访问性，发现多数库（尤其重要库）可监控，但部分库缺少 URL，建议维护者更新信息。
2025-04-23 cs.SE
Patterns of Effort Contribution and Demand and User Classification based on Participation Patterns in NPM Ecosystem
背景：开源需要志愿者和商业开发人员（用户）的参与，以提供功能性高质量的组件。开发人员都贡献努力的补丁和需求的组件维护者的努力，以解决问题的形式报告，对it.Aim：识别和描述模式的努力贡献和需求在整个开源供应链，并调查这些模式是否以及如何与开发活动的变化;确定不同的开发人员群体;并预测开发人员的公司隶属关系的基础上，他们的参与模式。方法：为4433个NPM包创建了1，376，946个问题和拉取请求，每月下载量超过10，000次，获得并分析了272，142个问题创建者的完整（公开）提交活动数据，并识别了对NPM包的依赖性。模糊c-均值聚类算法被用来找到组之间的用户的基础上，他们的努力贡献和需求模式，和随机森林被用来作为预测建模技术，以确定他们的公司隶属关系。测试结果：用户贡献和要求的工作主要来自他们直接依赖的包，只有一小部分贡献和要求传递依赖。很大一部分需求进入了用户各自供应链之外的软件包（基于公开可见的版本控制数据构建）。根据工作需求和工作贡献模式，分别观察到三组和两组不同的用户。用于识别用户的公司从属关系的随机森林模型给出0.68的AUC-ROC值。结论：我们的研究结果为NPM生态系统及其用户的供应链不同部分的努力需求和供应提供了新的见解，并建议需要进一步提高上游的可见性。
2019-07-15 cs.CY cs.SE
Lags in the Release, Adoption, and Propagation of npm Vulnerability Fixes
第三方依赖关系中的安全漏洞不仅是受影响软件的开发人员日益关注的问题，而且还对整个软件生态系统构成风险，例如，心脏出血漏洞。最近的研究表明，开发人员对漏洞威胁的反应很慢，有时需要4到11个月才能采取行动。为了确保快速采用和传播的版本，包含修复（修复版本），我们进行了实证调查，以确定可能发生的滞后之间的脆弱的版本和它的修复版本（包端修复版本）。通过对GitHub上npm项目的231个包端修复版本的初步研究，我们观察到修复版本很少单独发布，高达85.72%的捆绑提交与修复无关。然后，我们将包端修复版本与客户端（客户端修复版本）上的更改进行比较。通过对影响整个网络的1，553，325个npm包版本的1，290个包端修复版本的采用和传播趋势的实证研究，我们发现陈旧的客户端需要额外的迁移工作，即使包端修复版本很快（即，包补丁着陆）。此外，我们显示的影响因素，如包端固定释放土地上的分支和脆弱性的严重程度，其传播。除了这些滞后，我们确定和表征，本文奠定了基础，为未来的研究如何减轻滞后的生态系统。
2021-03-31 cs.CR cs.SE
SpellBound: Defending Against Package Typosquatting
基于单一程序设计语言的软件存储库的包管理器非常常见。例子包括npm（JavaScript）和PyPI（Python）。这些工具鼓励代码重用，使开发人员导入外部包变得微不足道。不幸的是，仓库的大小和发布软件包的容易程度促进了排印的实践：上传一个与一个非常流行的软件包名称相似的软件包，通常目的是捕获一些流行软件包的安装。错别字有严重的负面影响，导致开发人员导入恶意软件包，或者-正如我们所展示的-不包含最新安全更新的代码克隆。为了解决这个问题，我们提出了SpellBound，一个工具，用于识别和报告潜在的错误导入开发人员。SpellBound基于对npm和PyPI的深入分析，实现了一种新的排版检测技术。我们的技术利用名称之间的词汇相似性模型，并进一步结合了包流行度的概念。这种方法会在安装之前标记未知/很少使用的软件包将被安装在具有相似名称的流行软件包的位置的情况。我们在npm和PyPI上对SpellBound进行了评估，结果令人鼓舞：SpellBound在生成有限警告（占软件包安装总量的0.5%）的同时标记了typosquatting案例，并且开销很低（仅占软件包安装时间的2.5%）。此外，SpellBound允许我们确认已知的typosquatting案例，并发现一个备受瞩目的未知typosquatting案例，导致npm安全团队删除了一个包。
2020-03-06 cs.CR cs.SE
SōjiTantei: Function-Call Reachability Detection of Vulnerable Code for npm Packages
软件项目采用第三方依赖关系已经成为一种常见的做法。我们鼓励开发人员更新任何过时的依赖项，以免受潜在的漏洞威胁。在这项研究中，我们提出了一种方法来帮助开发人员显示是否有一个脆弱的代码是可达的JavaScript项目。我们的原型SōjiTantei从两个方面进行评估：（i）与手动方法相比的准确性;（ii）对78个安全漏洞案例中的780个客户端进行更大规模的分析。第一次评估显示，SōjiTantei具有83.3%的高准确性，每个客户端的分析速度不到一秒。第二次评估显示，在研究的78个漏洞中，有68个报告至少有一个干净的客户端。该研究证明，自动化是有前途的，有进一步改进的潜力。
2021-09-18 cs.CR cs.SE
Assumptions to Evidence: Evaluating Security Practices Adoption and Their Impact on Outcomes in the npm Ecosystem
North Carolina State University（北卡罗来纳州立大学）
本研究通过分析145K个npm包，评估安全实践采用与安全结果的关系，发现聚合采用安全实践可显著减少漏洞并加快修复和更新速度，且仓库特征影响实践效果。
2025-08-02 cs.LG cs.SE
NCQ: Code reuse support for node.js developers
代码重用是软件开发的重要组成部分。代码重用实践的采用在Node.js开发人员中尤其普遍。Node.js包管理器NPM索引了超过100万个包，开发人员经常寻找包来解决编程任务。由于软件包数量众多，选择合适的软件包既困难又耗时。为了提高通过第三方包大量重用代码的开发人员的生产力，我们提出了节点代码查询（NCQ），一个读取-评估-打印-循环环境，允许开发人员1）使用自然语言查询搜索NPM包，2）搜索与这些包相关的代码片段，3）自动纠正这些代码片段中的错误，4）快速设置新的环境来测试这些片段，以及5）在搜索和编辑模式之间转换。在两项共有20名参与者的用户研究中，我们发现参与者使用NCQ比基线方法更快地开始编程并更快地完成任务，并且他们喜欢搜索代码片段和包等功能。我们的研究结果表明，NCQ使Node.js开发人员在重用代码方面更有效率。
2023-01-02 cs.SE
License Incompatibilities in Software Ecosystems
当代软件的特点是重用组件，这些组件被声明为依赖关系，并从包管理器/注册中心接收，如NPM，PyPI，RubyGems，Maven Central等。在本文中，我们研究了来自七个软件包注册表（Cargo，Maven，NPM，NuGet，Packagist，PyPI，RubyGems）的所有组件之间的许可证使用和许可证不兼容性，并对GNU Affero通用公共许可证（AGPL）引起的许可证不兼容性进行了更深入的调查。我们发现，不同生态系统之间使用的许可证的相对数量不同（MIT和Apache等许可证最常见），直接许可证不兼容的数量从Cargo的2.3%到PyPI的20.8%不等，只有少量的直接许可证不兼容是由AGPL许可证引起的（最大值）。PyPI中为0.04%），但高达6.62%的Maven包违反了间接依赖的AGPL许可证。我们的研究结果表明，重用PyPI或Maven软件包的应用程序面临许可证不兼容的可能性并不太大，这可能意味着应用程序必须在分发时开源（PyPI），或者一旦它们作为Web应用程序公开（Maven）。
2022-03-03 cs.SE
PoCGen: Generating Proof-of-Concept Exploits for Vulnerabilities in Npm Packages
University of Stuttgart（斯图加特大学）；CISPA Helmholtz Center for Information Security（CISPA亥姆霍兹信息安全中心）
本文提出PoCGen，通过结合大语言模型和静态动态分析，自动生成并验证npm包漏洞的概念验证漏洞利用，成功率达77%，优于现有基线方法。
2026-06-28 cs.CR cs.SE
Breaking the borders: an investigation of cross-ecosystem software packages
软件生态系统是在同一环境中开发和发展的项目的集合。现有的文献调查软件生态系统作为孤立的实体，其边界不重叠，并假设它们是自包含的。然而，许多软件项目分布在不止一个生态系统中。作为不同的方面，例如，成功、安全漏洞、错误等，这种跨生态系统的软件包可能会影响多个生态系统，我们调查了这些跨生态系统的软件包在12个大型软件发行版中的存在和特点。我们发现少量的软件包分布在多个包装生态系统中，这些软件包通常分布在两个生态系统中。这些软件包倾向于更好地支持某些生态系统的新版本，而它们的发展可能会影响其他生态系统中的大量软件包。最后，这样的软件包似乎在大型开发人员社区中很受欢迎。
2018-12-13 cs.SE
On the Dependency Heaviness of CRAN/Bioconductor Ecosystem
R包生态系统正在快速扩展，生态系统中包之间的依赖关系变得越来越复杂。在本研究中，我们从一个新的方面探索了包依赖关系。我们应用了一个新的度量标准，名为“依赖沉重性”，它测量了一个包对其子包或下游包唯一贡献的额外强依赖项的数量。它还测量了当包的角色从强父级更改为弱父级时，生态系统中减少的总依赖性。我们系统地研究了依赖性如何从父包传播到子包，以及它如何进一步传播到CRAN/Bioconductor生态系统中的远程下游包。我们提取了生态系统中主要传输严重依赖的顶级包和关键路径。此外，生态系统上的依赖性分析已经实现为基于Web的数据库，该数据库提供了用于查询单个R包依赖性的综合工具。
2023-01-05 cs.SE
Promises and Perils of Mining Software Package Ecosystem Data
本文综述了挖掘软件包生态系统数据的承诺与风险，探讨了依赖网络获取、边界界定、未使用依赖检测、开发者识别等挑战，并强调了跨语言泛化问题。
2023-05-29 cs.SE
Dependency Update Strategies and Package Characteristics
本文通过分析超11.2万个npm包的19个特征构建预测模型，研究依赖更新策略的选择与演变，发现依赖方数量、年龄和发布状态影响最大，且模型比npm默认策略更符合社区决策。
2023-05-25 cs.SE
A complex network analysis of the Comprehensive R Archive Network (CRAN) package ecosystem
自由和开源软件包生态系统已经存在了很长时间，是最复杂的人造系统之一。最古老和最流行的软件包生态系统之一是CRAN，它是统计语言R的软件包存储库，也是当今最流行的统计计算环境之一。CRAN存储了大量定期更新的包，并依赖于复杂关系图中的许多其他包;本文从复杂网络分析（CNA）的角度对这种图进行了实证研究，展示了以前工作提出的网络理论和措施如何帮助分析生态系统并从三个角度检测优势，良好实践和潜在风险：生态系统的宏观属性（网络的结构和复杂性）、单个包的微观属性（表示为节点）和模块化属性（社区发现）。结果表明，复杂的网络分析工具可以用来评估一个包的生态系统，特别是CRAN。
2020-07-15 cs.SE
Intertwining Communities: Exploring Libraries that Cross Software Ecosystems
在应用程序中使用库可以帮助开发人员降低重新开发现有代码的成本。然而，不同技术栈和第三方库使用的增加导致开发人员不可避免地切换技术并搜索在新技术中实现的类似库。为了帮助寻找这些替代库，维护人员已经开始将他们的库发布到多个生态系统。我们的目标是探索这些图书馆在生态系统之间相互交织的程度。我们对来自五个不同软件生态系统的110万个库进行了大规模的实证研究，即，PyPI、CRAN、Maven、RubyGems和NPM，以识别4，146个GitHub存储库。作为一个起点，这项研究的见解为图书馆维护者、用户、贡献者和研究人员提供了启示，帮助他们了解这些不同的生态系统如何变得更加相互交织。
2023-03-16 cs.SE
Towards Robust Detection of Open Source Software Supply Chain Poisoning Attacks in Industry Environments
针对 NPM 与 PyPI 供应链投毒，本文提出 OSCAR 动态检测流水线，结合沙箱执行、模糊测试和方面级行为监控，在工业部署中显著降低误报并发现大量恶意包。
2024-09-14 cs.CR cs.SE
