When is vendoring a fork of a third-party build step into an internal repository worth its upgrade debt?

## What vendoring means here Vendoring a third-party build step means copying its source into a repository you control at a revision you have reviewed, and pointing every consumer at the internal copy instead of the upstream one. It sits at one end of a spectrum: use upstream by tag, use upstream by digest, mirror upstream byte-for-byte internally, fork and patch internally, or rewrite it yourself. The crucial framing is that digest pinning already delivers the benefit people usually give as the reason to vendor. With a pin, no upstream change reaches your builds until a human bumps the reference. If the argument for vendoring is *so upstream cannot change under us*, the answer is that a pin does that for free. ## What vendoring adds that a pin does not **You can modify the code.** This is the strongest reason. You can delete the run-time download and vendor its payload too, remove a telemetry call, pin the step's own transitive dependencies, or cut the surface down to the one path you use. None of that is possible with an upstream pin. **Durability.** A pinned upstream reference is only as available as upstream. A deleted repository, a renamed organisation, a namespace that someone else re-registers - each turns a green pipeline into a broken or, worse, a silently redirected one. If the pipeline is on a release path where an outage is expensive, that availability argument stands on its own, independent of any attacker. **One choke point.** When something needs fixing in that step, an internal copy is a single place to fix it and a single reference to bump. With upstream pins spread across hundreds of repositories, you either wait for upstream or run a large migration under time pressure. **Enforceability.** An internal path is easy to require and easy to detect the absence of. It makes *someone quietly added the upstream reference back* visible. ## What it costs, every release, forever - **Diff review.** Each upstream release has to be read and merged, and the local patches re-applied. That is a standing obligation on somebody's week. - **Vulnerability response moves to you.** When a flaw is reported in that code, upstream's fix does not reach your consumers by itself; someone here has to notice, port and ship it. - **Drift.** Forks diverge. Once the local copy is several releases behind with three local patches, merging becomes a project rather than a review, and the usual outcome is that it stops happening. - **An owner.** Every one of the above needs a name, not a team mailbox. Ownership decay is the normal failure mode, and the end state - old unreviewed code running in your highest-privilege jobs - is precisely the risk vendoring was supposed to remove. ## Deciding Vendor when several of these hold at once: the step runs in a job whose compromise is catastrophic; it is referenced by a large part of the estate, so a mass bump would be slow; you need to change its behaviour, most often to remove a run-time fetch; upstream is thin or unresponsive; and you can name the person who owns the copy. Pin when the step is small, its upstream is healthy, you would not modify it, and it runs somewhere with little to reach. That is the majority of steps, and treating it as the default is what keeps the vendored set small enough to maintain. ## The middle path most estates should take Mirror without forking. Copy upstream byte-for-byte into the internal repository, apply no local patches, and record the upstream revision. You get durability, the choke point and enforceability, while upgrades stay a fast-forward with a diff to read rather than a merge to resolve. Reserve real forks for the handful of steps you genuinely had to change, and write down why each patch exists so the next owner knows whether it can be dropped. Whichever you choose, make the state visible: which internal steps exist, at what upstream revision, who owns each, when it was last reviewed, and how far behind it is. A dashboard of *distance from upstream* is what turns vendoring from a decision into an operable programme - and if that dashboard would be red across the board, the honest conclusion is that the organisation cannot afford to vendor and should pin instead. ## A note on the sales pitch Vendoring is often proposed as a security control and bought as one. It is better understood as taking ownership: you are moving code into your maintenance perimeter, and you get to decide what it does at the price of having to keep deciding. Teams that make that trade knowingly, for a handful of steps, do well. Teams that make it broadly to satisfy an audit finding end up with an internal catalogue nobody upgrades.