DevOps Artifact Management and Container Registries

An artifact is any versioned, deployable output produced by a build process. Docker images, compiled JAR files, npm packages, Python wheels, Helm charts, and compiled binaries are all artifacts. Artifact management is the practice of storing, versioning, securing, and distributing these outputs reliably across the software delivery pipeline.

Without proper artifact management, teams face broken builds from deleted dependencies, security vulnerabilities in unscanned images, and no reliable way to reproduce a specific past deployment.

Why Artifact Management Matters

• Reproducibility: The exact artifact that passed testing is the one deployed to production — not a newly built version that might differ.
• Security: Scan artifacts for vulnerabilities before they reach production.
• Traceability: Every artifact is linked to the Git commit, branch, and pipeline run that produced it.
• Rollback: Previous artifact versions are always available for instant rollback.
• Dependency control: Proxy external package registries to cache dependencies and prevent supply chain attacks.

Artifact Types and Storage

Docker Image Tagging Strategy

Tagging Docker images with meaningful, consistent names is essential for traceability and rollback. Poor tagging (using only :latest) is one of the most common and dangerous anti-patterns in DevOps.

Recommended Tagging Strategy

# Tag with the Git commit SHA — fully unique and traceable
docker build -t myrepo/webapp:a3f9d12 .

# Tag with the semantic version for releases
docker tag myrepo/webapp:a3f9d12 myrepo/webapp:2.5.1

# Tag with the branch name for branch builds
docker tag myrepo/webapp:a3f9d12 myrepo/webapp:feature-new-checkout

# The :latest tag — update it, but never deploy using :latest alone
docker tag myrepo/webapp:2.5.1 myrepo/webapp:latest

In production Kubernetes deployments, always use the commit SHA or semantic version tag — never :latest. The :latest tag moves to a different image on every build, making deployments non-deterministic.

AWS ECR – Elastic Container Registry

AWS ECR is a fully managed Docker image registry integrated with the AWS ecosystem. It works natively with ECS, EKS, CodeBuild, and GitHub Actions.

Push an Image to ECR

# Authenticate Docker to ECR
aws ecr get-login-password --region us-east-1 \
  | docker login --username AWS \
    --password-stdin 123456789.dkr.ecr.us-east-1.amazonaws.com

# Create a repository (first time only)
aws ecr create-repository --repository-name webapp --region us-east-1

# Tag the image for ECR
docker tag webapp:2.5.1 \
  123456789.dkr.ecr.us-east-1.amazonaws.com/webapp:2.5.1

# Push to ECR
docker push 123456789.dkr.ecr.us-east-1.amazonaws.com/webapp:2.5.1

ECR Lifecycle Policies – Automatic Cleanup

{
  "rules": [
    {
      "rulePriority": 1,
      "description": "Keep last 30 tagged images",
      "selection": {
        "tagStatus": "tagged",
        "tagPrefixList": ["v"],
        "countType": "imageCountMoreThan",
        "countNumber": 30
      },
      "action": { "type": "expire" }
    },
    {
      "rulePriority": 2,
      "description": "Delete untagged images older than 7 days",
      "selection": {
        "tagStatus": "untagged",
        "countType": "sinceImagePushed",
        "countUnit": "days",
        "countNumber": 7
      },
      "action": { "type": "expire" }
    }
  ]
}

Harbor – Self-Hosted Container Registry

Harbor is an open-source enterprise container registry that extends Docker Distribution with security scanning, role-based access control, content trust, and replication.

Key Harbor Features

• Vulnerability scanning: Integrates with Trivy or Clair to scan every pushed image automatically.
• Content trust: Enforces that only signed images can be pulled and run.
• Replication: Synchronizes images across multiple Harbor instances or to ECR/GCR for geographic distribution.
• RBAC: Project-level access control — teams only access their own image repositories.
• Quota management: Limits storage consumption per project.
• Proxy cache: Caches Docker Hub images locally — speeds up builds and protects against Docker Hub rate limits.

JFrog Artifactory and Sonatype Nexus

Artifactory and Nexus are universal artifact repository managers. They handle Docker images alongside every other artifact type: Maven JARs, npm packages, Python wheels, Helm charts, and raw binaries — in one place.

Repository Types

• Local repositories: Store internally built artifacts.
• Remote/proxy repositories: Cache external registries (Maven Central, PyPI, npm). Builds use the internal proxy — if the external registry goes down, the cache keeps builds working.
• Virtual repositories: A single URL that aggregates multiple local and remote repositories. Developers use one URL for all dependencies.

Artifact Management in CI/CD Pipelines

GitHub Actions – Build, Scan, and Push

name: Build and Push Docker Image

on:
  push:
    branches: [main]

jobs:
  build-and-push:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Configure AWS credentials
        uses: aws-actions/configure-aws-credentials@v4
        with:
          aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
          aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          aws-region: us-east-1

      - name: Log in to Amazon ECR
        id: login-ecr
        uses: aws-actions/amazon-ecr-login@v2

      - name: Build Docker image
        env:
          ECR_REGISTRY: ${{ steps.login-ecr.outputs.registry }}
          IMAGE_TAG: ${{ github.sha }}
        run: |
          docker build -t $ECR_REGISTRY/webapp:$IMAGE_TAG .

      - name: Scan image for vulnerabilities
        uses: aquasecurity/trivy-action@master
        with:
          image-ref: ${{ steps.login-ecr.outputs.registry }}/webapp:${{ github.sha }}
          exit-code: '1'
          severity: 'CRITICAL'

      - name: Push image to ECR
        env:
          ECR_REGISTRY: ${{ steps.login-ecr.outputs.registry }}
          IMAGE_TAG: ${{ github.sha }}
        run: |
          docker push $ECR_REGISTRY/webapp:$IMAGE_TAG
          # Also tag and push as semantic version if on a release tag
          docker tag $ECR_REGISTRY/webapp:$IMAGE_TAG $ECR_REGISTRY/webapp:latest
          docker push $ECR_REGISTRY/webapp:latest

Image Signing and Supply Chain Security

Signing Docker images cryptographically proves that an image was built by a trusted system and has not been tampered with since.

Cosign – Container Image Signing

# Generate a signing key pair
cosign generate-key-pair

# Sign an image after pushing to registry
cosign sign --key cosign.key \
  123456789.dkr.ecr.us-east-1.amazonaws.com/webapp:2.5.1

# Verify an image signature before pulling
cosign verify --key cosign.pub \
  123456789.dkr.ecr.us-east-1.amazonaws.com/webapp:2.5.1

Combining image signing with a Kubernetes admission controller (like Kyverno or OPA Gatekeeper) enforces that only signed images from trusted registries can run in the cluster.

SBOM – Software Bill of Materials

An SBOM is a complete inventory of every component and dependency inside a software artifact. Regulatory requirements (US Executive Order 14028 on Cybersecurity) increasingly mandate SBOMs for software sold to governments.

# Generate an SBOM for a Docker image using Syft
syft 123456789.dkr.ecr.us-east-1.amazonaws.com/webapp:2.5.1 \
  -o spdx-json > webapp-2.5.1-sbom.json

# Scan the SBOM for vulnerabilities using Grype
grype sbom:./webapp-2.5.1-sbom.json

Summary

• Artifacts are the versioned, deployable outputs of build processes — always link them to the Git commit that produced them.
• Always use specific version tags (commit SHA or semantic version) for production deployments — never :latest alone.
• AWS ECR integrates natively with the AWS ecosystem. Harbor provides self-hosted enterprise features including scanning and signing.
• Nexus and Artifactory act as universal artifact repositories — storing and proxying all artifact types in one place.
• Vulnerability scanning (Trivy) and image signing (Cosign) are required steps in a secure artifact pipeline.
• SBOMs provide a complete inventory of every dependency inside an artifact for security and compliance.