Research / Lockfile injection
The lockfile blind spot.
My 2019 research into malicious dependency sources hidden in npm and Yarn lockfiles, and the defenses and follow-on research it led to.
A dependency change hiding in plain sight
In September 2019, I demonstrated how a pull request could redirect a dependency to attacker-controlled code through a lockfile. The package name and version could look familiar while its download source changed beneath the reviewer’s attention.
Large, generated diffs make this kind of change difficult to spot. The research examined how npm and Yarn treat lockfile entries as installation instructions, and why reviewing package.json alone does not establish the trustworthiness of an install.
Turning the finding into a defense
I built lockfile-lint to make dependency-source checks repeatable in development and CI. It lets teams enforce policies such as HTTPS and approved registry hosts, so suspicious sources can be flagged automatically.
The tool addresses a particular trust boundary in dependency installation. It complements package review and vulnerability scanning; an allowed registry alone cannot guarantee that a package is safe.
From the original finding to Black Hat
GitLab researchers Dennis Appelt and Greg Johnson extended this work for “Picking Lockfiles: Attacking and Defending Your Supply Chain” at Black Hat Europe 2021. Their published notes explicitly credit my initial research.
They explored additional tampering techniques and extended the analysis to Ruby and Go, alongside Node.js. Their work also introduced defensive verification and tooling to automate lockfile tampering for security testing.