What changed
On October 14, 2026 security firm Trail of Bits published an experimental comparison of 25 source-code package managers under a simulated compromised package repository. In its tested default configurations, only Go and vcpkg verified integrity of every downloaded package. Several others verified hashes only when a suitable lockfile was present, while some required extra configuration or lacked artifact verification. The study distinguishes package integrity from package-author authenticity, and explicitly limits its findings to the tested package, version and platform per manager.
Why it matters
Teams may assume a committed lockfile or a registry signature means a malicious package server cannot change the code installed in CI. The tests show those assumptions are ecosystem- and configuration-dependent. PHP Composer's lockfile can pin a Git commit without verifying the downloaded GitHub ZIP's bytes; npm can validate signatures, but that is a separate audit command. Builders need to understand what their actual install command verifies, especially when dependency installation occurs inside privileged CI jobs.
The attacker model is a malicious download source, not a compromised maintainer
The researcher used Docker and mitmproxy with a trusted interception certificate to simulate a repository or download host returning a modified package while keeping private signing keys outside the attacker's control. A package manager failed the integrity test when the altered package executed. This tests resistance to a compromised distribution path, not whether the legitimate package author intentionally published malicious code.
Two verified every tested download by default
The study places Go and Microsoft's vcpkg in the category that verified integrity in its default tested configuration. Bun, Bundler, Cargo, npm, pnpm, Poetry, SwiftPM, uv and Yarn verified when a suitable lockfile was present. Conda, Gradle, Pip, NuGet and Pub required additional steps with a lockfile. Composer, Conan, CocoaPods, Gem, Maven, cpanminus, PowerShellGet, PSResourceGet and R did not verify artifact integrity in the tested default path. These are results for specific test cases, not a blanket finding that every install in each ecosystem is exploitable.
Composer demonstrates why a commit reference is not a content hash
The report shows composer.lock storing a GitHub ZIP URL and source commit reference while its dist shasum is empty. The URL identifies a commit, but Composer does not recompute a Git tree hash from the downloaded ZIP to confirm the server served those bytes. A compromised download host could substitute archive contents under the same URL in this threat model. Composer and Packagist have other supply-chain protections, but this particular artifact-integrity guarantee should not be inferred from the lockfile alone.
Signatures exist more often than verification is enabled
The npm registry publishes signatures, but npm's documentation directs users to run npm audit signatures after installation to verify registry signatures and provenance attestations; npm install is not equivalent to that check. Go's module system checks downloaded hashes against go.sum or its public checksum database by default for public modules, with explicit exceptions such as GOPRIVATE and GONOSUMDB. Signature support, lockfile hashes, identity attestations and a trustworthy transparency log solve different pieces of the problem.
How far the experiment can be generalised
The researcher installed current managers, selected one package per ecosystem and ran a representative install in Ubuntu-based containers. PowerShell and CocoaPods behaviour on Ubuntu may differ from normal target platforms. The results are researcher-produced rather than independently replicated across every package/version/configuration. Treat the matrix as a prompt to test your actual install and CI settings, not as a universal ranking of languages or a claim of a newly exploited vulnerability.
Practical actions for build pipelines
Commit lockfiles where appropriate, use frozen or immutable install modes where available, review changes to dependency sources and package identities, and test whether the install process rejects a modified artifact. For npm, consider a separate npm audit signatures step and check registry trust assumptions. For Go, preserve checksum database verification where feasible. For Composer, recognise that locking versions alone does not cryptographically authenticate GitHub ZIP contents; layer source provenance and trusted publishing controls rather than claiming a single flag solves the threat.