Quản lý Artifact (Artifact Management)Artifact Management

Part of the DevOps Roadmap knowledge base.

Overview

An artifact is any file produced by your build process that you deploy, distribute, or depend on: compiled binaries, language packages (JARs, wheels, npm tarballs), container images, Helm charts, OS packages (deb/rpm), and even machine-learning models. Artifact management is the discipline of storing, versioning, securing, and distributing these outputs through dedicated repositories rather than ad-hoc file shares or rebuilding from source every time.

In a healthy CI/CD pipeline, an artifact is built exactly once, given an immutable identity, and then promoted through environments (dev → staging → prod) unchanged. This “build once, deploy many” principle is what makes deployments reproducible and rollbacks trivial. Without an artifact repository, teams end up rebuilding per environment — which means the thing you tested is not literally the thing you shipped.

Artifact management has also become a security front line. Supply-chain attacks (dependency confusion, typosquatting, compromised registries) target exactly this layer, which is why modern practice adds provenance, signing (Sigstore/cosign), and SBOMs on top of plain storage.

Why a dedicated repository, and not just Git or a file share

A natural question is “why not commit artifacts to Git, or drop them on shared storage?” Three reasons make purpose-built repositories the standard:

1. Binaries break version control. Git is built for diffable text; large binary blobs bloat history irreversibly and make clones painfully slow. Artifact repositories store binaries efficiently with deduplication.
2. Protocol awareness. A real repository speaks the native protocols — Maven, npm, PyPI, NuGet, OCI/Docker Registry v2 — so your existing tools (mvn, npm, pip, docker pull) work unchanged by just pointing at a different URL.
3. Metadata, search, and policy. Repositories track who published what, when, from which build, attach checksums and signatures, enforce retention, and answer “which artifacts contain log4j 2.14?” — none of which a file share can do.

The mental model: your artifact repository is the boundary between “code” and “running system.” Source flows in from Git, gets built into an immutable artifact, and every deployment pulls from the repository. If the repository is trustworthy and its contents are immutable and signed, you can reason about what is running in production. If it’s a free-for-all, you cannot.

Fundamentals

What counts as an artifact

A useful realization: OCI has quietly become the universal artifact format. Originally the container-image spec, the OCI registry now stores Helm charts, WASM modules, SBOMs, signatures, and arbitrary files as “OCI artifacts.” Increasingly, “push it to the registry as an OCI artifact” is the answer for anything that needs content-addressable, immutable, distributable storage — not just container images.

Roles of an artifact repository

1. Local/hosted repositories — store artifacts you build (private packages, internal images). This is your source of truth for first-party artifacts.
2. Proxy/remote repositories — cache upstream public registries (Maven Central, npmjs, Docker Hub, PyPI). Builds keep working when upstream is down or rate-limited, downloads are faster (cached locally) and auditable, and you gain a chokepoint to scan and block malicious packages before they reach developers.
3. Virtual/group repositories — a single URL aggregating hosted + proxy repos, so build tools need only one endpoint. Resolution order matters: typically internal-hosted is searched before public-proxy so an attacker can’t shadow an internal package name (see dependency confusion below).

Major artifact repository managers

Choosing between them, briefly: deep in a single cloud → the native registry (ECR/ACR/GAR) is the path of least resistance. On GitHub/GitLab → the bundled registry saves setup. Need one place for 20 formats with enterprise policy → Artifactory or Nexus. Want a self-hosted, security-focused container registry → Harbor.

Where artifacts fit in the pipeline

Promotion is metadata movement (retag, copy between repos), never a rebuild. Configuration is injected at deploy time (env vars, config maps, secrets) so the same immutable artifact behaves correctly in each environment. If you find yourself passing environment-specific values into the build, you’ve broken build-once-deploy-many and can no longer trust that staging tested what production runs.

Key Concepts

Versioning strategies

• Semantic Versioning (SemVer) — MAJOR.MINOR.PATCH (e.g., 2.5.1): increment MAJOR for breaking changes, MINOR for backward-compatible features, PATCH for backward-compatible bugfixes. The lingua franca for libraries and packages; consumers use ranges (^2.5.0) to opt into safe updates automatically.
• Pre-release and build metadata — 1.3.0-rc.1, 1.3.0-beta.2, 1.3.0+build.2025. Pre-release tags sort before the release (1.3.0-rc.1 < 1.3.0); build metadata after + is ignored for precedence but useful for traceability.
• Snapshot vs release — Maven’s 1.2.0-SNAPSHOT is mutable and for development only (the same version can be re-published with new content); releases are immutable and must never be overwritten. Keep them in separate repositories with different overwrite policies.
• Calendar versioning (CalVer) — 2026.07.1 or 26.07; good for products released on a cadence (Ubuntu, many SaaS tools) where “breaking vs non-breaking” is less meaningful than “when.”
• Immutable tags for containers — a moving tag like latest or 1.4 is convenient for humans but dangerous for deployments because its meaning changes over time. Deploy by a unique, traceable tag and pin the content digest:

# Build with an immutable, traceable tag
docker build -t registry.example.com/team/api:1.4.2-gitsha.9f8e7d6 .
docker push registry.example.com/team/api:1.4.2-gitsha.9f8e7d6

# Deploy pinned to the content digest (cannot be silently changed)
image: registry.example.com/team/api@sha256:3b1a9c...e2f

The tag vs digest distinction is fundamental. A tag is a mutable pointer — 1.4 can be repointed to new content tomorrow. A digest (sha256:…) is the content address — it is derived from the bytes themselves, so pinning to a digest guarantees you run byte-for-byte what you tested. Use human-readable tags for discovery and digests for the actual deploy manifest. Enabling tag immutability on the registry (ECR, ACR, Harbor, GAR all support it) prevents anyone from re-pushing over an existing tag, closing the gap between the two.

Retention policies

Registries grow without bound unless you prune; storage cost and attack surface both scale with hoarded artifacts. Typical policy dimensions:

• Keep the last N versions per package/image.
• Delete untagged/dangling manifests (orphaned layers from overwritten tags) after X days.
• Expire snapshot/pre-release builds after X days; keep releases longer or indefinitely.
• Never auto-delete anything currently deployed to production or flagged for compliance/legal retention — this is the rule that turns a retention policy from helpful to catastrophic if omitted.

// AWS ECR lifecycle policy: keep only the 30 most recent images
{
  "rules": [{
    "rulePriority": 1,
    "description": "Keep last 30 images",
    "selection": {
      "tagStatus": "any",
      "countType": "imageCountMoreThan",
      "countNumber": 30
    },
    "action": { "type": "expire" }
  }]
}

A more realistic policy uses multiple rules by tag prefix: aggressively expire pr-* and snapshot-* images after a few days, keep release-* / semver-tagged images for months, and exempt anything referenced by a running deployment. The safest architectures make retention aware of what’s actually deployed (e.g., GitOps tools or admission controllers that mark in-use digests) so cleanup can never delete a running image.

Provenance, signing, and SBOM

This is the modern supply-chain security layer, and the three pieces answer three different questions.

Provenance — “where did this come from?” Verifiable metadata about how and where an artifact was built: source repo, commit SHA, builder identity, build parameters. The SLSA framework (Supply-chain Levels for Software Artifacts) defines increasing levels of build integrity; GitHub Actions build attestations and cloud-native build services can generate signed provenance automatically. Provenance lets a consumer verify “this image really was built by our trusted CI from commit abc123,” not slipped in by an attacker.

Signing — “is this really from us, and untampered?” Cryptographically sign artifacts so consumers can verify the publisher and that nothing changed after signing. Sigstore/cosign made this practical with keyless signing: instead of managing long-lived private keys, the signer uses a short-lived certificate bound to its OIDC identity (e.g., the exact CI workflow), recorded in a public transparency log (Rekor).

# Sign an image (keyless, in CI — identity comes from the OIDC token)
cosign sign registry.example.com/team/api@sha256:3b1a9c...e2f

# Verify before deploying — assert WHO signed it and WHICH issuer vouched for them
cosign verify \
  --certificate-identity-regexp 'https://github.com/myorg/.*' \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com \
  registry.example.com/team/api@sha256:3b1a9c...e2f

Note that you verify against a digest, not a tag — signing a mutable tag would be meaningless. The verify step asserts the identity that signed (a specific workflow) and the issuer, so a signature from some other repo won’t pass.

SBOM — “what’s inside?” A Software Bill of Materials is a machine-readable inventory (SPDX or CycloneDX format) of every component and dependency inside an artifact. When a CVE drops (Log4Shell, xz), an SBOM turns “are we affected?” from a multi-day investigation into a database query.

# Generate an SBOM from an image, then scan the SBOM for known vulnerabilities
syft registry.example.com/team/api:1.4.2 -o cyclonedx-json > sbom.json
grype sbom:sbom.json

# Attach the SBOM and vuln scan to the image as signed attestations (in-registry)
cosign attest --predicate sbom.json --type cyclonedx \
  registry.example.com/team/api@sha256:3b1a9c...e2f

Closing the loop — enforcement at deploy time. Generating provenance, signatures, and SBOMs is only half the value; the payoff is enforcing them. Kubernetes admission controllers (Kyverno, Sigstore policy-controller, Connaisseur, OPA Gatekeeper) can reject any image that isn’t signed by your CI’s identity or lacks a passing SBOM attestation. This turns “we trust our pipeline” into a cluster-enforced guarantee: an unsigned or unknown image simply cannot start in production.

Defending against dependency confusion and typosquatting

Two of the most common supply-chain attacks target the resolution step:

• Dependency confusion — an attacker publishes a public package with the same name as one of your internal packages and a higher version number; a misconfigured resolver pulls the malicious public one. Defenses: scope/namespace internal packages (npm @myorg/, Maven internal groupId, unique names), configure resolvers so internal names resolve only from your private repo, and set explicit priority so private always wins over public.
• Typosquatting — a malicious package named reqeusts or python-dateutil- preys on typos. Defenses: proxy all public registries through your repository manager so you have one place to block known-bad packages, and use lockfiles with integrity hashes so an unexpected package can’t slip in silently.

Best Practices

1. Build once, promote everywhere — rebuilding per environment invalidates your testing; promotion should be a copy/retag, never a recompile. What you tested must be byte-for-byte what you ship.
2. Make release artifacts immutable — enable “block redeploy/overwrite” on release repos and immutable tags on registries; a version, once published, never changes meaning. Keep mutable snapshots in a separate repo.
3. Never deploy latest (or any moving tag) — deploy unique, traceable version tags and pin container digests so what runs is exactly what was tested and reviewed.
4. Proxy all public registries — route Maven Central, npm, PyPI, Docker Hub through your repository manager for caching, availability during upstream outages, rate-limit relief (Docker Hub’s anonymous pull limits especially), audit trails, and a single chokepoint to block malicious packages.
5. Defend against dependency confusion — scope internal package names, pin private-registry priority above public, and configure resolvers so an internal name can never be satisfied from a public registry.
6. Use lockfiles with integrity hashes — package-lock.json, poetry.lock, go.sum, Cargo.lock pin exact versions and content hashes, so a compromised or swapped dependency fails the integrity check instead of installing silently.
7. Scan artifacts continuously, not just at build time — new CVEs are published daily against components that were clean when you built; rescan stored images and packages on a schedule (Trivy, Grype, ECR scanning, Nexus IQ, Xray) and alert when a deployed version becomes vulnerable.
8. Automate retention with a production-aware exemption — lifecycle rules for snapshots, untagged manifests, and old pre-releases keep storage and attack surface down; always exempt artifacts referenced by running deployments or compliance holds.
9. Authenticate machines with scoped, short-lived credentials — use robot accounts and OIDC federation for CI with write access limited to specific repos; prefer per-job identity tokens over long-lived static credentials; keep humans read-mostly.
10. Sign artifacts in CI and verify at deploy time — cosign signing bound to your CI’s OIDC identity, plus a cluster admission policy that rejects unsigned images, turns “trust the pipeline” into an enforced guarantee.
11. Generate and store an SBOM per release artifact — attach it in the registry as a signed attestation/referrer so vulnerability response is a query, not an archaeology project, and downstream consumers can audit what they’re running.
12. Capture and attach build provenance (SLSA) — record source repo, commit, and builder identity so any running binary is traceable to its exact source and build, and tampering between build and deploy is detectable.
13. Embed traceability metadata in the artifact — include git SHA, build number, and pipeline URL as OCI labels / artifact properties so an operator inspecting a running container can jump straight to the source and build that produced it.
14. Separate repositories by trust and lifecycle — distinct repos for snapshots vs releases, internal vs proxied-public, and per team/environment, each with appropriate permissions and retention. One giant bucket makes policy impossible.
15. Enforce least-privilege and quotas on the registry — RBAC so teams push only to their own namespaces, storage quotas so one team can’t fill the disk, and read-only access for consumers.
16. Back up and plan HA for the repository — the artifact repo is a tier-1 dependency; if it’s down, you can neither build (dependencies) nor deploy (artifacts) nor roll back (previous versions). Treat its availability with the same seriousness as your production database.

References

• roadmap.sh — DevOps Roadmap
• JFrog Artifactory Documentation
• Sonatype Nexus Repository Documentation
• GitHub Packages Documentation
• GitLab Package Registry Documentation
• Harbor Documentation
• Amazon ECR Documentation
• Azure Container Registry Documentation
• Google Artifact Registry Documentation
• OCI Distribution Specification
• Semantic Versioning specification
• Sigstore / cosign Documentation
• SLSA — Supply-chain Levels for Software Artifacts
• CycloneDX SBOM standard
• SPDX SBOM standard
• Syft (SBOM generation) and Grype (vulnerability scanning)
• Trivy (scanner for images, filesystems, IaC)
• Kyverno — Kubernetes policy engine
• GitHub — Artifact Attestations
• Book: Continuous Delivery — Jez Humble & David Farley (chapters on the deployment pipeline and artifact repositories)