许多流行的包管理器未能充分防范被篡改的仓库注入恶意代码。虽然密码学哈希和签名可以解决这一问题，但众多包管理器仍易受攻击。在测试的 25 种管理器中，不到一半默认使用锁文件（lockfiles）来检测篡改，且仅有两种验证了所有下载包的完整性。一旦开发者层面的漏洞利用难度增加，攻击者更可能转向包仓库。密码学解决方案较为复杂，许多实现因设计选择或资源限制而未能达到预期。将密码学哈希纳入锁文件以进行验证是一种常见做法，但各包管理器的实现方式各异。仅有少数管理器（如 Go）默认验证包完整性，而其他管理器则需要额外配置或缺乏完整性验证。签名验证可避免安全哈希分发的需求，但其实现也不一致。Go 是唯一默认验证签名的管理器，其他管理器则需要额外设置或缺乏签名支持。测试结果显示，密码学设计和安全水平存在显著差异。研究团队开发了一套基于 Docker 和 mitmproxy 的测试框架，用于模拟来自恶意仓库的攻击，并动态评估包管理器在面临被篡改服务器时的安全性。HTTPS 被大多数包管理器广泛采用，cpanminus 是一个显著例外，它使用未加密的 HTTP。哈希函数的本意是确保文件完整性，但挑战在于如何将正确的哈希值传达给包管理器。Vcpkg 使用预计算的哈希值，这些哈希值存储在其源代码中用于验证。锁文件是包管理器获取正确哈希值的更常用方法。Bun、npm 和 Cargo 等包管理器使用带哈希的锁文件进行自动完整性检查。部分管理器（如 Pip 和 Conda）提供实验性或可选的锁文件支持，而 Maven 和 Composer 则缺乏专用的锁文件。令人惊讶的是，某些锁文件中的哈希值无法有效防止被篡改，例如在 Pub 和 pnpm 中，默认情况下可能忽略哈希不匹配的情况。Conan 和 CocoaPods 将哈希用作标识符，而非用于密码学完整性验证。