Trail of Bits tests 25 package managers: only Go and vcpkg verify every package

Trail of Bits security researcher Keegan Ryan published a 25-package-manager audit on October 14, 2026 that puts hard numbers on a known supply-chain hole: with a compromised package repository or MITM-capable proxy in front of it, fewer than half of the 25 managers tested verify lockfile integrity by default, and only two — Go and vcpkg — verify every package they download. For blockchain tooling that runs on npm (Hardhat, Foundry front-ends, wallet SDKs), Cargo (Solana programs, substrate chains, zkVMs), pip (Vyper, slither, mythril) and Go (geth, erigon, cosmos-sdk), this is the single most citable baseline on how exposed each toolchain is right now.

What the test does

Ryan constructs a reproducible threat model: an attacker controls the web-facing package repository or a proxy in front of it and can rewrite plaintext HTTP(S) responses. Signing keys and server-side build infrastructure remain intact. For each of the 25 managers, Ryan runs the install flow through a Docker container with mitmproxy and a custom addon that injects a modified package. The test checks whether the manager detects the tampering.

The attack family is not hypothetical. It is the same shape as the Lazarus-run npm-package compromises that have hit Web3 teams repeatedly through 2025 and 2026, as the ongoing PyPI typosquats targeting Solana and Ethereum developers, and as any attack that defeats repository TLS or runs between a build server and the registry CDN.

The 25 managers

Bun, Bundler, Cargo, CocoaPods, Composer, Conan, Conda, cpanminus, Gem, Go, Gradle, Maven, npm, NuGet, Pip, Poetry, Pub, PowerShellGet, PSResourceGet, pnpm, R, SwiftPM, uv, vcpkg, Yarn.

Headline results

• Verify integrity by default: 11 of 25 (Go, vcpkg outright; Bun, Bundler, Cargo, npm, pnpm, Poetry, SwiftPM, uv, Yarn only when a lockfile is present).
• Verify every package by default: 2 of 25 — Go and vcpkg.
• Verify signatures by default: 1 of 25 — Go.
• Default to HTTPS: 24 of 25. The lone holdout is cpanminus, which fetches over plain HTTP, so Ryan assumes an active network attacker for that manager alone.
• Hash-based lockfiles that catch tampering: inconsistent. Several managers write hashes but do not re-check them on every install step.

Why "lockfile present" matters

Nine of the 11 defaults-verifying managers only check integrity when the project already has a lockfile. In practice:

• First install on a new checkout without a lockfile — most Node, Rust, and Python workflows at some point — reaches the registry with no hash to compare against. That first install is the attacker's window.
• CI pipelines that run npm install instead of npm ci fall into the same hole, since npm install can accept server-side changes to the resolved tree.
• Developer --force or --no-lockfile flows, common in monorepos, bypass the check entirely.

Blockchain-tooling implications

Ryan's post does not call out crypto packages by name — its "cryptography" references are about signing and hashing. But the mapping to blockchain stacks is direct:

• npm / pnpm / Yarn: Verify only with lockfile. Hardhat, Foundry's TypeScript bindings, Ethers, Wagmi, Viem, and most wallet SDKs ship via npm. CI pipelines in Web3 orgs rely on npm ci with pinned hashes to close this gap — the audit confirms that is in fact necessary, not optional.
• Cargo: Same pattern. Solana program development, substrate chains, zkEVM/zkVM crates (RISC Zero, SP1, Jolt), and MEV search tooling all live here. A missing lockfile in a Cargo workspace is a real risk.
• pip / uv / Poetry: Verify only with lockfile. Vyper, slither, mythril, Brownie-era holdouts, and most Python-side auditing tools fit here. pip install without --require-hashes and a hash-pinned requirements file is unverified.
• Go: Verifies by default, every package, with signature checks. Geth, erigon, cosmos-sdk, polygon-cdk, prysm — the Go-side consensus-client and L1 ecosystems get the strongest default of any ecosystem tested.
• vcpkg: Verifies by default. Relevant for C++ node implementations (Bitcoin Core, Zcash) that pull dependencies through vcpkg on Windows and Linux.

Numbers block

• Managers tested: 25.
• Default-verifying integrity: 11 (always 2, lockfile-conditional 9).
• Default-verifying every package: 2 (Go, vcpkg).
• Default-verifying signatures: 1 (Go).
• Default HTTPS: 24.
• Report date: October 14, 2026.
• Reference study on lockfile design: Gamage et al., arXiv:2505.04834.

What a crypto team should do today

1. Commit a lockfile for every repo, no exceptions, and gate CI on it (npm ci, cargo install --locked, uv sync --frozen, pip install --require-hashes).
2. Pin registry proxies and verify TLS pinning on build hosts; the audit's threat model assumes the proxy is the attacker.
3. Prefer Go-shaped defaults where you have the choice — Go modules verify by default, including signatures, which is why the Go-side of client development has had materially fewer supply-chain incidents than npm or pip.
4. For audit-adjacent tooling (slither, mythril, Foundry forge-std forks), check your dependency tree with cargo audit, npm audit --production, pip-audit, or osv-scanner on every CI run.

Pattern

Ryan's audit is the second major Trail of Bits release this year on cryptographic infrastructure hygiene after the SequenceHash / C2SP multihashing work. Both land on the same point: the default behavior of widely deployed tooling is weaker than practitioners assume, and the gap only closes with explicit configuration. Expect the 25-manager table to show up in Web3 security-engineering RFCs and in the next round of OpenZeppelin and audit-firm reviews of DeFi protocols as a cited baseline.