Research & Tools · Supply Chain
Trail of Bits tested 25 popular package managers and found that fewer than half use tamper-checking lockfiles by default, while only two verified every package they downloaded. The audit looked at what happens if a package repository serves altered code inside an otherwise legitimate package.
In plain terms, some managers record a package hash or signature in a lockfile but do not automatically compare it to the downloaded file unless extra verification is turned on. Others use hashes weakly, skip signature checks, or do not support them at all, so a modified package can reach the build as if it were clean.
The practical effect is that repository-side tampering can slip past the “clean lockfile” assumption many teams rely on. If your build pipeline depends on default package-manager behavior, the trust boundary sits weaker than it looks, and a compromised repository can become the next path attackers try.
1 source · 7h ago
Trail of Bits
Package managers have an integrity problem
Only two verified the integrity of every package they downloaded.
originalPart of the PlainSec briefing for 2026-10-14
Every edition of this story: Package managers leave repository tampering too much trust