Press play to start listening
Almost every containerized application is built on top of base images. They provide the operating system packages, runtime libraries and core components needed for the workload to run. For many years, many large organizations have been developing and maintaining their own in-house images to manage security, compatibility, and compliance. That used to be the safest way, but the burden of operation is increasingly difficult to justify.
The increasingly popular and ever-growing market of Secure base images for containerized applications is providing enterprises with an additional option. Organizations do not need to keep all the base packages in-house; externally managed images are constantly patched, scanned, signed and documented. The use of trusted base images is no longer a question of whether they are needed, but whether the effort to build them in-house is best spent.
Internal Images Offer Control
Control is the best reason to build base images from within the organization. Enterprises can determine which packages are included, which repositories to trust and which configurations are applied by default. They can also customize images for internal infrastructure, application frameworks, and regulatory needs.
This may be useful in very specific settings. A financial institution, defense contractor, or healthcare provider might require certain cryptographic modules, monitoring agents, or compliance controls that aren’t offered in a typical public image.
Internal ownership can also help make governance easier. Cybersecurity teams can share a small list of approved images and block the developers from using arbitrary images from public registries. Each application starts with a solid base, minimizing variations between development teams. But organizations can only be secure if they can effectively control it.
Maintenance Is the Real Cost
Creating a base image is fairly simple. It is very difficult to keep it going all the time.
Vulnerabilities need to be monitored in packages for operating systems, language runtimes, certificates and supporting libraries across the teams. If a critical issue is revealed, then engineers should identify which images should be affected, apply the patch, rebuild all variants, test for compatibility and publish updated versions.
That work doesn’t end after the first release. Base images must be owned and have clear service level expectations and consistent automation. The same image that was once secure may have outdated packages and known vulnerabilities in it now, six months later.
Many internal image programs start as side projects and are owned by platform or cybersecurity teams. They become business-critical infrastructure over time but are not staffed as such. This may lead organizations to have supposedly trusted images that are patched less often than professionally maintained images.
External Providers Can Reduce Vulnerability Backlogs
Commercial and open-source hardened image providers are geared towards ensuring secure foundations for images. Their services can include frequent rebuilds, minimal package sets, software bills of materials, signatures and provenance records.
The same base image can serve multiple customers, so providers can put significant resources into automating and hiring security experts. A vulnerability can be patched at the base level and across a wide range of applications.
For example, this model can help decrease the number of CVEs that enterprise security teams must investigate. It can also reduce the time from when a patch is available upstream to when the new image is available in production.
But outsourcing the maintenance does not absolve you of responsibility. Businesses must still check image signatures, evaluate update policies, and test new versions before deployment.
Compatibility Can Complicate Migration
But it’s not always easy to let go of inner pictures. Applications can rely on packages, file paths, user permissions, or debugging tools that are part of the foundation.
Minimal images can cause unexpected issues. When removing a shell, package manager, or OS utility, this may enhance security but could make production troubleshooting more challenging. Applications can also use older libraries which are not present in the hardened replacement.
This can then create disruption when there is a sudden organization-wide migration. Before making the change to another foundation, enterprises must test workloads one by one and determine the hidden workload dependencies.
Slow and steady is the best way to go. Older applications can be moved during scheduled downtime, and new services can use images maintained in the external service first.
A Hybrid Model May Be More Practical
It is not a case of all or nothing when it comes to ownership of enterprises. A hybrid model can provide a better balance.
Starting with a trusted external image, organizations can implement a thin internal layer with the certificates, monitoring tools, or configuration standards needed. This will reduce the amount of software the company needs to maintain while still retaining essential personalization.
Security teams can still determine which images are approved and require deployment by digest, not by a changing tag. They can also reflect images from the outside world into a private registry, and check signatures and scan them against internal policies. This is done without forcing internal teams to rebuild an enterprise security boundary, the operating system foundation.
Enterprises Should Build Only When It Creates Real Value
It’s a mistake to think that managed alternatives exist so that enterprises should not continue to build their own base images. They should cease when internal maintenance no longer offers a significant security, compliance, or operational benefit.
But complete ownership could still be advantageous for companies that have a unique set of technical needs and established platform teams. For many others, it’s just a part of the job, updating OS packages, but not the application itself, and not a job they particularly enjoy.
A more effective plan is to consider the full responsibility, rather than just the initial cost. Base images should be patched, tested, traceable and supported over the whole life cycle. An external provider may be able to do that work more consistently, and a managed secure foundation may decrease risk and complexity.
(Photo by Erik Mclean on Unsplash)