In traditional server deployments, security updates follow a clear path: system administrators run yum update or apt-get upgrade to patch the underlying OS while applications remain unchanged. Docker containers break this paradigm by bundling both application and OS dependencies into immutable images.

# Traditional update vs Container update
Host System Update:
sudo yum update openssl

Containerized Update:
docker build -t myapp:patched .
docker stop myapp && docker rm myapp
docker run -d --name myapp myapp:patched

For RHEL-based containers, Red Hat suggests these key strategies:

• Use yum update --security in build process
• Implement image vulnerability scanning with OpenSCAP
• Leverage Atomic Host for host-level updates

Here are three production-tested approaches with code examples:

1. The Rebuild Strategy

# Dockerfile snippet for rebuild-based updates
FROM rhel7:latest
RUN yum -y update --security && \
    yum clean all
COPY ./app /app
CMD ["/app/start.sh"]

2. The Sidecar Updater

# Kubernetes cronjob for in-container updates
apiVersion: batch/v1beta1
kind: CronJob
metadata:
  name: security-updater
spec:
  schedule: "0 3 * * *"
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: updater
            image: redhat/updater
            command: ["/bin/sh", "-c", "yum -y update --security"]
          restartPolicy: OnFailure

3. The Golden Image Pattern

Create a base image with all security patches, then layer applications:

# Build patched base image
FROM rhel7:7.6
RUN yum -y update --security && \
    yum clean all

# Application Dockerfile
FROM mycompany/patched-base:2020-09
COPY ./app /app

When implementing container security updates:

• Maintain an audit trail of all image changes
• Test updates in staging before production
• Implement rollback capability (consider Docker image tags)
• Monitor running containers for drift from base image

Unlike traditional server deployments where security updates can be applied through standard package managers (yum update, apt-get upgrade), Docker containers present a unique challenge. The very strength of containers - their immutable, self-contained nature - becomes an operational hurdle when urgent CVE patches need deployment.

Consider these common but problematic approaches:

# Bad Practice 1: Ad-hoc container patching
docker exec -it my_container yum update openssl

# Bad Practice 2: Host-level updates only
sudo yum update # Does nothing for containers

The first approach violates container immutability, while the second leaves containers vulnerable.

For RHEL-based containers, Red Hat suggests:

1. Rebuilding from updated base images
2. Using the Image Builder service
3. Implementing atomic update strategies

Example rebuild process:

FROM registry.access.redhat.com/ubi8/ubi:8.5-226

# Update all packages during build
RUN yum update -y && \
    yum clean all

COPY ./app /app

Modern CI/CD pipelines should incorporate security scanning:

# Sample GitLab CI pipeline
stages:
  - security-scan
  - rebuild
  - deploy

container_scan:
  stage: security-scan
  image: docker:stable
  script:
    - docker scan $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA

rebuild_base:
  stage: rebuild
  image: docker:stable
  script:
    - docker build --pull -t $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA .

For zero-downtime updates:

# Kubernetes rolling update strategy
spec:
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 25%
      maxUnavailable: 25%

Essential scanning tools for container workflows:

• Trivy (open-source)
• Clair (CoreOS)
• Anchore Engine
• Red Hat Quay security scanning