- Trail of Bits tested 25 package managers against a simulated compromised repository. Only two checked every download for tampering.
- A lockfile that holds a hash does not always enforce it. Behavior differs by tool, and often by setting.
- Ask your teams which package managers they use, whether a hash mismatch blocks the install, and where the trusted hash comes from.
Many engineering leaders assume a lockfile pins their software supply chain. The file lists exact dependencies. So the build should match what the developer approved. New research from Trail of Bits shows this holds for some tools and not for others. The word "lockfile" covers very different promises.
What the researcher tested
A Trail of Bits researcher tested 25 popular package managers. Each faced a simulated compromised package repository. The question was simple. If the server returns a package with malicious code inside, does the tool notice?
The results were uneven. Roughly half of the tools checked lockfile hashes automatically. A hash is a fingerprint of a file. Others needed extra setup, used weak hashes, or had no hashes at all.
Full protection was rare. Just two of the 25 confirmed that each package they fetched was unaltered. Signatures did no better. Only Go verified them by default.
How the test worked, and its limits
The researcher built a test rig from Docker containers and mitmproxy. Mitmproxy is a tool that sits in the middle of network traffic. It rewrote the repository's replies to slip in malware. Private signing keys were assumed to stay safe. If the sample code ran the malware, the attack counted as a success.
The researcher names the limits. Each test used one package, one tool version and one platform. Some tools, such as PowerShell and CocoaPods, ran on Ubuntu. That may not match common use.
The point is not that every developer is exposed. It is that a developer following reasonable conventions can be.
A hash in the file is not a hash that is enforced
The safe pattern is simple. The lockfile stores a fingerprint. The tool recomputes it after download. A tampered package then fails the check. Bun, npm, Yarn, Cargo, Bundler and uv work this way.
The researcher also singles out vcpkg. It keeps its hashes in its own source code. That is fully secure against a malicious repository, as long as vcpkg itself is trusted.
Other tools hold a hash but use it differently. The researcher documents several cases.
Dart's Pub spots a mismatch but installs the package anyway. Blocking needs the non-default --enforce-lockfile option.
pnpm overwrote the lockfile after a mismatch by default. That lasted until version 11.4 in May 2026. The release closed what the project called "supply-chain holes."
Conan's lockfile uses an MD5 hash as an identifier. Conan does not recompute it on install. MD5 is not meant to give cryptographic security.
CocoaPods stores a hash of a file that points to a GitHub repository. A compromised GitHub server could serve a malicious version under the same tag.
Composer's lockfile holds a commit hash. But its ZIP download is not checked against it. GitHub could serve a malicious archive without Composer noticing.
One more case stands out. The Perl tool cpanminus uses plain, unencrypted HTTP by default. Any active attacker on the network path could inject code. The problem has been known for years. The developer has not fixed it because the change would break existing behavior.
The gap: a convenience feature became a security control
The lesson here is that lockfiles were built to make builds repeatable. They were not built to resist a hostile server. The researcher calls the security view a recent interpretation that can clash with the original design.
Security teams have adopted the file as a control. Tool makers may still treat it as a convenience.
That mismatch is where risk hides. A policy that says "we use lockfiles" can be true in every team and still protect nothing in some of them.
There is also a trade-off. Pinning exact hashes means teams miss new releases and security fixes automatically. A newer package has a different hash. The researcher notes this forces frequent lockfile updates. Integrity and fast patching pull in different directions.
What leaders should ask
First, ask for an inventory of the package managers in use. Include the less visible ones for mobile, data and infrastructure code.
Second, ask of each one: does a hash mismatch block the install, or only warn? Third, ask where the trusted hash comes from. Is it committed to version control?
Fourth, look for plain HTTP. Also look for tools that need a non-default flag to enforce integrity. Build pipelines can set those flags once.
Finally, ask how fast your team can update lockfiles when a fix ships.
A repository you do not control is a dependency you have to verify. Some tools do that for you. Others leave it to you.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: Trail of Bits.
