Dockerfile Optimization Journey: From Security Mindset To Runner-Up at Python Contest 2025

In early 2025, I had the opportunity to participate in the Dockerfile Contest organized by the DevOps.vn community. This is an exciting playground for DevOps/SRE engineers to compete on two core criteria: Smallest Image Size and Fastest Build Time. For me, this competition was not just about numbers, but a place to apply the "Zero Trust" security philosophy to container architecture.

1. Starting Point And Strategic Goal

I come from an Information Security background, having battled in many Web Security CTFs. Days spent setting up Proxmox nodes to deploy opensource projects helped me fall in love with and deeply explore Docker.

This background shaped my strategic goal for the competition: Not just an image that "runs", but one that is absolutely secure and free of vulnerabilities.

In security thinking, minimizing the Attack Surface is vital. This inadvertently aligns with the competition's goal of minimizing image size. I pursued the "Zero Trust Runtime" philosophy: Instead of just deleting cache or temporary files, I proactively removed every component unnecessary for running the application, including unused Python Standard Library modules. Every superfluous file is a potential risk.

2. Philosophy "What Doesn't Exist Cannot Be Exploited"

Experience from CTFs shows that attackers often leverage available tools in the system to escalate privileges. Therefore, I applied an Aggressive Cleanup strategy.

For example, a pure FastAPI service certainly doesn't need turtle (graphics), tkinter (GUI), or idlelib (IDE). Keeping them only increases size and risk. However, deep intervention into the Standard Library always comes with risks:

• Dynamic Import: Some libraries import modules dynamically; deleting them wrongly causes runtime errors.
• Hidden Dependencies: A typical example is pydantic needing the email module - something I once accidentally deleted during testing.

To control risk, I didn't delete based on intuition but applied a process:

1. Analyze dependency tree thoroughly (pip show).
2. Test every application endpoint carefully.
3. Combine using Repomix to pack all code into a single text file, then use AI (ChatGPT/Claude) to analyze the entire codebase, helping identify exactly which modules are truly needed.

The result was trading a bit more checking effort for an image "cleaner" by ~11 MB and absolute peace of mind regarding security.

3. Deep Optimization Techniques

Besides cleaning up code, I applied binary "strip" techniques (removing debug symbols) and deleted package metadata (.dist-info). The purpose is to remove "developer-only" information from the production environment. Debug symbols or Changelogs can provide valuable information to attackers (like specific versions or code structure).

However, I assess that the technique of removing excess modules in the Python standard library brought the highest efficiency:

• Size: Significant reduction (~11 MB).
• Security: Completely removed unnecessary executable code like test frameworks or complex parsers (lib2to3) - places inherently hiding many vulnerabilities.

4. "0 CVEs" Principle And Dependency Management

My Dockerfile announced the goal of reaching 0 CVEs. To do this, I combined 3 tools: Trivy, Grype, and Docker Scout. Each tool has its own database; cross-checking helps me not miss any vulnerabilities.

In dependency management, I always follow the "golden rules":

1. Patch First, Feature Later: Prioritize versions with security patches (use pip-audit to scan).
2. Pin Everything: Always pin specific versions (Example: aiohttp>=3.12.14,<4.0.0 to ensure CVE patches are present).
3. Trust but Verify: Don't absolutely trust scanners, always manually check High/Critical alerts.
4. Automation: Integrate security scanning scripts into CI/CD to block builds immediately if vulnerabilities are detected.

5. Challenge With Alpine And Debugging Mindset

Choosing Alpine as the base image for size optimization brought the biggest technical challenge: The conflict between musl libc (of Alpine) and glibc (popular standard). Many Python libraries like cryptography or pandas are pre-compiled for glibc, leading to ImportError or Segmentation Fault errors when running on Alpine.

In a minimal environment (no bash, no curl), my debugging mindset is "Environment Separation". I built a separate Debug Image — identical to production but with tools like vim, strace, gdb installed. When encountering errors, I reproduced them on the Debug Image, used strace to inspect missing dynamic link files (.so), then went back to fix the main Dockerfile. Additionally, Dive was also a powerful assistant helping inspect every layer to visually detect excess/missing files.

6. Lessons And Future Of Container Architecture

The biggest lesson I learned is: "Measure, Don't Guess". Don't optimize based on intuition. Use metrics from dive, trivy to decide which files to delete, which packages to upgrade. Every small change needs to be verified by specific numbers.

Regarding architectural thinking, treat Containers as an Immutable Artifact. Everything necessary must be packaged inside, secure and minimal from the start.

The future of optimization will likely lie in automation with AI assistance. We will soon have AI-Powered Optimizer tools automatically analyzing code to generate the optimal Dockerfile or CI/CD systems auto-patching errors. At that point, the engineer's role will shift from manual configuration to setting high-level security and performance policies.

---

Hope these shares will be helpful for you in your container optimization and security journey!