Python is one of the most widely used languages for web applications, automation, data science, machine learning, and AI workloads. As Python applications move into production containers, the security of the image running the application becomes an important part of the application's overall security posture.
A Python application can have secure code and well-maintained dependencies, but the container can still introduce hundreds of additional operating-system packages, libraries, and executables that need to be monitored, patched, and secured.
We compared the official python:3.14.6 image with CleanStart's hardened Python 3.14.6 image using Trivy.
Both images contain the same Python version: Python 3.14.6.
The comparison shows substantial differences in image size, installed packages, executables, and reported vulnerabilities.
Comparison Baseline
Compared Item | Value |
Runtime | Python 3.14.6 |
Public Image | |
CleanStart Image | |
Scanner | Trivy |
Scan Method | Same configuration for both images |
Scan Date | Aug 6, 2026 |
Official Python vs CleanStart Python
We compared the official python:3.14.6 image with CleanStart Python 3.14.6 using Trivy.
Metric | python:3.14.6 | cleanstart -python |
Python Version | 3.14.6 | 3.14.6 |
Image Size | 395.6 MB | 44.3 MB |
Installed Packages | 469 | 53 |
Executables | 582 | 68 |
Total CVEs | 2601 | 0 |
Critical | 60 | 0 |
High | 373 | 0 |
Medium | 904 | 0 |
Low | 1214 | 0 |
Shell | ✓ | ✗ |
Package Manager | ✓ | ✗ |
SBOM | ✓ | ✓ |
Provenance | SLSA provenance, unsigned | SLSA L3, Cryptographically verified |
Signature | Not detected | Cosign keyless, Rekor-logged (verified) |
What the Scan Revealed
How Large Is the Official Python Docker Image?
The official python:3.14.6 image in this benchmark is 395.5 MB.
The CleanStart Python 3.14.6 image is 44.3 MB.
That represents an approximately 88.8% reduction in image size.
Image size is useful operationally because smaller images can reduce storage requirements and the amount of data that needs to be transferred when images are pulled or deployed.
How Many Packages Are Included?
The official Python image contains 469 installed packages in the benchmark.
CleanStart Python contains 53.
That's approximately 88.7% fewer packages.
A container's packages become part of the software inventory that organizations need to understand and maintain.
When vulnerabilities are disclosed in an operating-system component or library, security teams need to determine whether that component exists in their deployed images and whether remediation is required.
Reducing unnecessary packages can therefore reduce the amount of software that needs to be inventoried and maintained.
How Many Executables Are Included?
The benchmark identified:
- 582 executables in python:3.14.6
- 68 executables in CleanStart Python 3.14.6
That's approximately 88.3% fewer executables.
A production Python application generally does not need every utility that may be useful in a development environment.
Removing unnecessary executables can reduce the number of tools available inside the runtime and reduce the amount of software that needs to be tracked.
This is one component of a broader principle:
Only include functionality that the production workload actually needs.
How Many CVEs Does the Python Docker Image Have?
In the August 6, 2026 Trivy scan, python:3.14.6 reported 2,601 vulnerabilities, while CleanStart Python 3.14.6 reported 0.
The supplied severity breakdown for the official image is:
- 60 Critical
- 373 High
- 904 Medium
- 1,213 Low
CleanStart reported zero at each listed severity level.
These numbers should be interpreted as point-in-time Trivy scan results, not permanent properties of the image. Results can change as vulnerability databases, package versions, and image contents change.
Supply Chain Trust Goes Beyond an SBOM
Both images provide an SBOM, making it possible to inventory the software components they contain.
But an SBOM tells you what is inside an image. It doesn't tell you how the image was built or whether its origin can be independently verified.
The CleanStart image also includes:
- SLSA L3 provenance
- Sigstore signatures
Together, these provide additional supply-chain visibility and verification:
- Where did the image come from?
- How was it built?
- Can its provenance be verified?
- Can the image's signature be verified?
For container security, knowing what's inside an image is important. Knowing where it came from and being able to verify the artifact adds another layer of trust.
Conclusion
Python container security is about more than securing Python code and application dependencies.
The container environment itself becomes part of the application's security boundary.
Our benchmark of python:3.14.6 against CleanStart Python 3.14.6 demonstrates how significant that difference can be:
- 395.5 MB vs 44.3 MB
- 469 vs 53 installed packages
- 582 vs 68 executables
- 2,601 vs 0 reported CVEs
- Shell present in the official image and absent from CleanStart
- SBOM available for both images
- Provenance and signature support as part of CleanStart's supply-chain approach
The key takeaway is that Python container security is not only about the Python version or application dependencies. The underlying image determines how much additional software enters production, what runtime capabilities are available, and what supply-chain information can be verified. We found the same pattern when we ran this comparison for another language runtime: Official Go Docker Image vs CleanStart Go Image.
A secure production image should therefore be evaluated not only by size and vulnerability count, but also by its software footprint, runtime capabilities, SBOM, provenance, and artifact verification.
Try the CleanStart Community Images
Curious how your own applications compare?
Pull the equivalent CleanStart Community Image, scan it with Trivy, and compare the results in your own environment.
The Community Images are freely available for popular languages and runtimes and are built with a minimal software footprint, near-zero known vulnerabilities at release, SBOMs, SLSA-aligned provenance, and Sigstore signatures.
Explore the Community Images → images.cleanstart.com
Continue the Investigation
If you found this comparison useful, you may also enjoy these technical deep dives:
- Attack Surface Reduction in Containers: Measuring What Really Matters – Learn how package count, executables, and image composition influence container attack surface.
- Why SBOMs Alone Don't Establish Container Trust – Understand the difference between inventory and verification.
- Software Supply Chain Security: A Technical Imperative – Explore why provenance, signatures, and reproducible builds are becoming essential for modern software delivery.
