Patch Container Vulnerabilities in Seconds Without Rebuilding Images

Your security scan just flagged 47 vulnerabilities in your production container image. Most of them are OS-level packages you didn't even know were there.

The traditional solution? Rebuild the entire image, update base images, wait for upstream fixes, redeploy everything. This takes hours or days.

There's a better way.

The problem with container vulnerabilities

Container images bundle your application code with OS packages, libraries, and dependencies. When a security vulnerability is discovered in any of these components, you're exposed.

The typical workflow looks like this:

  1. Security scanner finds vulnerabilities
  2. Wait for upstream base image updates
  3. Rebuild your image
  4. Test everything again
  5. Deploy

This process is slow. During that time, your vulnerable containers are running in production.

The tools: Trivy + Copa

Trivy is a vulnerability scanner that finds security issues in container images, filesystems, and git repositories. It's fast, accurate, and open source.

Copa (short for Copacetic) patches container images directly by applying security updates to vulnerable OS packages. No rebuilds required.

Together, they let you scan for vulnerabilities and patch them in seconds.

Installing the tools

# Install Trivy (macOS)
brew install trivy

# Install Copa
brew install copa

# Verify installations
trivy --version
copa --version

For Linux or other platforms, check the official docs:

Scanning for vulnerabilities

First, scan your image to see what you're dealing with:

# Scan an image and show summary
trivy image --report summary --scanners vuln --pkg-types os --ignore-unfixed nginx:latest

# Example output:
# nginx:latest (debian 12.4)
#
# Total: 95 (UNKNOWN: 0, LOW: 58, MEDIUM: 23, HIGH: 12, CRITICAL: 2)
#
# ┌──────────────┬──────────────┬──────────┬────────┬───────────────────┐
# │   Library    │ Vulnerability│ Severity │ Status │  Installed Version│
# ├──────────────┼──────────────┼──────────┼────────┼───────────────────┤
# │ libssl3      │ CVE-2023-5678│ CRITICAL │ fixed  │ 3.0.11-1~deb12u2  │
# │ openssl      │ CVE-2023-5678│ CRITICAL │ fixed  │ 3.0.11-1~deb12u2  │
# └──────────────┴──────────────┴──────────┴────────┴───────────────────┘

The flags explained:

  • --pkg-types os - Only scan OS packages (not language-specific dependencies)
  • --ignore-unfixed - Skip vulnerabilities without available patches
  • --scanners vuln - Only run vulnerability scanning (not misconfigurations, secrets, etc.)

Patching vulnerabilities automatically

Here's where it gets good. Generate a vulnerability report and apply patches:

# Generate vulnerability report in JSON format
trivy image --pkg-types os --ignore-unfixed -f json -o trivy.json nginx:latest

# Apply patches using Copa
copa patch -r trivy.json -i nginx:latest

# This creates a new patched image: nginx:latest-patched

Copa reads the Trivy report, identifies which packages need updates, and applies security patches directly to the image layers. It creates a new patched image without rebuilding from source.

Real example: patching a vulnerable image

Let me show you the complete workflow I use. Here's a Makefile that makes this trivial:

IMAGE := your-app:latest

# Patch vulnerabilities
patch:
\ttrivy image --pkg-types os --ignore-unfixed -f json -o trivy.json $(IMAGE)
\tcopa patch -r trivy.json -i $(IMAGE)

# Scan and show summary
scan:
\ttrivy image --report summary --scanners vuln --pkg-types os --ignore-unfixed $(IMAGE)

# Scan both original and patched images to compare
compare:
\t@echo "Original image:"
\t@trivy image --report summary --scanners vuln --pkg-types os --ignore-unfixed $(IMAGE)
\t@echo ""
\t@echo "Patched image:"
\t@trivy image --report summary --scanners vuln --pkg-types os --ignore-unfixed $(IMAGE)-patched

Usage:

# Scan for vulnerabilities
make scan

# Patch them
make patch

# Compare before/after
make compare

Before and after results

Here's what the output looks like when scanning a typical Node.js application image:

Before patching:

Total: 47 (HIGH: 12, CRITICAL: 3)

Critical vulnerabilities:
- libssl3: CVE-2023-5678
- curl: CVE-2023-46218
- libsystemd0: CVE-2023-7008

After patching:

Total: 0 (HIGH: 0, CRITICAL: 0)

All OS-level vulnerabilities with available patches have been fixed.

The patched image went from 47 vulnerabilities to zero in under 30 seconds.

How Copa works under the hood

Copa doesn't rebuild your image from scratch. Instead, it:

  1. Analyzes the vulnerability report from Trivy
  2. Downloads the updated packages for vulnerable components
  3. Creates new image layers with patched packages
  4. Preserves all your application code and custom configurations

This is way faster than rebuilding because it only touches the packages that need updates.

Important limitations

Copa is powerful but has constraints you need to understand:

1. OS packages only

Copa patches OS-level packages (apt, apk, yum packages). It doesn't patch:

  • Language-specific dependencies (npm packages, Python packages, Go modules)
  • Application code vulnerabilities
  • Custom compiled software

For these, you still need to update your source and rebuild.

2. Only patches with available fixes

The --ignore-unfixed flag is important. Copa can only apply patches when upstream maintainers have released security updates. If a vulnerability has no fix available yet, Copa can't help.

3. Base image matters

Copa works best with official base images that have active security maintenance:

  • debian, ubuntu, alpine - Good
  • node, python, nginx - Good (based on maintained images)
  • Random images from Docker Hub - Risky

Integrating into CI/CD

You can integrate vulnerability patching into your CI/CD pipeline to automatically patch OS vulnerabilities before deployment. This ensures every build is automatically scanned and patched, keeping your container images secure without manual intervention.

When to use Copa vs rebuilding

Use Copa when:

  • You need to patch production images quickly
  • The vulnerabilities are in OS packages only
  • You don't control the base image build process
  • You want to patch third-party images (nginx, postgres, etc.)

Rebuild from source when:

  • Vulnerabilities are in application dependencies
  • You're making code changes anyway
  • You want to update the base image version
  • You need to change build-time configurations

For most production systems, use both: Copa for emergency patches, scheduled rebuilds for comprehensive updates.

Takeaways

  1. Copa patches OS vulnerabilities in seconds - No need to rebuild entire images just to update system packages

  2. Use --ignore-unfixed - Only focus on vulnerabilities that actually have patches available

  3. OS packages only - Copa handles system-level vulnerabilities, not application dependencies

  4. Integrate into CI/CD - Automate vulnerability patching so every deployed image is secure

  5. Not a replacement for rebuilding - Use Copa for quick patches, but still rebuild regularly for comprehensive updates

  6. Test patched images - Even though Copa is safe, always test patched images before deploying to production

The speed difference

Traditional approach to fixing a critical vulnerability:

  1. Wait for base image update: 1-3 days
  2. Rebuild image: 5-10 minutes
  3. Run tests: 10-30 minutes
  4. Deploy: 5-10 minutes

Total: Hours to days

Copa approach:

  1. Scan: 30 seconds
  2. Patch: 20 seconds
  3. Deploy: 5-10 minutes

Total: Minutes

That's the difference between responding to a critical CVE in under an hour versus waiting days for fixes to trickle through the supply chain.

When zero-day vulnerabilities drop, every hour counts.

·share on