Build vs Pull Dependencies

Build dependencies internally or pull from upstream.

Pull (default)

Every modern application depends on third-party code. The decision is whether to pull those dependencies as pre-built artifacts from the upstream registry, or to build them yourself from source. The two approaches trade off different things: convenience versus control, speed versus risk, simplicity versus security depth. Most teams default to pulling; some need to build; the right answer depends on the workload's risk profile.

What pulling pre-built dependencies looks like:

• Faster builds.: Pulling a pre-built artifact is faster than building from source. npm install, pip install, docker pull all download artifacts that someone else built. The team's build pipeline is shorter; the iteration loop is faster.
• Less maintenance overhead.: The team does not maintain build infrastructure for upstream dependencies. If the dependency releases a new version, the team updates the version pin and pulls the new build. The upstream maintainer handles the build process.
• Risk: upstream changes can break.: A breaking change in an upstream dependency lands in your build the next time you pull. If you do not pin versions strictly, the change can land without notice. Even with strict pinning, an explicit upgrade can break unexpectedly.
• Risk: supply-chain compromise.: The pre-built artifact is whatever the registry hosts. If the registry has been compromised (rare but real), the artifact you pull is malicious. SBOMs and signature verification reduce this risk; they do not eliminate it.
• Pin to specific versions or hashes.: The minimum discipline for pulling: pin to specific versions, ideally with hash verification (npm package-lock.json hashes; pip requirements.txt with --hash). Pulling "latest" produces unreproducible builds and inherent supply-chain risk.

Pulling is the default for most teams because the convenience benefit is real and the risks are manageable with reasonable discipline. The security investment is in pinning, scanning, and SBOM tracking rather than in building from source.

Build internally

Building dependencies internally trades convenience for control. The team operates the build process themselves; they know exactly what is in the artifact; they can apply patches that have not been merged upstream; they bear the operational cost.

• Slower iteration.: Building from source is slower than pulling pre-built. The team's build pipeline includes the full dependency build chain. Initial builds can take hours; cached builds are faster but still slower than pulling.
• More maintenance.: The team owns the build process for the dependencies. When the dependency's build system changes, the team adapts. When the dependency adds new transitive dependencies, the team handles those too. The maintenance cost is real and ongoing.
• Control over what ships.: The team can patch security issues before upstream merges them. The team can disable optional features they do not want. The team can verify the source code matches what they expect. Control over the artifact is the main reason teams build internally.
• Defends against supply-chain attacks.: A compromised upstream registry serves a malicious artifact. A team building from source compiles from source code they reviewed. The supply-chain attack vector is reduced (though not eliminated; the source repository can also be compromised).
• Required for some workloads.: Air-gapped environments. Regulated industries with strict provenance requirements. High-security workloads where the cost of supply-chain compromise outweighs the cost of internal building. For these, building internally is necessary, not optional.

Internal building is the right choice for the cases where control matters more than velocity. Most workloads do not justify the cost; some require it.

Hybrid

Most mature teams converge on a hybrid model: pull most dependencies, build the security-critical or operationally-significant ones. The hybrid captures convenience for the common case and control for the cases that need it.

• Pull most dependencies.: The vast majority of dependencies (utility libraries, build tools, framework dependencies) are pulled as pre-built artifacts. The convenience benefit applies; the risk is bounded by SBOM scanning and pinning.
• Build security-critical dependencies.: Cryptographic libraries, authentication libraries, anything that handles secrets, network parsing libraries that handle external input. These warrant the additional control because their compromise has high impact.
• Build unstable dependencies.: Some upstream projects have flaky build systems, frequent breaking changes, or unmaintained release processes. Building these internally insulates the team from upstream chaos.
• Most teams converge here.: The hybrid is the natural endpoint. Teams that started pulling everything add internal builds for the cases that bit them. Teams that started building everything relax to pulling for the cases where the cost is not justified. Both directions converge to a similar middle.
• Document the choice per dependency.: The decision (pull vs build) is documented per dependency in the build manifest. The rationale is captured. Future decisions are informed by the existing classifications; the team is not re-litigating the choice every time.

Build versus pull is a per-dependency decision, not a per-team one. Nova AI Ops integrates with build manifests, surfaces the dependency tree by classification (pulled vs built), and tracks supply-chain risk per dependency so the classification decisions remain calibrated to the threat profile.