Struggling with a sea of red on your container security scans? This is a senior engineer’s no-nonsense guide to triaging and fixing container CVEs, moving from the quick patch to the permanent, architectural solution.

So Your Container Scan is a Sea of Red: A Senior Engineer’s Guide to Taming CVEs

I remember it like it was yesterday. It’s 2 AM, and the big go-live for our new payments microservice is blocked. The CI/CD pipeline is bleeding red. Why? A ‘CRITICAL’ CVE in a library I’d never even heard of, flagged by our automated scanner. The security team was (rightfully) losing their minds, management wanted answers, and I was staring at a vulnerability in a package that, it turned out, was only used by the package manager itself to unpack other files. Our application never called it, never touched it. That night taught me a hard lesson: not all CVEs are created equal, and fixing them is often more art than science.

First, Why Is My Simple Container Full of Holes?

You wrote a 50-line Python script, put it in a container, and your scanner comes back with 150 vulnerabilities. How? Because you didn’t just ship your script; you shipped an entire operating system with it. When you write FROM ubuntu:22.04 in your Dockerfile, you’re inheriting every library, every utility, and every potential vulnerability that comes with that base image. Your scanner sees that an ancient version of curl or libssl is present, and it screams bloody murder—even if your app is just a simple web server that never makes an outbound call.

The vast majority of vulnerabilities aren’t in your code. They’re in the foundation you built on. So, let’s fix the foundation.

Solution 1: The Quick Fix – “The APT-GET Hammer”

You’re on a deadline. The pipeline is blocked. You just need to make the scanner happy and move on. I get it. This is the tactical, short-term fix.

The idea is simple: inside your Dockerfile, after you declare your base image, force the package manager to update itself and all installed packages to their latest versions. This will often patch the low-hanging fruit.

Example Dockerfile (Before):

FROM debian:11-slim

# Copy application files
COPY ./myapp /app/myapp

CMD ["/app/myapp"]

Example Dockerfile (After):

FROM debian:11-slim

# Add this layer to patch existing OS-level vulnerabilities
RUN apt-get update && apt-get upgrade -y && rm -rf /var/lib/apt/lists/*

# Copy application files
COPY ./myapp /app/myapp

CMD ["/app/myapp"]

Warning: This is a band-aid, not a cure. It adds a new layer to your image, increasing its size. More importantly, it’s not deterministic. The packages upgraded today might be different from the ones upgraded tomorrow, leading to “it works on my machine” headaches. Use it to get unblocked, but plan for a real fix.

Solution 2: The Permanent Fix – “Rebuild on a Better Foundation”

The real, long-term solution is to stop shipping a bloated operating system with your application. You need to change your FROM line. This approach tackles the root cause by fundamentally reducing your container’s attack surface.

Option A: Use a Specific, Patched Base Image Tag

Instead of using a floating tag like ubuntu:latest or debian:11-slim, use a specific, dated tag. The image maintainers release updated images with the latest security patches baked in. By pointing to a specific version, you get a patched image from the start, and your builds become more reproducible.

# Less good: Could be an old, unpatched version
FROM python:3.10-slim

# Much better: A specific version released on a certain date
FROM python:3.10.13-slim-bookworm

Option B: Switch to a Minimalist Base Image

If your application is a compiled binary (like Go) or doesn’t have complex OS dependencies, this is the gold standard. Minimal images contain only what is absolutely necessary to run an application, and nothing more. No shell, no package manager, no extra libraries. No cruft means fewer vulnerabilities.

Here’s how the popular choices stack up:

Base Image	Typical Size	Attack Surface	Debugging Ease
ubuntu:22.04	~78MB	Very Large	Easy (full shell)
alpine:latest	~8MB	Very Small	Okay (basic shell)
gcr.io/distroless/static-debian11	~2MB	Microscopic	Hard (no shell)

Pro Tip: For compiled languages like Go, Rust, or C++, a multi-stage build is your best friend. Compile your code in a full build image with all the tools, then copy the final binary into a tiny ‘distroless’ or ‘scratch’ image for the final product.

Solution 3: The ‘Nuclear’ Option – “The CVE Suppression List”

Sometimes, you’re stuck. A CVE is flagged, but:

• The base image maintainer hasn’t released a patch yet.
• The vulnerability is in a dev tool that isn’t present in production, but the scanner sees it anyway.
• The vulnerability is technically present but not exploitable in your specific use case (like the `tar` example from my story).

This is where you use a suppression file (sometimes called an ignore list or allow-list). You are explicitly telling your scanner, “I acknowledge this vulnerability, I have assessed the risk, and I am accepting it for a specific reason.”

This is a governance process, not just a technical fix. You can’t just ignore things without reason.

For a tool like Trivy, you might create a .trivyignore file:

# Ignore this specific CVE until the end of Q3. A patch is expected from upstream.
# Ticket: SEC-1234
CVE-2023-4567

# This library is only used for running tests and is not packaged in the final image.
# Assessed as a false positive for prod-db-01.
CVE-2022-8910

Critical Rule: Every ignored CVE needs a justification, a ticket reference, and an expiration date. An ignored CVE without a paper trail is just hidden tech debt waiting to blow up. Review your suppression list every quarter. Don’t let it become a digital graveyard.

Putting It All Together

There’s no single magic bullet. Taming CVEs is a layered strategy. Start with the quick hammer-and-nail approach to unblock yourself, but immediately create a ticket to address the root cause by improving your base image. Reserve the suppression list for true exceptions, and treat it with the respect it deserves.

Get your foundation right, and you’ll spend less time chasing red alerts and more time building great software. Now, go get those scans green.

---

🤖 Frequently Asked Questions