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
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
Detecting and Characterizing Low and No Functionality Packages in the NPM Ecosystem
Faculty of Engineering, Kasetsart University（泰国农业大学工程学院）；Nara Institute of Science and Technology (NAIST)（奈良先端科学技术大学院大学）
本研究针对npm生态系统中低功能/无功能包的安全风险问题，完善相关定义并提出纯数据包概念，开发基于规则的静态分析检测工具，在2025年npm生态中验证其94%的准确率，为降低依赖管理中的技术债务与安全风险提供支持。
2025-10-06 cs.SE
PVAC: Package Version Activity Categorizer, Leveraging Semantic Versioning in a Heterogeneous System
本研究提出系统方法和原型工具 PVAC，通过解析语义化版本控制细节并利用三个组件对异构包管理器生态系统中的版本活动进行分类与定量评分，在 Debian 和 Ubuntu 数据集上验证了其准确性与有效性。
2025-05-31 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
Where to Go Now? Finding Alternatives for Declining Packages in the npm Ecosystem
本文提出一种基于 npm 生态中真实依赖迁移模式的方法，自动识别衰退软件包并推荐替代方案，实验显示替代建议准确率达 96%，且获 67% 专业 JavaScript 开发者认可。
2023-08-16 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
What are the characteristics of highly-selected packages? A case study on the npm ecosystem
随着软件生态系统的普及，开源组件（称为包）的数量迅速增长。从大量的软件包中识别出高质量和维护良好的软件包是一个基本而重要的问题，因为它对各种应用程序都有好处，例如软件包推荐和软件包搜索。然而，除了在线讨论或非正式文献和访谈之外，没有任何系统和全面的工作侧重于解决这一问题。为了填补这一空白，在本文中，我们进行了混合定性和定量分析，以了解开发人员如何识别和选择相关的开源软件包。特别是，我们首先调查了来自npm生态系统的118名JavaScript开发人员，以定性地了解使包在npm生态系统中被高度选择的因素。调查结果显示，JavaScript开发人员认为，高度选择的软件包有良好的文档记录，在GitHub上获得大量的星星，有大量的下载，并且没有漏洞。然后，我们进行了一个实验，以定量验证开发人员对高选择性软件包的因素的看法。在这项分析中，我们收集和挖掘了2,527个软件包的历史数据，这些软件包分为高选择和非高选择软件包。对于数据集中的每个包，我们收集了定量数据，以呈现开发人员调查中研究的因素。接下来，我们使用回归分析来定量研究哪些研究因素是最重要的。我们的回归分析补充了我们关于精选套餐的调查结果。特别是，结果表明，高选择的软件包往往与下载次数、星级和软件包的自述文件大小相关。
2022-04-09 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
Towards Sustainable and Secure Reuse in Dependency Supply Chains: Initial Analysis of NPM packages at the End of the Chain
Nara Institute of Science and Technology（奈良先端科学技术大学院大学）；The University of Osaka（大阪大学）
本文初步分析 NPM 中无外部依赖的链路末端包，发现其占关键依赖链逾半数且特征多样，为平衡复用收益与安全可持续实践提供启示。
2025-10-06 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
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
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
Systematic literature review of the trust reinforcement mechanisms exist in package ecosystems
本文通过系统性文献综述梳理npm安全与信任工具现状，分析开发者选择第三方包的动机、告警响应及安全认知，并识别SECO集成复杂性与研究空白。
2024-06-26 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
On the Feasibility of Cross-Language Detection of Malicious Packages in npm and PyPI
本研究提出一种基于语言无关特征的跨语言恶意包检测方法，通过训练模型捕捉 npm 和 PyPI 中恶意包的共性，成功检测出58个未知恶意包。
2023-10-14 cs.CR 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
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
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
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
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
Practical Automated Detection of Malicious npm Packages
npm注册表是JavaScript和TypeScript生态系统的支柱之一，托管了超过170万个包，从简单的实用程序库到复杂的框架和整个应用程序。由于npm的压倒性流行，它已成为恶意行为者的主要目标，他们发布新的包或破坏现有的包，以引入恶意软件，篡改或暴露安装这些包或任何（过渡性）依赖于它们的包的用户的敏感数据。防御此类攻击对于维护软件供应链的完整性至关重要，但软件包更新的绝对数量使得全面的手动审查变得不可行。我们提出了Amalfi，一种基于机器学习的方法，用于自动检测由三种互补技术组成的潜在恶意软件包。我们从已知的恶意和良性软件包的例子训练分类器开始。如果一个软件包被分类器标记为恶意软件，我们就会检查它是否包含有关其源代码库的元数据，如果包含，则检查该软件包是否可以从其源代码中复制。可从源代码复制的包通常不是恶意的，因此这一步允许我们剔除误报。最后，我们还采用了一个简单的文本克隆检测技术来识别可能被分类器错过的恶意软件包的副本，减少了误报的数量。Amalfi改进了现有技术，因为它是轻量级的，每个包只需要几秒钟就可以提取特征并运行分类器，并且在实践中取得了良好的效果：在一周内发布的96287个包版本上运行它，我们能够识别95个以前未知的恶意软件样本，误报数量可控。
2022-02-28 cs.CR 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
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
Contributing Back to the Ecosystem: A User Survey of NPM Developers
本文通过对 49 名 NPM 开发者的调查发现，开发者更倾向于维护自己的包而非回馈生态系统，并据此为库生态系统的可持续性研究及工具支持提供了新方向。
2024-07-01 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
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
Extracting Insights from the Topology of the JavaScript Package Ecosystem
软件生态系统对计算和社会产生了巨大的影响，吸引了企业、研究人员和政策制定者的关注。像JavaScript节点包管理器（npm）这样的大规模生态系统就是软件项目如何容易使用包的证据。由于软件生态系统的高维性和复杂性，其分析方法受到了限制。在本文中，我们利用拓扑方法可视化软件生态系统的高维数据集。拓扑数据分析（TDA）是一种新兴的分析高维数据集的技术，它使我们能够研究数据的形状。我们生成了npm软件生态系统拓扑，通过研究其位置来揭示现有库的见解和提取模式。我们的真实世界的例子揭示了许多有趣的见解和模式，描述了软件生态系统的形状。
2017-10-02 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
Possible Directions for Improving Dependency Versioning in R
R最强大的功能之一是它的贡献代码基础设施。内置的包管理器和补充存储库为代码的开发和交换提供了一个很好的系统，并且在平台向当今统计计算的事实标准发展的过程中发挥了重要作用。然而，CRAN和其他存储库上的软件包数量的增加超出了预期，并揭示了当前设计的一些局限性。其中一个问题是基础设施中普遍缺乏依赖性版本控制。本文更详细地探讨了这个问题，并建议其他开源社区采取的方法也适用于R。定义了三个用例来解决这个问题，并说明了如何改善包管理的这一方面可以提高可靠性，同时支持R社区的进一步发展。
2013-11-01 cs.MS cs.SE stat.CO
Lost in Zero Space -- An Empirical Comparison of 0.y.z Releases in Software Package Distributions
专用于特定程序设计语言的开放源码软件包的分发通过允许软件项目依赖于这种可重用软件包所提供的功能来促进软件开发。软件项目的健康状况可能会受到它所依赖的软件包的成熟度的影响。所使用的软件包版本号提供了其成熟度的指示。带有0.y.z版本号的软件包通常被认为处于初始开发阶段，这表明它们可能不太稳定，并且依赖于它们可能被认为是不太健康的。在本文中，我们实证研究了四个开源软件包发行版（Cargo，npm，Packagist和RubyGems）在何种程度上0.y.z软件包发行版和>=1.0.0软件包发行版的行为不同。我们量化了0.y.z版本的流行程度，我们探索了软件包在初始开发阶段的持续时间，我们比较了0.y.z和>=1.0.0软件包版本的更新频率，我们研究了其他软件包需要0.y.z版本的频率，我们评估了语义版本是否尊重对它们的依赖，我们比较了托管在GitHub上的0.y.z和>=1.0.0包存储库的一些特征。除此之外，我们观察到包发行版比语义版本控制对0.y.z版本的要求更宽松，并且许多0.y.z版本实际上可以被视为成熟的包。因此，版本号并不能很好地指示软件包发布的成熟度。
2021-01-04 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
Measuring Software Innovation with Open Source Software Development Data
本文提出基于 GitHub 开源软件开发活动的软件创新度量方法，通过分析 JS、Python 和 Ruby 生态中依赖增长与发布复杂性，发现语义版本控制信号而非技术变更驱动了依赖增长，需结合生态文化等因素加权以准确捕捉创新动态。
2025-06-30 cs.SE
Dependency Update Strategies and Package Characteristics
本文通过分析超11.2万个npm包的19个特征构建预测模型，研究依赖更新策略的选择与演变，发现依赖方数量、年龄和发布状态影响最大，且模型比npm默认策略更符合社区决策。
2023-05-25 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
I depended on you and you broke me: An empirical study of manifesting breaking changes in client packages
本文实证研究 npm 生态中依赖更新引发的破坏性变更，量化其对客户端包构建的影响及恢复方式，发现非主版本更新仍会造成显著破坏。
2023-01-11 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
An Empirical Study of Yanked Releases in the Rust Package Registry
Cargo是Rust的软件打包管理器，它提供了一个yank机制来支持版本级别的弃用，这可以防止软件包依赖于yanked release。大多数先前的研究集中在代码级（即，弃用的API）和包级弃用（即，已弃用的包）。然而，很少有研究关注发布级的弃用。在这项研究中，我们调查了yank机制的使用频率和使用方式，其使用背后的原理，以及在Cargo生态系统中采用yanked release。我们的研究表明，Cargo中9.6%的包裹至少有一次被猛拉释放，并且从2014年到2020年，猛拉释放的比例不断增加。软件包所有者出于其他原因而不是撤回有缺陷的版本，例如修复不遵循语义版本控制的版本或指示软件包被删除或替换。此外，我们发现46%的软件包直接采用了至少一个yanked版本，并且yanked版本通过依赖网络传播，这导致生态系统中1.4%的版本具有未解决的依赖关系。
2022-01-27 cs.SE
The Range Shrinks, the Threat Remains: Re-evaluating LLM Package Hallucinations on the 2026 Frontier-Model Cohort
Anthropic；OpenAI；Google；DeepSeek
本文重新评估了2026前沿模型队列上大型语言模型（LLM）的包幻觉现象，发现尽管幻觉率有所降低，但仍然存在威胁，识别出一组127个包名（109个在PyPI，18个在npm）被所有评估模型一致生成，构成一个跨模型的供应链攻击面，同时发现Python与JavaScript幻觉的不对称性以及DeepSeek V3.2和GPT-5.4-mini之间的高相似性。
2026-11-10 cs.CR cs.LG cs.SE
Are your dependencies code reviewed?: Measuring code review coverage in dependency updates
由于现代软件广泛使用免费的开源软件包作为依赖项，开发人员必须通过频繁的更新定期引入新的第三方代码。然而，如果不对每个传入的更改进行适当的审查，易受攻击的代码和恶意代码就可以通过这些依赖项潜入代码库。本研究的目标是帮助开发人员通过测量更新中的代码更改是否通过了代码审查过程，安全地接受依赖更新。我们实现了Depdive，这是一个更新审计工具，用于Crates.io，npm，PyPI和RubyGems注册表中的包。Depdive first（i）标识更新中无法追溯到软件包的源存储库的文件和代码更改，即，\textit{phantom artifacts} ;然后（i i）测量更新中的改变的哪一部分（不包括幻影工件）已经通过代码审查过程，即，\textit{code review coverage}。使用Depdive，我们提出了一个实证研究，在最近十次更新的最下载的1000个软件包在四个注册表。我们通过维护者协议调查进一步评估了我们的结果。我们发现更新通常只进行部分代码审查（52.5%的时间）。此外，在我们的数据集中，只有9.0%的软件包的所有更新都经过了完全的代码审查，这表明即使是最常用的软件包也会在软件供应链中引入未经审查的代码。我们还观察到，更新要么倾向于具有高\textit{CRC}，要么倾向于具有低\textit{CRC}，这表明在谱的另一端的包可能需要一组单独的处理。
2022-11-07 cs.SE
Open or Sneaky? Fast or Slow? Light or Heavy?: Investigating Security Releases of Open Source Packages
开放源码包中的漏洞对于将这些包用作依赖项的客户端项目来说可能是一个安全风险。当在软件包中发现新漏洞时，软件包应快速发布新版本的修复程序，在本研究中称为安全发布。安全版本应该有很好的文档记录，并且只需要最少的迁移工作，以促进客户端项目的快速采用。然而，开源软件包在多大程度上遵循这些建议尚不清楚。本研究的目标是帮助软件从业者和研究人员了解目前的做法，释放安全补丁的开源软件包，并确定改进的领域，通过实证研究的安全版本。具体来说，本文研究了（1）修复和发布之间的时间差;（2）如何在发布说明中记录安全修复;（3）代码更改特征（大小和语义版本）的发布;以及（4）发布与Snyk或NVD上的咨询出版物之间的时间差（两个流行的漏洞数据库）的安全版本，涵盖七个软件包生态系统中的4，377个安全数据集。我们发现，中值安全版本在相应修复后的4天内可用，并包含134行代码（代码）更改。此外，我们发现61.5%的安全版本都附带了一个发布说明，记录了相应的安全修复程序。但是，Snyk和NVD可能需要25天（从发布开始）才能发布这些安全版本的建议，这可能会导致延迟通知客户项目。根据我们的研究结果，我们为软件包维护者和生态系统管理员提出了四项建议，例如使用私有分叉进行安全修复，以及标准化发布安全版本的做法。
2021-12-13 cs.CR cs.SE
Bridging the Language Gap: An Empirical Study of Bindings for Open Source Machine Learning Libraries Across Software Package Ecosystems
University of Alberta（阿尔伯塔大学）
本文通过BindFind方法收集并实证研究跨13个软件包生态系统的2,436个ML库绑定，揭示其多由社区维护、版本覆盖有限且技术滞后严重，为开发者集成与后续研究提供依据。
2024-08-19 cs.LG cs.SE
A Difference Without a Distinction: A Measurement Study of Release Trust Evidence in Package Registries
International University of La Rioja（里奥哈国际大学）
提出一种前驱感知的发布权威记录，通过比较发布路径证据（发布者、仓库、工作流、来源、签名、中介）识别策略触发的发布路径不连续性，经npm等五个生态系统的审计样本验证，触发策略可有效筛选需审查的发布。
2026-10-27 cs.CR cs.SE
Which Is Better For Reducing Outdated and Vulnerable Dependencies: Pinning or Floating?
North Carolina State University（北卡罗来纳州立大学）
本研究通过实证分析npm、PyPI和Cargo生态系统中依赖版本约束的使用趋势，利用生存分析比较固定版本与浮动版本对依赖过时和易受攻击风险的影响。
2026-05-24 cs.CR cs.LG cs.PL
