live wire
▸Red Hat ships important MicroShift 4.16.73 security updateRed Hat Product Errata▸AI · Red Hat maps local AI Inference serving and load tests on RHEL (Oct. 15)Red Hat Emerging Technologies▸PLATFORM · IBM guide maps Secure Execution VMs onto OpenShift Virtualization for LinuxONEIBM Community▸AI · vLLM maps Nemotron 3.5 Super VL across Hopper, Blackwell and Red Hat DSpark (Oct. 15)vLLM Recipes▸AI · AWS contributes push-based KV transfer to vLLM, reporting 3x better TTFT under loadAWS Machine Learning Blog▸AI · AWS contributes bidirectional KV transfer to vLLM, cutting multi-turn TTFT up to 3.3xAWS Machine Learning Blog▸AI · vLLM Semantic Router adds d3-turbo with box and video-tracking decisionsvLLM Semantic Router▸IDENTITY · Keycloak DevDay 2027 opens call for deep technical talks through Oct. 24Keycloak▸AI · vLLM Recipes maps Muse Spark Open to single-node Blackwell and AMD deployment (Oct. 16)vLLM▸PLATFORM · Clang 23 bytecode interpreter cuts allocations and expands constant-expression supportRed Hat Developer▸PLATFORM · RHEL becomes first-party on OCI; OpenShift subscriptions reach Oracle MarketplaceRed Hat▸AI · vLLM-Omni merges native MOSS-Image serving with parallelism and offloadvLLM▸AI · vLLM adds System One endpoint for Decision 3.0 multimodal routing models (Oct. 15)vLLM▸SECURITY · Red Hat rates OpenShift AI 3.4.5 update Critical; advisory lists hundreds of CVEsRed Hat Product Security▸Red Hat ships important MicroShift 4.16.73 security updateRed Hat Product Errata▸AI · Red Hat maps local AI Inference serving and load tests on RHEL (Oct. 15)Red Hat Emerging Technologies▸PLATFORM · IBM guide maps Secure Execution VMs onto OpenShift Virtualization for LinuxONEIBM Community▸AI · vLLM maps Nemotron 3.5 Super VL across Hopper, Blackwell and Red Hat DSpark (Oct. 15)vLLM Recipes▸AI · AWS contributes push-based KV transfer to vLLM, reporting 3x better TTFT under loadAWS Machine Learning Blog▸AI · AWS contributes bidirectional KV transfer to vLLM, cutting multi-turn TTFT up to 3.3xAWS Machine Learning Blog▸AI · vLLM Semantic Router adds d3-turbo with box and video-tracking decisionsvLLM Semantic Router▸IDENTITY · Keycloak DevDay 2027 opens call for deep technical talks through Oct. 24Keycloak▸AI · vLLM Recipes maps Muse Spark Open to single-node Blackwell and AMD deployment (Oct. 16)vLLM▸PLATFORM · Clang 23 bytecode interpreter cuts allocations and expands constant-expression supportRed Hat Developer▸PLATFORM · RHEL becomes first-party on OCI; OpenShift subscriptions reach Oracle MarketplaceRed Hat▸AI · vLLM-Omni merges native MOSS-Image serving with parallelism and offloadvLLM▸AI · vLLM adds System One endpoint for Decision 3.0 multimodal routing models (Oct. 15)vLLM▸SECURITY · Red Hat rates OpenShift AI 3.4.5 update Critical; advisory lists hundreds of CVEsRed Hat Product Security
upstreambeat.ai
guideSUPPLY CHAIN

A two-line move to Red Hat Hardened Images cut one Go container by 84%

Red Hat’s worked example pairs a smaller distroless runtime with signed builds, SBOMs and automated daily redeployment—but teams still need to test each rebuilt artifact.

Old Go container shrinks to a hardened minimal image.
Side by side: what changed
By The News Desk· Oct 8, 2026the quick take — two AI hosts go live when you do

Red Hat has published a compact migration example for its Hardened Images service: replace the builder and runtime base-image lines in a Go application’s Dockerfile, then automate rebuilds as updated bases arrive. In Red Hat’s account, the change reduced the application image from 218 MB to 35 MB—an 84% drop.

The useful part is not the headline number alone. The example links image minimization to a continuing rebuild process rather than treating a small image as a one-time security result.

What the pattern changes

The original application carried components it did not need, including a shell, package manager and curl. Red Hat’s replacement uses a Go builder image and a static runtime image from a catalog that the company says spans roughly 100 runtimes and services, including Go, Python, Node.js, Java, Ruby, PostgreSQL and Nginx.

That removes unused software from the final artifact. Red Hat says the images are produced with SLSA Level 3 supply-chain controls, signed with cosign and accompanied by a verifiable software bill of materials. Those properties give a platform team evidence to check; they do not eliminate the need to verify provenance and compatibility in its own pipeline.

The operational step matters more

The worked example adds a daily workflow that pulls an updated hardened base, rebuilds the application and redeploys it. Red Hat says this keeps the running workload no more than 24 hours behind a patched base in this setup. The company reports a current median of 18 hours for its image pipeline to deliver vulnerability fixes, against a service-level objective of delivering 80% within seven days.

Those are vendor-reported pipeline figures, not a universal remediation time. An application can still carry vulnerabilities in its own dependencies, and an automatic base-image rebuild can introduce a regression. Teams adopting the pattern should retain tests, signature verification, SBOM inspection and promotion controls between rebuild and production.

What platform teams should try

A sensible first trial is a statically linked service whose runtime requirements are easy to enumerate. Compare the old and new images for size, package inventory and startup behavior; verify the cosign signature and SBOM; then run the normal integration and policy gates before promotion.

The larger lesson is straightforward: changing the base image shrinks today’s attack surface, while a tested rebuild-and-promotion loop determines how quickly tomorrow’s fixes reach a workload. Red Hat’s two-line Dockerfile example makes the first step unusually small, but the surrounding automation is the part that turns it into a supply-chain practice.

Filed by The News Desk. Corrections: desk@upstreambeat.ai · Our standards →

comments · 0

    Comments are moderated before they appear. Your email is used once to confirm it is you — never shown, never sold. Corrections and questions get an answer from the desk when we have one.