Enterprise Container Registry Security: Building a Defence-in-Depth Strategy

Introduction

Container registries have become critical infrastructure in modern enterprises. They store the images that run in production, the base images that development teams build upon, and increasingly, the artifacts that define infrastructure itself. A compromised registry can inject malicious code into every deployment across an organisation.

The software supply chain attacks of recent years have elevated container security from an operational concern to a board-level risk. The SolarWinds incident, the Codecov breach, and numerous compromised npm packages demonstrated that attackers increasingly target the software supply chain rather than runtime environments.

For CTOs managing containerised workloads at scale, registry security requires a comprehensive strategy that addresses image provenance, vulnerability management, access control, and runtime verification. This guide examines how enterprise technology leaders are building defence-in-depth for their container supply chains.

The Container Security Landscape

Why Registries Are High-Value Targets

Container registries occupy a unique position in the software delivery pipeline:

Central distribution point: Every container pulled in production comes through the registry Trusted by default: Orchestrators like Kubernetes typically trust registry contents Persistent access: A compromised image continues affecting deployments until detected Broad impact: Popular base images affect countless downstream applications

Attackers who compromise a registry gain leverage that direct attacks on running systems cannot match. A single malicious image can affect thousands of containers across multiple environments.

Attack Vectors

Understanding threats helps prioritise defences:

Compromised base images: Malicious code inserted into public or internal base images that other images build upon

Dependency poisoning: Legitimate packages replaced with malicious versions in public registries

Image tampering: Modification of images after they pass security scanning but before deployment

Credential theft: Stolen registry credentials used to push malicious images

Registry infrastructure compromise: Direct attacks on registry servers or backing storage

Insider threats: Malicious or negligent employees introducing vulnerable or compromised images

The Supply Chain Imperative

Modern applications comprise more third-party code than first-party. A typical container image includes:

• Operating system packages
• Language runtime
• Application frameworks
• Direct dependencies
• Transitive dependencies

Each layer presents supply chain risk. The enterprise response must address the full chain, not just internally-developed code.

Registry Architecture Decisions

Public vs Private Registries

Public Registries (Docker Hub, GitHub Container Registry, Quay.io)

Advantages:

• No infrastructure to manage
• Wide availability of public images
• Global distribution networks

Risks:

• Images from unknown sources
• Rate limiting affecting production
• No control over image availability
• Potential for typosquatting attacks

Private Registries (Harbor, AWS ECR, Azure ACR, Google Artifact Registry)

Advantages:

• Full control over image inventory
• Enforcement of security policies
• Audit logging of all access
• Integration with enterprise identity

Considerations:

• Operational overhead
• Distribution across regions
• Mirror management for external images

Enterprise Recommendation

Production workloads should pull only from private registries. Mirror required external images through controlled processes that include security scanning and approval workflows.

Registry Selection Criteria

Evaluate registries against enterprise requirements:

Security features:

• Vulnerability scanning integration
• Image signing and verification
• RBAC and fine-grained access control
• Audit logging
• Network policies and IP restrictions

Operational capabilities:

• Multi-region replication
• High availability architecture
• Garbage collection for storage management
• Performance at scale
• Backup and disaster recovery

Integration:

• CI/CD pipeline compatibility
• Kubernetes admission controller support
• Identity provider integration
• Policy engine connectivity

Compliance:

• SOC 2, HIPAA, PCI-DSS certifications
• Data residency controls
• Encryption at rest and in transit
• Access audit trails

Harbor as Enterprise Platform

Harbor has emerged as a leading enterprise registry platform:

• Open source with enterprise governance (CNCF graduated project)
• Built-in vulnerability scanning with Trivy integration
• Content trust with Notary/Cosign
• Replication across instances
• RBAC with LDAP/OIDC integration
• Robot accounts for automation
• Webhook notifications for events

For organisations preferring managed services, cloud provider registries (ECR, ACR, Artifact Registry) offer similar capabilities with reduced operational burden.

Vulnerability Management

Scanning Strategy

Vulnerability scanning must occur at multiple points:

Build time: Scan images in CI pipelines before pushing to registry. Block builds with critical vulnerabilities.

Registry admission: Scan images on push to the registry. Quarantine images that fail policy.

Continuous monitoring: Re-scan stored images regularly as new vulnerabilities are discovered.

Runtime admission: Verify scan results before allowing images to run in Kubernetes.

Scanning once is insufficient. A clean image today may have critical vulnerabilities tomorrow when new CVEs are published.

Scanner Selection

Leading scanners for enterprise use:

Trivy

• Comprehensive vulnerability database
• OS packages, language packages, and IaC
• Fast scanning with good accuracy
• Strong Kubernetes integration
• Open source with active development

Grype

• Anchore’s open source scanner
• SBOM-based vulnerability matching
• Good performance characteristics
• Integration with Anchore Enterprise for advanced features

Snyk Container

• Commercial offering with free tier
• Developer-friendly experience
• IDE and SCM integrations
• Base image upgrade recommendations

Cloud provider scanners

• AWS ECR scanning
• Azure Defender for container registries
• Google Artifact Analysis
• Tight integration with respective platforms

Most enterprises use multiple scanners—different tools catch different issues.

Vulnerability Policies

Raw vulnerability counts overwhelm teams. Effective policies prioritise action:

Critical severity: Block deployment. Address within 24 hours.

High severity: Block production deployment. Address within 7 days. May allow deployment to development environments.

Medium severity: Flag for review. Address within 30 days. Allow deployment with exception.

Low severity: Informational. Address as part of regular maintenance.

Considerations for policy design:

• Exploitability: Is there a known exploit in the wild?
• Network exposure: Is the vulnerable component reachable from untrusted networks?
• Data sensitivity: What data could be compromised?
• Compensating controls: Are other mitigations in place?

Base Image Strategy

Base images are the foundation of container security:

Minimal images: Use distroless or minimal base images. Fewer packages mean fewer vulnerabilities.

Maintained images: Choose base images with active security maintenance.

Version pinning: Pin specific image versions rather than using latest tags.

Regular updates: Schedule regular base image updates to incorporate security patches.

Internal golden images: Maintain a library of approved, hardened base images for teams to build upon.

Image Signing and Verification

The Provenance Problem

Vulnerability scanning alone doesn’t guarantee that an image in production is the same one that was scanned. Images could be:

• Modified after scanning
• Replaced by malicious versions
• Built from compromised sources

Image signing establishes provenance—cryptographic proof of who built an image and that it hasn’t been modified.

Sigstore and Cosign

The Sigstore project has transformed container signing:

Cosign: Signs and verifies container images Fulcio: Provides short-lived certificates based on OIDC identity Rekor: Provides an immutable transparency log of signing events

Benefits of Sigstore:

• Keyless signing using existing identity (no key management)
• Public transparency log for audit
• Strong ecosystem adoption
• OIDC integration with common providers

Enterprise implementation:

# Sign an image using keyless signing
cosign sign --yes image:tag

# Verify signature
cosign verify --certificate-identity [email protected] \
  --certificate-oidc-issuer https://accounts.google.com \
  image:tag

Notation and Supply Chain Security

The Notary project (now Notation) provides an alternative signing approach:

• OCI-compliant signature storage
• Pluggable trust policy
• Support for hardware security modules
• Strong enterprise governance (CNCF project)

Notation may suit organisations with existing PKI infrastructure or specific compliance requirements.

Admission Control

Signatures are only valuable if verified. Kubernetes admission controllers enforce signing policies:

Sigstore Policy Controller: Verifies Cosign signatures during admission Kyverno: Policy engine with image signature verification OPA Gatekeeper: General-purpose policy with signature verification capabilities Connaisseur: Dedicated image signature verification

Policy example using Kyverno:

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: verify-image-signatures
spec:
  validationFailureAction: enforce
  rules:
  - name: verify-signature
    match:
      resources:
        kinds:
        - Pod
    verifyImages:
    - image: "registry.example.com/*"
      attestors:
      - entries:
        - keyless:
            subject: "*@example.com"
            issuer: "https://accounts.google.com"

Software Bill of Materials (SBOM)

Why SBOMs Matter

An SBOM lists all components within a software artifact—analogous to an ingredient list for food. SBOMs enable:

Vulnerability response: When a new vulnerability is announced, quickly identify affected images

License compliance: Understand what licenses govern software components

Supply chain visibility: Know what third-party dependencies exist

Regulatory compliance: Meet emerging requirements (US Executive Order 14028)

SBOM Generation

Generate SBOMs as part of the build process:

Syft (Anchore): Generates SBOMs in multiple formats

syft image:tag -o spdx-json > sbom.json

Trivy: Generates SBOMs alongside vulnerability scanning

trivy image --format spdx-json -o sbom.json image:tag

Docker BuildKit: Native SBOM generation

docker buildx build --sbom=true .

SBOM Formats

Standard formats enable tooling interoperability:

SPDX (Software Package Data Exchange): ISO standard, comprehensive CycloneDX: OWASP project, security-focused SWID (Software Identification): ISO standard, older format

Most organisations standardise on SPDX or CycloneDX.

SBOM Attestation

Attach SBOMs to images as attestations:

# Generate SBOM
syft image:tag -o cyclonedx-json > sbom.json

# Attach attestation
cosign attest --predicate sbom.json \
  --type cyclonedx image:tag

Attestations are signed and stored with the image, providing verified provenance for the SBOM itself.

Access Control and Governance

Authentication and Identity

Registry access should integrate with enterprise identity:

OIDC integration: Connect registries to corporate identity providers Service accounts: Use robot accounts or service principals for automation Short-lived credentials: Avoid long-lived credentials where possible Multi-factor authentication: Require MFA for privileged access

Authorisation Models

Implement least-privilege access:

Repository-level RBAC:

• Developers: Push to development repositories
• CI systems: Push to staging repositories
• Release automation: Push to production repositories
• Production systems: Pull-only access

Label-based policies: Control access based on image metadata or labels

Project isolation: Separate repositories by team or application

Audit and Compliance

Maintain comprehensive audit trails:

• Image push and pull events
• Authentication attempts
• Policy changes
• Administrative actions
• Scanning results and policy decisions

Feed audit logs to SIEM systems for correlation and alerting.

Operational Practices

Image Lifecycle Management

Registries accumulate images over time. Implement lifecycle policies:

Retention policies: Automatically delete old images (keeping recent N versions or images younger than N days)

Protected images: Tag production images for retention protection

Garbage collection: Schedule regular garbage collection to reclaim storage

Cross-reference checking: Verify images aren’t in use before deletion

Multi-Region Distribution

Global enterprises need images available near workloads:

Replication strategies:

• Push-based: Automatically replicate on image push
• Pull-through: Cache images on first pull
• Selective: Replicate only tagged releases

Considerations:

• Network bandwidth and costs
• Consistency delays during replication
• Disaster recovery across regions

Incident Response

Prepare for container security incidents:

Detection: Alert on policy violations, unsigned images, critical vulnerabilities

Containment: Ability to quarantine images, block deployments

Investigation: Trace image usage across environments, review build provenance

Remediation: Patch and rebuild affected images, rotate credentials

Recovery: Restore from known-good images, verify integrity

Document runbooks for common scenarios before incidents occur.

Integration Architecture

CI/CD Pipeline Integration

Security controls must integrate into existing workflows:

Build stage:

• Scan source code and dependencies
• Build image with minimal base
• Generate SBOM
• Scan image for vulnerabilities
• Sign image if scan passes
• Push to staging registry

Promotion stage:

• Re-verify signature
• Re-scan for newly discovered vulnerabilities
• Apply promotion policies
• Push to production registry

Deployment stage:

• Admission controller verifies signature
• Verify scan results meet policy
• Allow or deny deployment

Policy Enforcement Points

Implement controls at multiple levels:

Pipeline level: Prevent vulnerable images from being built Registry level: Quarantine non-compliant images Cluster level: Block deployment of unsigned or vulnerable images Runtime level: Monitor for unexpected behavior

Defence in depth ensures that failure at one level doesn’t compromise security.

Metrics and Measurement

Security Posture Metrics

Track security health over time:

• Percentage of images with critical/high vulnerabilities
• Mean time to remediate vulnerabilities by severity
• Percentage of images with valid signatures
• Number of unsigned images in registries
• Policy violation frequency

Operational Metrics

Monitor registry operations:

• Image pull latency
• Registry availability
• Scan completion times
• Replication lag
• Storage utilisation trends

Compliance Metrics

Demonstrate control effectiveness:

• Audit log completeness
• Policy coverage
• Access review completion
• Incident response times

Conclusion

Container registry security is fundamental to modern software supply chain protection. The images in your registry become the code running in production—securing the registry secures the supply chain.

Effective enterprise strategies combine multiple controls: vulnerability scanning catches known weaknesses, image signing establishes provenance, access controls limit who can modify images, and admission controllers verify compliance at deployment time. No single control is sufficient; defence in depth provides resilience against determined attackers.

The technology ecosystem has matured significantly. Sigstore has made image signing practical at scale. SBOM standards enable comprehensive component tracking. Policy engines provide flexible enforcement. The tools exist; implementation requires organisational commitment.

For CTOs, container registry security represents both risk and opportunity. Organisations that build robust supply chain security will increasingly differentiate themselves with customers and partners who scrutinise vendor security practices. Those that neglect this domain face material risks—from breaches affecting their own systems to regulatory penalties as supply chain requirements tighten.

The investment in registry security is an investment in the integrity of everything your organisation deploys.

Sources

1. CNCF. (2025). Software Supply Chain Best Practices. Cloud Native Computing Foundation.
2. NIST. (2022). Software Supply Chain Security Guidance. NIST SP 800-218.
3. Sigstore. (2025). Sigstore Documentation. https://docs.sigstore.dev/
4. Anchore. (2025). Container Security Best Practices. https://anchore.com/
5. Harbor. (2025). Harbor Documentation. https://goharbor.io/docs/

---

Strategic guidance for technology leaders securing container supply chains at enterprise scale.