Dependency Vendoring

Vendoring means committing the full source of your dependencies into your own repository instead of fetching them by name and version at build time. The build reads its dependencies from a directory you control and have already reviewed, not from a network location that can change between builds.

The reuse-less-software argument frames this as a defense against supply-chain attacks. A package manager that auto-fetches dependencies on every build is also an auto-propagation channel: when an upstream package is compromised, everyone who depends on it pulls the poisoned version the next time CI runs, and it "spreads like wildfire, as fast as CI runners can execute it." Vendoring cuts that channel. A compromised upstream release doesn't reach you until you deliberately copy the new source in, review it, and commit it. Every vendored package becomes a fire-break — the attack stops at the boundary of each repo that hasn't chosen to pull the update.

The same boundary blocks bug fixes and security patches from propagating automatically, which the argument accepts on the grounds that if a fix matters you'll go looking for it, and if you aren't looking, it usually doesn't matter. This is the same tradeoff dependency cooldowns make, taken to its limit: cooldowns delay auto-updates by a few days; vendoring stops them entirely until a human acts.

Second-order effect: visibility

Vendoring raises the visible cost of a dependency. A "200-line library" that turns out to be 50,000 lines of committed source is obvious once it's sitting in your tree, in a way it never is behind a one-line manifest entry. The claim is that this gentle friction pushes toward flatter, narrower dependency trees — the source hopes to cut typical dependency counts "from 200-300" down to "at most 2-3" — because each addition now costs a visible amount of reviewed, committed code.

Downsides

No automatic transitive deduplication. If library A and library B both vendor library Z, you have two copies and deduping them is manual work rather than something the resolver does for you. Repo size grows, though the source argues disk is cheap and build times don't change because you were compiling that code anyway.

Endpoint: Nix/Guix

Taken all the way, vendoring becomes a fully specified build environment where every input is pinned and content-addressed — which is what Nix and Guix already do. The source endorses that as the logical destination: treating the "build environment" as something to specify completely rather than assume. Pinning every input is also what makes builds reproducible, so vendoring and reproducibility push toward the same place.

Related

• reuse-less-software — the source argument for this page
• supply-chain-security — the attack class vendoring defends against
• open-source-security-astral — dependency cooldowns as the softer version of the same idea
• reproducible-builds — pinning all inputs is the shared foundation
• manylinux — the wheel-building side of shipping self-contained binary artifacts