Package Management

TL;DR

• An artifact repository (Nexus, JFrog Artifactory) is the control point for dependency reliability, security scanning, and build traceability — not just a build-speed cache.
• Proxying/caching public registries (npm, Maven Central, PyPI) means a public outage or a yanked package doesn’t block builds, and gives one place to scan/block malicious dependencies.
• Virtual/grouped repositories unify a local repo, a public proxy, and internal shared repos behind one endpoint so developers configure a single registry URL.
• Retention policies are required to keep artifact storage cost bounded — keeping every build forever is not viable at scale.
• Build metadata/traceability (which dependency versions went into which artifact) is what turns a CVE investigation into a query instead of log archaeology.
• OS-level package managers (apt, yum/dnf, apk) solve a related but distinct problem: system package installation and dependency resolution on a host or in a container image, with real behavioral differences that affect image size and build reproducibility.

Core Concepts

Artifact repositories: Nexus and Artifactory

Nexus Repository and JFrog Artifactory are the two dominant platforms, both supporting every major package ecosystem (npm, Maven, PyPI, Docker/OCI images, generic files) through a unified server. Both provide three repository types: hosted (internally-built artifacts), proxy (a cached passthrough to a public registry), and virtual/group (an aggregation of other repositories behind one endpoint). Proxying public registries rather than pulling directly from the public internet accomplishes two things simultaneously: already-cached packages remain available if the public source has an outage or a package is yanked/unpublished, and every dependency — internal or external — flows through one point where security scanning and blocking policy can be applied.

Virtual/grouped repositories

A virtual repository (Artifactory’s term) or group repository (Nexus’s term) combines a local hosted repository, a proxy to a public registry, and potentially another team’s shared internal repository behind a single URL. A client running npm install or mvn install points at one endpoint; the repository resolves each requested package from whichever underlying member actually has it, in a configured resolution order. This removes the need for developers to know or manually configure multiple separate registry sources per package origin.

Retention policies

Every CI build that produces an artifact, if kept indefinitely, becomes an unbounded storage cost. Retention policies define explicit rules instead of manual, ad-hoc cleanup: keep the last N builds per branch, retain release-tagged builds for a compliance-mandated window (or indefinitely), and aggressively clean up ephemeral feature-branch or per-commit builds once they’re merged or abandoned. The policy differentiates by artifact classification (release vs. snapshot/ephemeral) rather than applying a single blanket age or count limit.

Build metadata and traceability

When a CVE is disclosed against a specific dependency version, the operational question is which deployed artifacts actually included that vulnerable version and when they were deployed. This requires the repository to reliably capture build metadata — the exact dependency versions resolved into each build — combined with immutable versioning, meaning an artifact reference (e.g. a specific version or digest) cannot silently change content after publication. Together these make the question answerable via a direct query. Without reliable metadata, the same investigation requires reconstructing dependency graphs from CI logs that may no longer exist.

OS package managers: apt, yum/dnf, apk

Distribution package managers resolve and install system-level packages and their dependencies. They differ in package format, dependency resolution approach, and default footprint — all of which matter directly for container image size and build reproducibility (see comparison table below). Key mechanisms shared across all of them: a local package index/cache that must be refreshed before install (apt update, dnf makecache), dependency graph resolution to pull in required libraries automatically, and a package database on disk tracking installed files for clean removal.

apt vs yum/dnf vs apk

Command / Configuration Reference

# Nexus/Artifactory-style repository usage (npm example)
npm config set registry https://artifactory.example.com/api/npm/npm-virtual/   # point at virtual repo
npm install                                                                     # resolves through hosted/proxy/group chain

# apt (Debian/Ubuntu)
apt update && apt install -y curl && rm -rf /var/lib/apt/lists/*   # refresh index, install, clean cache in one layer

# dnf/yum (RHEL/Fedora family)
dnf install -y curl && dnf clean all                                # install, then clean cache to reduce image size

# apk (Alpine)
apk add --no-cache curl                                             # install without persisting the package index cache

Common Pitfalls

• Pitfall: CI builds pulling dependencies directly from public registries with no internal proxy. Why: A public registry outage or a yanked upstream package blocks every team’s builds simultaneously, and no scanning checkpoint exists before packages reach the pipeline. Fix: Route all builds through a proxy/cache repository (Nexus or Artifactory) that fronts the public registry.
• Pitfall: No retention policy configured on the artifact repository. Why: Every build producing a uniquely-versioned or uniquely-tagged artifact accumulates indefinitely, turning into an unplanned storage cost line item. Fix: Define retention rules that differentiate release-tagged artifacts (retained per compliance need) from ephemeral builds (cleaned up aggressively).
• Pitfall: Build metadata and dependency versions not captured or retained. Why: Without it, a CVE disclosure forces manual reconstruction of what was actually deployed from CI logs that may no longer exist. Fix: Ensure the repository captures dependency resolution metadata per build and uses immutable versioning so historical builds remain queryable.
• Pitfall: Not cleaning package manager caches inside container image layers (apt-get clean, dnf clean all, relying on apk --no-cache). Why: Package indices and cached .deb/.rpm files persist in the image layer even after the package is installed, bloating image size. Fix: Clean caches in the same RUN layer as the install, or use --no-cache where the package manager supports it.
• Pitfall: Assuming a binary built against glibc will run unmodified on Alpine. Why: Alpine uses musl libc, not glibc, and prebuilt binaries linked against glibc can fail or behave subtly differently. Fix: Use glibc-compatible base images or musl-native builds when Alpine is the target.

Interview Questions

• Why should builds pull dependencies through a private artifact repository instead of directly from public registries? — Tests whether both the reliability and security-scanning benefits are articulated, not just one.
• A new critical CVE was just disclosed for a widely-used dependency. Walk through how you’d find every affected deployed artifact. — Tests whether build metadata and traceability are treated as a pre-built capability, not an afterthought.
• Design a retention policy that balances a multi-year compliance requirement against storage cost. — Tests whether the candidate reasons about differentiated retention (release vs. ephemeral builds) rather than a single blanket rule.
• Why does an Alpine-based Docker image sometimes break a binary that runs fine on a Debian-based image? — Tests understanding of musl vs. glibc as a real compatibility boundary, not just “Alpine is smaller.”
• What’s the difference between a hosted, proxy, and virtual repository in Nexus/Artifactory? — Tests whether the three repository types and their composition are understood precisely.