A container image can pass a scan during build and still become vulnerable later. The operating system packages and libraries in its base layer change over time, while teams may keep using the same image digest for weeks or months. Updating the base image helps only when the provider publishes a fix, the team rebuilds the application image, and the new version is tested and deployed.
Providers approach this maintenance differently. Some rebuild images from source and publish patch commitments. Others maintain a distribution or project with a defined support window. The distinction affects how much work stays with the application team, and what “continuously patched” means in practice.
Continuous Patching Is a Delivery Model, Not a Tag
A latest tag does not guarantee that an image is current, and a patched base image does not automatically update every application built on top of it. A provider may publish a fixed base, but teams generally still need to rebuild, test, and redeploy their own images. Vulnerabilities in application code, language packages, tools, and configuration also remain outside the base image unless the provider explicitly covers those layers.
When evaluating a provider, check four parts of its maintenance model:
- Coverage: Which operating system packages, runtimes, and libraries are included?
- Remediation terms: Does the provider publish response targets or an SLA for fixing vulnerabilities?
- Compatibility: Can the image stay on the runtime or distribution version the application requires?
- Release workflow: How are updates delivered, verified, and incorporated into your builds?
Some providers offer a managed image service with explicit remediation commitments. Others provide maintained image families or projects, where the support window and update cadence can vary by image or version. The profiles below reflect those differences.
8 Providers of Continuously Patched Container Base Images
1. Echo
Echo offers maintained container images designed to replace commonly used open-source images. Teams can switch the base image reference in a Dockerfile and continue building their application on top. Echo says its images are continuously rebuilt and updated, with vulnerability fixes applied to the base and library layers it maintains.
The company’s published patching terms set a target of triaging critical and high vulnerabilities within 24 hours and fixing them within up to seven days. Echo also describes signed images with SBOM, provenance, and VEX information, along with FIPS-validated and STIG-hardened variants. Those materials can help security teams review what an image contains and how it was built.
Echo’s model is aimed at teams that want a maintained replacement for their existing image without taking on the work of managing the base and supported library layers themselves. The handoff still matters: binaries, application code, and dependencies added by the customer need their own update and scanning process.
Key capabilities
- Continuously rebuilt replacement images for common container workloads
- Published vulnerability remediation targets
- SBOM, provenance, VEX, and image signing
- FIPS-validated and STIG-hardened variants
2. Chainguard Containers
Chainguard provides a catalog of minimal container images built around reduced package sets and frequent updates. Its images are intended to give teams maintained alternatives to familiar language, runtime, and application images. The catalog includes variants with different levels of compatibility, so teams can choose between smaller images and options that preserve more of the tools or packages their existing workflows expect.
Chainguard publishes image documentation and supply-chain information, including package details and image build data. Its support materials describe a vulnerability remediation SLA, though the exact service terms should be confirmed for the selected image and subscription. A migration may also require testing: minimal images can omit shells, package managers, or utilities that were available in the original image and quietly became part of a build or runtime process.
Key capabilities
- Catalog of minimal images for languages and common workloads
- Image documentation and package-level information
- Vulnerability remediation terms tied to the applicable service
- Multiple image variants to balance minimization and compatibility
3. Docker Hardened Images
Docker Hardened Images (DHI) are maintained images distributed through Docker’s ecosystem. They are designed to reduce unnecessary packages and provide a hardened starting point for production containers. Docker describes an event-driven build system that keeps images updated and publishes security information such as signed SBOMs, VEX statements, and provenance.
Docker’s documentation lists SLA-backed continuous patching, with critical CVE fixes targeted within seven days. Teams should check which image variants and service terms apply to their subscription, then validate how DHI fits with existing Dockerfiles, registries, and build pipelines. The smaller package set can reduce what needs to be scanned and maintained, but it may require adjustments if an application expects tools that are absent from the hardened image.
Key capabilities
- Docker-maintained minimal images for production workloads
- Published image signatures, SBOMs, VEX, and provenance
- SLA-backed patching terms for covered images
- Compatibility testing needed when replacing existing bases
4. RapidFort Curated Images
RapidFort provides curated container images built on established Linux distributions, including Alpine, Debian, and Red Hat-based options. Its approach combines image hardening with continuous scanning and patching, while aiming to keep images compatible with standard container workflows. RapidFort lists support for multiple distribution families and says its catalog includes images for teams that need to retain older versions.
RapidFort publishes remediation targets for certain vulnerability classes, including a one-day target for known exploited vulnerabilities and seven days for critical and high findings. Its product materials also describe compliance-related configurations such as FIPS and STIG alignment. Buyers should verify the specific image, operating-system version, compliance evidence, and contract terms they need; a provider’s catalog-wide claims may not apply identically to every image or package.
Key capabilities
- Curated images based on several established Linux distributions
- Continuous patching and scanning
- Published remediation targets for selected severity categories
- Compliance-oriented image configurations and metadata
5. Canonical Chiselled Ubuntu
Canonical’s Chiselled Ubuntu images use Ubuntu packages assembled into smaller, workload-focused filesystems. Chiselled images can omit components such as a shell or package manager from the final runtime image, reducing the amount of software included. Canonical also offers Ubuntu-based container maintenance through its standard and extended security programs.
The update model is tied to the underlying Ubuntu release and the applicable maintenance coverage. Canonical describes five years of standard security updates for core components, with longer coverage available through Ubuntu Pro for supported offerings. Its container services may also include maintained application layers, depending on the product. Teams should confirm that the exact image and packages they use are covered, especially when they need support for components outside the standard Ubuntu repositories.
Key capabilities
- Smaller Ubuntu-based images assembled with Chisel
- Runtime variants that can omit shells and package managers
- Security maintenance tied to Ubuntu releases and selected plans
- Options for supported runtimes and application containers
6. Red Hat Hardened Images
Red Hat Hardened Images are a catalog of security-focused container images designed to reduce attack surface and support enterprise deployment requirements. Red Hat positions them as a separate choice from Universal Base Image (UBI): the right option depends on the organization’s security needs, image requirements, and operating constraints.
For Red Hat Enterprise Linux and UBI content, Red Hat says critical and important security fixes are released as soon as possible, typically within hours or days. The company recommends automating image updates through CI/CD or continuously mirroring its registry, which leaves application teams responsible for bringing updated images into their build and deployment process. Confirm the support scope for the exact image and any added layers; a Red Hat base does not automatically cover packages installed by the application team.
Key capabilities
- Hardened image catalog for enterprise container workloads
- Distinct image choices, including Hardened Images and UBI
- Red Hat security updates for covered packages
- Guidance for automating pulls or registry mirroring
7. ActiveState Secure Containers
ActiveState’s Secure Containers are prebuilt images for language runtimes and common tools. The company says the images are rebuilt nightly and remediated according to published service targets: five business days for critical vulnerabilities, ten for high, and thirty for other vulnerabilities. Its offering is aimed at teams that want maintained language images without building and updating each runtime from scratch.
The scope of coverage matters. A secure runtime image can reduce risk in the operating-system and language-runtime layers it includes, but application dependencies added later still need to be tracked. Teams should map the provider’s image catalog to their actual runtime versions, package requirements, and build process, then verify how image updates are surfaced and how quickly they can be adopted after release.
Key capabilities
- Prebuilt images for popular languages and common utilities
- Nightly rebuilds, according to the provider
- Published remediation targets by vulnerability severity
- Image selection should account for added application dependencies
8. Google Distroless
Google Distroless is a project-maintained set of minimal container images containing an application runtime and its dependencies without a conventional Linux userland. Removing shells, package managers, and other general-purpose tools can reduce the image’s contents, but it also changes how teams debug and operate containers.
The project publishes and updates supported image families, with support timelines documented in its repository. It is a different maintenance model from a commercial image service with a provider-specific remediation SLA: teams need to track the support policy for each image and tag, and avoid deprecated tags that are no longer updated. This makes version and lifecycle management part of the adoption decision, alongside compatibility testing for applications that expect tools absent from a distroless image.
Key capabilities
- Minimal images for supported language and runtime families
- Project-maintained updates with documented support timelines
- No general-purpose shell or package manager in many variants
- Tag and lifecycle tracking remain important to the consuming team
Comparing the Maintenance Models
| Provider | Image model | Published maintenance signal |
| Echo | Rebuilt replacement images | Critical and high CVEs triaged within 24 hours; fixed within up to seven days |
| Chainguard | Minimal image catalog | Vulnerability remediation SLA; confirm terms for the selected service |
| Docker Hardened Images | Docker-maintained hardened images | SLA-backed continuous patching; critical fixes targeted within seven days |
| RapidFort | Curated images on established Linux distributions | Published targets include one day for KEVs and seven days for critical/high |
| Canonical | Chiselled and other Ubuntu-based containers | Coverage follows Ubuntu release and subscription terms |
| Red Hat | Hardened images and UBI | Critical/important RHEL package fixes typically released within hours or days |
| ActiveState | Prebuilt language and utility images | Published targets of 5, 10, and 30 business days by severity |
| Google Distroless | Project-maintained minimal images | Support timelines vary by image family and tag |
These are provider-published descriptions, not a guarantee that every image, package, or version has identical coverage. Compare the contract and support policy for the precise artifact you plan to deploy.
How to Evaluate a Provider in a Proof of Concept
A short proof of concept should test the image lifecycle, not just whether the container starts.
- Replace one representative base image. Choose a service with real dependencies and a test suite, rather than a trivial demo container.
- Check package and runtime compatibility. Verify required libraries, certificates, user permissions, startup commands, health checks, and debugging procedures.
- Inspect the image evidence. Confirm that signatures, SBOMs, provenance, and vulnerability reports are available in the format your security process uses.
- Simulate an update. Pull a patched image, rebuild the application image, run tests, and measure the work required to deploy it.
- Confirm coverage boundaries. Identify which layers the provider maintains and which dependencies remain your team’s responsibility.
- Review exceptions and support. Ask how the provider handles unsupported versions, disputed findings, delayed upstream fixes, and images that fail compatibility tests.
This process reveals whether “continuously patched” fits the team’s release model. A fast patch commitment still leaves operational work if the update cannot pass tests or reach production promptly.
Frequently Asked Questions
What does continuously patched mean for a container base image?
It means the provider maintains and releases updated image versions as security fixes become available, often through automated rebuilds. It does not necessarily mean a running container changes in place. Teams usually need to pull the new image, rebuild their application image, test it, and redeploy it. The provider’s SLA and the covered image layers define the actual commitment.
Does a patched base image remove vulnerabilities from the whole container?
No. A base image update addresses only the packages and components covered by that image. Language libraries, application dependencies, binaries, and configuration added by the team can still contain vulnerabilities. Review the provider’s coverage boundary, scan the final application image, and maintain a process for rebuilding and deploying it after a base image update.
Should teams choose a distroless image for every workload?
Not automatically. Distroless images reduce included components, which can reduce attack surface, but they also remove tools that developers may use for debugging or runtime operations. Teams should test how they diagnose failures, collect logs, handle certificates, and meet operational requirements before moving production workloads to a distroless variant.
What should buyers compare beyond CVE counts?
Compare remediation targets, image support lifecycles, package coverage, compatibility, provenance, signatures, update delivery, and the effort required to rebuild and deploy. CVE counts are useful but depend on scanners, package metadata, and exploitability context. A low count alone does not establish that an image meets the organization’s operational or compliance requirements.
