Artifact Registries Are Now Part of the Attack Surface

· Eurtifact Platform Team

Context

For years, artifact registries (Docker registries, npm repositories, Maven Central) were treated as file storage. Teams pushed artifacts, others pulled them. The registry’s job was availability and bandwidth.

Supply chain attacks have changed this. Attackers no longer need to compromise application code. They can compromise the registry, substitute a malicious artifact, and wait for automated deployments to propagate it.

SolarWinds (2020), Codecov (2021), and PyPI typosquatting campaigns demonstrate that the artifact distribution layer is now a primary attack vector.

Reality Check

Common Belief

“Our artifact registry is behind a firewall and requires authentication. It’s not exposed to attacks.”

Why That’s Incomplete

Authentication protects against unauthorized external access. It does not protect against:

  • Insider threats: Developers or CI/CD pipelines with write access can push malicious artifacts
  • Credential compromise: Stolen CI/CD credentials allow attackers to push artifacts masquerading as legitimate builds
  • Dependency confusion: Attackers publish packages with the same name as internal libraries to public registries, and build systems pull the public (malicious) version instead
  • Registry compromise: Vulnerabilities in the registry software itself (Harbor, Artifactory, Nexus) can allow attackers to modify stored artifacts

Registries are no longer passive storage. They are trust boundaries.

Engineering Implications

Treating registries as attack surfaces requires technical controls beyond authentication.

1. Artifact Signing and Verification

Requirement: Every artifact must be cryptographically signed by the build process, and the registry must verify signatures before serving artifacts.

What this means:

  • Container images signed with Cosign or Notary
  • Signatures include provenance metadata (source commit, build timestamp, builder identity)
  • Registry admission control rejects unsigned or invalidly signed artifacts
  • Clients verify signatures before pulling (enforced via OPA policies or admission webhooks)

Example (Cosign signing):

# Sign container image during CI/CD build
cosign sign --key cosign.key registry.eurtifact.eu/app:v1.2.3

# Generate provenance attestation
cosign attest --predicate sbom.json --key cosign.key registry.eurtifact.eu/app:v1.2.3

# Verify before deployment (Kubernetes admission webhook)
cosign verify --key cosign.pub registry.eurtifact.eu/app:v1.2.3

Common failure: Signing artifacts but not enforcing verification. Signatures become documentation, not security controls.

2. Immutable Tags and Content Addressability

Requirement: Once an artifact is pushed, its content cannot be modified. Tags are immutable or use digest-based references.

What this means:

  • Disable tag overwriting in registry configuration (Harbor: immutable tag rules)
  • Use content digests instead of mutable tags in Kubernetes manifests:
    # WRONG: Mutable tag
image: registry.eurtifact.eu/app:latest

# CORRECT: Immutable digest
image: registry.eurtifact.eu/app@sha256:abcd1234...
  • Automated builds produce unique tags (commit SHA, build number) rather than reusing latest

Common failure: Using latest tags in production. An attacker who compromises the registry can push a malicious image as latest, and rolling deployments automatically pull it.

3. Vulnerability Scanning and Policy Enforcement

Requirement: The registry automatically scans artifacts for known vulnerabilities and blocks deployment of artifacts that violate security policies.

What this means:

  • Integration with Trivy, Grype, or Clair for CVE scanning
  • Admission policies that reject images with critical or high-severity vulnerabilities
  • Continuous re-scanning of stored artifacts as new CVEs are disclosed
  • Automated notifications when a deployed image becomes vulnerable

Example (Harbor vulnerability policy):

# Harbor project policy
project: production
prevent_vulnerable_images: true
severity_threshold: high  # Block images with high or critical CVEs
automatically_scan_on_push: true

Common failure: Scanning images but not enforcing policies. Scan results become informational, not gatekeeping.

4. Provenance and SBOM Availability

Requirement: Every artifact includes a Software Bill of Materials (SBOM) and provenance attestation linking it to source code and build process.

What this means:

  • SBOM in SPDX or CycloneDX format attached to artifacts (using cosign attest)
  • Provenance metadata includes:
    • Source repository URL and commit SHA
    • Build pipeline ID and timestamp
    • Builder identity (CI/CD system)
    • Dependencies included in the artifact
  • SBOM queryable via registry API for audit and compliance purposes

Example (generating and attaching SBOM):

# Generate SBOM using Syft
syft registry.eurtifact.eu/app:v1.2.3 -o spdx-json > sbom.json

# Attach SBOM as attestation
cosign attest --predicate sbom.json --key cosign.key \
  --type https://spdx.dev/Document \
  registry.eurtifact.eu/app:v1.2.3

Common failure: Generating SBOMs but not attaching them to artifacts. When an incident occurs, teams cannot determine which dependencies were included in deployed versions.

5. Access Control and Audit Logging

Requirement: Registry access is role-based, time-limited, and comprehensively logged.

What this means:

  • RBAC with separate roles for read (pull), write (push), and admin (policy configuration)
  • CI/CD credentials use short-lived tokens (not permanent API keys)
  • All push, pull, and delete operations logged with actor identity, timestamp, and artifact identifier
  • Logs forwarded to immutable storage for compliance (NIS2, CRA)

Example (Harbor RBAC):

# Project members
- username: ci-bot
  role: developer      # Can push artifacts
  token_expiry: 24h    # Rotated daily

- username: deploy-bot
  role: guest          # Can only pull artifacts
  token_expiry: 1h     # Short-lived for deployments

- username: admin
  role: project-admin  # Can configure policies
  mfa_required: true   # MFA enforced for privileged access

Common failure: Using permanent API keys for CI/CD. If leaked (committed to Git, exposed in logs), attackers have indefinite write access.

Failure Modes

Pattern 1: Unsigned Artifact Substitution

An attacker compromises a developer’s workstation and steals CI/CD credentials. They push a backdoored container image with the same tag as a legitimate build.

Without signature verification, Kubernetes pulls the malicious image during the next rolling update.

Why this fails: Tags are mutable. Without signatures, there’s no way to distinguish a legitimate artifact from an attacker-controlled one.

Solution: Cosign signature verification enforced via admission webhook. Unsigned images are rejected at admission time.

Pattern 2: Dependency Confusion in Private Registries

A company maintains an internal npm package @company/utils. An attacker publishes a public package with the same name to npmjs.com.

Build systems check public registries first and pull the attacker’s package instead of the internal one.

Why this fails: Package managers prioritize public registries by default. Without explicit scoping, internal package names can be shadowed.

Solution: Configure package managers to use private registry exclusively for scoped packages:

// .npmrc
@company:registry=https://registry.eurtifact.eu

Pattern 3: Vulnerable Image Deployed Despite Scanning

The registry scans an image and detects a critical vulnerability in OpenSSL. The scan result is logged, but deployment proceeds because there’s no policy enforcement.

Why this fails: Scanning without blocking is visibility, not protection.

Solution: Harbor project policies configured to prevent deployment of images with severity >= high. CI/CD pipeline fails if image violates policy.

What “Good” Looks Like

A secure artifact registry has these properties:

  1. Cryptographic Verification: All artifacts signed with Cosign or Notary. Kubernetes admission webhooks reject unsigned images. Signatures include provenance metadata.

  2. Immutable Storage: Content-addressable artifacts referenced by digest, not mutable tags. Tag overwriting disabled in registry configuration.

  3. Automated Policy Enforcement: Vulnerability scanning integrated with admission control. Images with critical CVEs are rejected before deployment, not flagged after.

  4. Provenance and SBOM: Every artifact includes an SBOM and build provenance attestation. Auditors can query the registry to determine what was deployed and when.

  5. Least-Privilege Access: CI/CD uses short-lived tokens with write-only permissions. Developers use read-only tokens for local testing. Privileged operations require MFA and are audited.

These are technical controls, not documentation artifacts.

Limits & Trade-offs

This approach does not:

  • Prevent all supply chain attacks: Attackers can compromise source code repositories, build systems, or signing keys. Registry controls reduce the attack surface, not eliminate it.
  • Solve zero-day vulnerabilities: Vulnerability scanning detects known CVEs. It does not detect backdoors or logic bugs introduced intentionally.
  • Eliminate operational complexity: Signature verification, SBOM generation, and policy enforcement add steps to the CI/CD pipeline. This complexity is necessary overhead, not optional.

Secure registries are a necessary but not sufficient component of supply chain security.

Key Takeaways

  • Artifact registries are no longer passive storage. They are trust boundaries and active targets for supply chain attacks.
  • Cryptographic signing (Cosign, Notary) ensures artifact integrity. Signatures must be verified at deployment time, not just generated at build time.
  • Mutable tags (latest, stable) enable substitution attacks. Use content digests (sha256:abcd...) in production manifests.
  • Vulnerability scanning without policy enforcement is visibility, not protection. Registries must reject vulnerable artifacts, not just report them.
  • SBOMs and provenance attestations must be attached to artifacts, not stored separately. This ensures auditability when incidents occur.

This article reflects the Eurtifact platform team’s understanding of artifact registry security as of February 2026. For implementation guidance specific to your infrastructure and compliance requirements, consult security and DevSecOps specialists.