Package Manager Integrity Study: Only 2 of 25 Verified All Downloads by Default in Tests

1. Basic Information

• Article Title: Package managers have an integrity problem
• Publisher: Trail of Bits
• Original: Trail of Bits
• Publication Date: 2026-10-14
• Related Sources: Go Modules Reference: Authenticating modules, Gradle: Verifying Dependencies
• Importance: High

2. Summary

Among the 25 package managers Trail of Bits evaluated using public packages, fewer than half used lockfiles for tamper checks by default. Under the study's test conditions, only Go and vcpkg verified the integrity of every package downloaded by default.

3. Security Issue

• Measuring the issue where package managers fail to detect malicious code injected into legitimate packages by a compromised package repository.

4. Proposal and Evaluation Method

• Containerizing 25 package managers and using mitmproxy to simulate a malicious repository, evaluating the actual behavior of hash and signature verification.

5. Inputs

• For each package manager, one version and one package from a public repository, evaluated on Ubuntu using primarily quickstart configurations and default command flags.
• Lockfiles, repository signatures, developer signatures, and transparency logs.
• A mitmproxy harness to inject malicious code.

6. Outputs

• Four categories of lockfile-based integrity.
• Four categories of signature verification.
• Default defense states of each tool against repository compromise.

7. Evaluation Workflow

1. Fetch dependencies both with and without a lockfile.
2. Insert malicious modifications into the repository response.
3. Check whether fetching or installing the modified package is stopped or requires additional configuration. Count the attack as successful if the sample code executes the injected code.
4. Compare the design, distribution, and verification paths of hashes and signatures.

8. Evaluation Design

• Target: 25 package managers
• Threat Model: Simulated compromise of public-facing distribution servers, while assuming backend resources such as private signing keys remain secure.
• Harness: Docker container and mitmproxy
• Verified every package downloaded by default under these test conditions: Go, vcpkg

9. Key Results

• Under these test conditions, Go and vcpkg were the only tools that verified the integrity of every package downloaded by default.
• Fewer than half used lockfiles for default tamper checks.
• In the study, only Go verified signatures by default.
• Many tools required additional configuration, had partial implementations, or lacked verification even when lockfiles or signatures were present.

10. Practical Implications

• Do not assume the presence of SBOMs or lockfiles guarantees control; verify CI failure behavior as well.
• Design defenses by separating developer account compromise mitigations from repository compromise mitigations.

11. Success Criteria

• For hash-based verification, immutable lockfiles or trusted metadata must store package content hashes obtained through a trusted channel.
• Compare downloads against trusted hashes for hash-based verification, or verify authenticity using trusted signers and public keys for signature-based verification. Enforce the applicable verification on every download, and stop installation on mismatch.

12. Constraints and Limitations

• The study tested one version of each package manager and one package on Ubuntu. These conditions may not represent common usage, particularly for tools such as PowerShell and CocoaPods.
• The research simulated repository compromise and did not measure real-world breach counts or malware distribution rates.
• Some ecosystems can achieve stronger verification through additional configuration.
• For Go, a module can be accepted without checksum-database verification when go.sum has no known hash and either the module is excluded through GOPRIVATE / GONOSUMDB or GOSUMDB=off is set.
• The vcpkg evaluation assumes that the package manager and its bundled hashes are trustworthy; the security of their update path was outside the evaluation scope.

Unknowns and Additional Investigation

• Differences in tool versions and configurations, and future updates, may change the results.
• The study did not measure actual repository-compromise rates or the probability of victimization.

13. Deployment Guidance

• Inference: Identify the verification features implemented by the product and version in use, and enforce them in CI using hashes or signing keys obtained through a trusted path. A uniform configuration procedure cannot be applied to products without lockfiles or without implemented signature verification.
• Maintain upstream metadata even in internal mirrors and alert on verification failures.
• Re-run tamper regression tests when updating package managers.

Evidence Needed for Verification

• Inference: Preserve CI logs, lockfile diffs, hash-mismatch and signature-verification results, download URLs, and cache provenance. Use them to confirm that verification ran and that a mismatch stopped processing.

14. Facts, Inference, and Hypothesis

Facts

• Evaluated 25 popular package managers using a malicious repository simulation.
• Inserted malicious code into repository responses using a Docker and mitmproxy harness to check for detection.
• Under these test conditions, Go and vcpkg verified the integrity of every package downloaded by default.
• Bun, Bundler, Cargo, npm, pnpm, Poetry, SwiftPM, uv, and Yarn verified integrity when lockfiles were present.
• Conda, Gradle, Pip, NuGet, and Pub required additional steps beyond lockfiles.
• CocoaPods, Composer, Conan, cpanminus, Gem, Maven, PowerShellGet, PSResourceGet, and R either did not verify via lockfile or were out of scope.
• In the study, only Go verified signatures by default; most required configuration, had incomplete implementations, or provided no signatures.

Inference

• Organizations should empirically test whether hash and signature verification fail-closed in CI, rather than relying on the presence of lockfiles.
• Repository compromise must be added to threat models, requiring a review of trust boundaries for mirrors, proxies, and caches.

Hypothesis

No additional hypotheses. Unconfirmed matters are listed under "Unknowns and Additional Investigation."

15. Implications for Defenders

Assuming repository compromise in addition to developer account protection means that the mere presence of HTTPS, lockfiles, hashes, and signatures is insufficient. Each ecosystem must be tested to ensure verification is actually enforced in CI.

16. Summary by Target Audience

• For SOCs: Monitor for hash mismatches, signature failures, and repository endpoint changes during dependency retrieval.
• For Administrators: Enforce the hash and signature verification supported by the products in use in CI, and confirm that mismatches stop processing.
• For Users: Developers should review lockfile management policies and verification settings for the package manager in use, taking account of whether they are developing an application or a library.