# Trail of Bits tests 25 package managers: most do not verify every download by default A controlled malicious-repository experiment across 25 dependency managers finds only Go and vcpkg protected every tested download by default. The practical surprise: a committed lockfile, a package signature and a verified artifact are three different guarantees. An October 14 study tests package-manager integrity against a malicious registry. Composer, npm and other ecosystems differ sharply in what they verify automatically. - Status: Active - Published: 2026-10-15T17:32:38+13:00 - Updated: 2026-10-15T17:32:38+13:00 - Categories: Web Development, PHP, JavaScript, Developer Tools - Tags: Composer, dependency management, npm, package management, supply chain security - Canonical HTML: https://beyondthe.news/dossiers/trail-of-bits-25-package-managers-artifact-integrity-defaults-2026 ## 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. ## Key details - Published October 14, 2026 by Trail of Bits researcher Keegan Ryan. - 25 source dependency managers tested with a simulated malicious package repository. - Only Go and vcpkg verified every tested downloaded package by default in the author's test matrix. - Nine managers verified integrity when a suitable lockfile was present; five required additional lockfile-related configuration. - Composer's GitHub dist ZIP URL can reference a Git commit without checking the downloaded archive against that commit. - npm signature and provenance checks are available through npm audit signatures, separate from ordinary npm install. - Study used one package/version/platform per manager; it is not a proof that all installations are compromised. ## Builder takeaways - Do not assume a lockfile automatically authenticates downloaded bytes; verify the guarantee for your specific package manager and install mode. - In CI, make lockfiles reviewable and use strict/frozen install options where supported. - For npm, evaluate npm audit signatures as an explicit verification stage and understand what it checks. - For PHP Composer, recognise the gap between pinning a Git reference and validating the contents of a fetched ZIP. - Avoid treating registry signatures or publisher identity as substitutes for artifact integrity and dependency review. - Assess exceptions such as private registries and checksum database opt-outs before relying on defaults. ## What to watch - Maintainer responses and independently reproduced tests for the 25 managers. - Composer/Packagist artifact-integrity work and any future checksum/signature verification defaults. - Wider adoption of Sigstore identity attestations and transparency-log checks at install time. - Changes to default verification in Pub, pnpm, npm and NuGet after this study. ## Uncertainties - The study's single-package Ubuntu-based tests do not represent every version, platform or enterprise configuration. - The researcher controlled the simulated repository and TLS interception environment; this is not evidence of an actual registry breach. - The study was not independently replicated across the complete 25-manager matrix. - Some ecosystems support stronger optional modes than the defaults tested. ## Sources - [Package managers have an integrity problem](https://blog.trailofbits.com/2026/10/14/package-managers-have-an-integrity-problem/) — Trail of Bits · primary · 2026-10-14T00:00:00+13:00. Original experimental methodology, tables, threat model, Composer example and caveats. - [Verifying ECDSA registry signatures](https://docs.npmjs.com/verifying-registry-signatures/) — npm Docs · primary. Official npm audit signatures verification workflow, supporting the distinction from ordinary install. - [Go Modules Reference](https://go.dev/ref/mod) — Go Project · primary. Official module checksum database and opt-out documentation. - [Composer documentation](https://getcomposer.org/doc/) — Composer · primary. Canonical Composer package management reference; report's specific ZIP-integrity finding is from the researcher's tests.