As a tech lead deciding your org's default policy on vendoring dependencies versus resolving them dynamically from a registry, what factors should actually drive that decision, and what does each choice cost you operationally?

## The bet you are actually making The decision between vendoring dependencies and resolving them dynamically at build time is, at its core, a bet about which failure mode you're more afraid of: - an external registry being unavailable, altered, or compromised at exactly the wrong moment; - versus your own repository silently accumulating stale, unpatched, unreviewable third-party code nobody is actively watching. Both are real, and a mature policy doesn't pick one universally — it recognizes the right answer depends on constraints specific to the deployment target, the regulatory environment, and how much engineering discipline the org can sustain around whichever choice it makes. ## The case for dynamic resolution The case for leaning toward **dynamic resolution** — fetching from npm, Maven Central, PyPI, etc. at build or install time, backed by a lockfile that pins exact versions and ideally verifies checksums — is that it keeps the automated tooling ecosystem working for you almost for free. - Tools like Dependabot, Renovate, `npm audit`, Snyk, and OWASP Dependency-Check all operate by reading manifest files and matching declared package-name/version pairs against CVE databases; this only works when the dependency is declared normally, not copied and potentially renamed into your tree. - Dynamic resolution also keeps diffs meaningful — bumping a version is a one- or two-line change in a lockfile a reviewer can actually reason about, versus a vendored upgrade touching tens of thousands of lines nobody will read line-by-line. The cost is **availability risk**: your build now depends on an external service (or your org's cached mirror of it) being reachable and serving the expected artifact every single time you build. This isn't hypothetical — the 2016 **left-pad** incident took down a large swath of the JavaScript ecosystem's builds when an 11-line npm package was unpublished, and most organizations have experienced at least a brief registry outage at an inconvenient moment. ## The case for vendoring The case for vendoring is narrower but sharper: it's the right call when you have a hard requirement dynamic resolution structurally cannot satisfy. 1. **An air-gapped deployment target** (defense, some industrial control systems, some regulated finance environments) may have literally no network path to any registry at build or runtime, making vendoring — or an on-site artifact mirror populated ahead of time, functionally similar — mandatory rather than optional. 2. **A compliance or audit regime** requiring a human to have reviewed the exact bytes of every third-party component shipping in a product is much easier to satisfy when that code is checked into the repository under version control with clear history, rather than 'trust the registry serves the same artifact it served last time we looked.' 3. When you've **forked and locally patched an unmaintained library** — fixing a bug upstream refuses to merge, or maintaining it after the original project died — vendoring is close to unavoidable, since there's no upstream registry entry reflecting your patch. ## The trap most teams fall into The trap most teams fall into is treating this as an all-or-nothing organizational policy rather than a per-situation judgment call. - **Wholesale vendoring** of every dependency (some shops commit `node_modules` entirely) buys blanket hermeticity but at a cost that scales badly: every dependency, including the 95% with no special regulatory or availability requirement, now needs someone to notice its upstream CVEs manually, and every routine version bump produces a diff too large for meaningful code review, which in practice means nobody reviews it and the org loses the audit benefit vendoring was supposed to provide in the first place. - **The opposite failure** — dynamic resolution with no lockfile, no checksum verification, and no private mirror — leaves builds fully exposed to upstream unavailability or tampering with zero mitigation, its own well-documented supply-chain risk (dependency confusion and typosquatting attacks specifically exploit registries with weak verification). ## The pragmatic default The pragmatic default most well-run engineering organizations converge on is a **middle path** that gets most of vendoring's guarantees without most of its costs: a lockfile with cryptographic checksum verification (`package-lock.json` with integrity hashes, Maven with checksum verification, `Cargo.lock`) combined with a **private artifact-caching proxy** — Artifactory, Sonatype Nexus, or Verdaccio for npm — that mirrors every dependency the org has ever resolved, permanently, on infrastructure the org controls. This gives hermetic, reproducible, always-available builds (the proxy serves cached artifacts even if the public registry is down or a package is unpublished upstream) while keeping every dependency declared normally in the manifest, so automated vulnerability scanning keeps working and upgrades stay reviewable single-line diffs. True vendoring is then reserved for the short, deliberate list above — air-gapped targets, audit mandates, and locally patched forks — rather than being the default for everything, which is exactly the discipline that keeps its costs proportional to the specific guarantee it's buying.