Gyaan

Artifact Management and Registries

intermediate registries artifacts versioning scanning

When our CI pipeline builds something — a Docker image, a JAR file, an npm package — that output is called an artifact. We need somewhere to store these artifacts, version them, and make sure they’re safe. That’s what registries and artifact management are about.

What Are Artifacts?

An artifact is the built output of our code. It’s the thing that actually runs in production.

  • Docker images — the most common artifact in modern DevOps
  • JARs / WARs — Java applications
  • npm packages — JavaScript libraries
  • Helm charts — Kubernetes package definitions
  • Binary executables — Go, Rust compiled binaries

The key distinction: source code is what we write, artifacts are what we deploy.

Container Registries

A container registry is like npm or PyPI, but for Docker images. We push images to it after building, and pull from it when deploying.

Popular Container Registries
Docker Hub     — the default, free for public images
GHCR         — GitHub Container Registry, great with GitHub Actions
ECR          — AWS Elastic Container Registry
GCR / GAR    — Google Container / Artifact Registry
ACR          — Azure Container Registry
Harbor        — self-hosted, open source
# build and push to GHCR
docker build -t ghcr.io/myorg/myapp:v1.2.3 .
docker push ghcr.io/myorg/myapp:v1.2.3

# pull on the server
docker pull ghcr.io/myorg/myapp:v1.2.3

Image Tagging Strategies

How we tag images matters more than people think. A bad tagging strategy leads to “what’s actually running in production?” confusion.

Semantic versioning — v1.2.3. Clear, human-readable, great for releases.

Git SHA — abc123f. Ties the image directly to a commit. No ambiguity.

latest — always points to the most recent build. Convenient but dangerous — we never know exactly which version latest is.

# good practice: tag with both semver and git SHA
docker build \
  -t ghcr.io/myorg/myapp:v1.2.3 \
  -t ghcr.io/myorg/myapp:$(git rev-parse --short HEAD) \
  .

The rule: never use latest in production manifests. Always pin to a specific version or SHA. Using latest means our deployments aren’t reproducible.

Vulnerability Scanning

Every Docker image contains an OS layer, libraries, and our code. Any of those can have known vulnerabilities. Scanning tools check our images against CVE databases.

# scan with Trivy (free, open source)
trivy image ghcr.io/myorg/myapp:v1.2.3

# scan and fail if critical vulnerabilities found (great for CI)
trivy image --exit-code 1 --severity CRITICAL ghcr.io/myorg/myapp:v1.2.3

Most registries now offer built-in scanning too — ECR scans on push, GHCR integrates with Dependabot, and Harbor has Trivy built in.

Image Signing

Signing proves that an image came from us and hasn’t been tampered with. Tools like Cosign (from Sigstore) make this easy.

# sign an image after pushing
cosign sign ghcr.io/myorg/myapp:v1.2.3

# verify before deploying
cosign verify ghcr.io/myorg/myapp:v1.2.3

In simple language, artifact management is the supply chain of our software. We build it, store it safely, check it for problems, sign it to prove it’s legit, and then deploy it. Skipping any of these steps is how supply chain attacks happen.

References