Redis is widely used as a cache, in-memory database, message broker, and high-performance data store. When Redis runs in production, however, its security depends on more than the Redis software itself. The Docker image and container foundation also determine what packages, executables, utilities, and runtime capabilities are included.
A larger software footprint means more components to inventory, monitor, patch, and secure.
This is where Redis container security becomes important.
In this comparison, we evaluate the official redis:8.10.0 Docker image against cleanstart/redis:8.10.0, using the same Redis version to examine differences in image size, packages, executables, vulnerabilities, runtime capabilities, and software supply-chain verification.
Comparison Baseline
Compared Item | Value |
Runtime | Redis 8.10.0 |
Public Image | |
CleanStart Image | |
Scanner | Trivy v0.74.0 |
Scan Method | Same configuration for both images |
Scan Date | Aug 21, 2026 |
Official Redis vs CleanStart Redis
The comparison shows how much the underlying container foundation can change while keeping the Redis version identical.
Metric | Public Redis | CleanStart Redis |
|---|---|---|
Redis Version | 8.10.0 | 8.10.0 |
Image Size | 148.0 MB | 46.3 MB |
Installed Packages | 78 | 25 |
Executables | 316 | 51 |
Total CVEs | 185 | 0 |
Critical | 4 | 0 |
High | 47 | 0 |
Medium | 64 | 0 |
Low | 65 | 0 |
Unknown | 5 | 0 |
Shell | ✓ | ✗ |
Package Manager | ✓ | ✗ |
BusyBox | ✓ | ✗ |
SBOM | ✓ | ✓ |
Non-root Runtime | ✗ | ✓ |
Provenance | Not published | SLSA Build Level 3, cryptographically verified |
Signature | Not detected | Cosign keyless, Rekor-logged (verified) |
What the Scan Revealed
148 MB vs 46.3 MB: A Smaller Redis Container Image
The official Redis image is approximately: 148.0 MB
The CleanStart Redis image is: 46.3 MB
That's approximately a 69% reduction in image size.
A smaller container image requires less software to transfer, store, scan, inventory, and maintain.
But image size alone does not determine container security.
A better question is:
What software is actually included in the Redis image?
That's where the package and executable comparison becomes important.
How Many Packages Are Included?
The official Redis image contains: 78 installed packages
The CleanStart image contains: 25 installed packages
That's approximately 68% fewer packages.
Reducing the number of packages reduces the amount of software that needs to be tracked and maintained throughout the container's lifecycle.
It also helps reduce unnecessary dependencies from the production runtime.
How Many Executables Are Included?
The benchmark identified:
- 316 executables in redis 8.10.0
- 68 executables in CleanStart redis 8.10.0
That's approximately 84 fewer executables.
A production Redis 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 Redis Docker Image Have?
The Trivy scan reported 185 total CVEs in the official Redis image:
- 4 Critical
- 47 High
- 64 Medium
- 65 Low
- 5 Unknown
The CleanStart Redis image returned:
0 Critical
0 High
0 Medium
0 Low
0 Total
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.
A Hardened Redis Image Without a Shell
One of the differences between the two images is the availability of a shell.
A shell can be useful for development, debugging, and troubleshooting.
But a production Redis container does not necessarily need an interactive shell.
Removing it eliminates unnecessary runtime functionality and makes the production image more focused on its intended workload.
This follows a straightforward container-hardening principle:
If the application does not need it at runtime, don't ship it at runtime.
No Package Manager in the Final Runtime Image
The CleanStart Redis image also removes the package manager from the final image.
This is an important distinction for production containers.
A package manager is useful for installing and managing software during image construction. It does not necessarily need to remain available inside the production runtime.
Removing it means software cannot simply be installed interactively inside the running container.
The CleanStart build process removes the package-management tooling before the final image is produced.
No BusyBox in the Final Image
The same principle applies to BusyBox.
The CleanStart build removes BusyBox from the final image along with package-management tooling.
That means the final runtime does not carry a collection of general-purpose Unix utilities that Redis does not require to perform its primary workload.
The objective is simple:
Build with what you need. Run with what you need. Remove the rest.
Redis Runs as a Non-Root User
Container hardening is not only about reducing software.
It is also about reducing privileges.
The CleanStart Redis image runs Redis as a dedicated non-root user, Redis is launched directly as root user
Running the application without root privileges follows the principle of least privilege.
If a process is compromised, restricting its privileges can limit what that process can do within the container.
This gives us another important dimension of Redis container security:
Security is not only about what is installed. It is also about what the running process is allowed to do.
Container Security Goes Beyond an SBOM
A stronger software foundation needs to answer three different questions.
SBOM
What is inside the image?
An SBOM provides visibility into the components that make up the container.
Provenance
Where did the image come from, and how was it built?
Provenance provides evidence about the origin and build process of the software artifact.
Signature
Can I verify the artifact I am consuming?
A cryptographic signature allows consumers to verify the integrity and authenticity of the signed artifact.
CleanStart combines these capabilities to provide a more verifiable software foundation.
Conclusion
Redis container security is about more than securing the Redis process itself.
The container environment becomes part of the application's security boundary. Every package, executable, utility, and runtime capability included in the image becomes part of what needs to be understood, monitored, and secured.
The comparison between the official Redis image and CleanStart Redis shows what changes when that foundation is deliberately minimized. A smaller software footprint, fewer runtime capabilities, non-root execution, and stronger supply-chain verification can reduce what enters production without changing the Redis version itself.
We found the same pattern when comparing another language runtime: Official Go Docker Image vs CleanStart Go Image.
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
