Rolling out a patched container image without changing your registry or your manifests
Do not point clusters at a new registry. Copy the fixed image into the registry they already pull from, by digest (crane copy or skopeo copy --all), and change the image in Git with a kustomize image override or a Helm value. To own the build, rebuild it from a Dockerfile that pins the original by digest and applies the same upgrades; to stop the CVEs coming back, fix the source Dockerfile with a pull request.
- 01Promoteinto your registry, by digest
- 02Roll outkustomize / Helm change in Git
- 03RebuildDockerfile.ocimend in your CI
- 04Fix the sourcepull request to the Dockerfile
1. Promote into the registry you already trust
Admission policies, pull secrets and mirrors are all set up for your internal registry. Copy the fixed image there, all architectures, and keep the digest:
crane copy ocimend.io/nginx:1.27-fixed registry.acme.io/platform/nginx:1.27-fixed # or skopeo copy --all docker://ocimend.io/nginx:1.27-fixed docker://registry.acme.io/platform/nginx:1.27-fixed
2. Change the reference where it lives: in Git
| You deploy with | Change |
|---|---|
| kustomize | images: [{{name: nginx, newName: registry.acme.io/platform/nginx, digest: sha256:…}}] |
| Helm | --set image.repository=registry.acme.io/platform/nginx --set image.tag=1.27-fixed |
| plain manifests | kubectl set image deploy/web nginx=registry.acme.io/platform/nginx@sha256:… |
A digest reference makes the rollout exact and the rollback a revert.
3. Rebuild it yourself when you must
Every OCImend fix comes with Dockerfile.ocimend: the original image pinned by digest, the package
upgrades, and any Go programs rebuilt from their own source with a patched toolchain. Build and sign it in your own
pipeline; the result is the same fix, built by you.
4. Fix the Dockerfile it came from
A patched image fixes today. A pull request to the source Dockerfile fixes every build after it: bump the Go builder image, add the upgrade step in the final stage, and state the before/after numbers in the description. OCImend previews the diff first, and the token is used once for that request.
Keep the link to the source
Fixed images carry io.ocimend.source, org.opencontainers.image.base.name and
org.opencontainers.image.base.digest, and /api/provenance?image=… returns the source, what
changed and how it was verified, for auditors and inventory jobs.
Fix an image and adopt it your way →
Questions
Should I use a tag or a digest in Kubernetes?
Does copying keep multi-arch images?
Where do I find which image a fixed one replaced?
Sources
More guides
- How to build FIPS-enabled containers (FIPS 140-3)
- OCImend FIPS containers: what you get and how they are verified
- How to fix container image CVEs automatically
- A container vulnerability pipeline that ends in a fix, not a report
- "No fix available": what to do about unfixable container CVEs
- Base image or your layers? Finding which Dockerfile step introduced a CVE
- EU Cyber Resilience Act for container images: SBOM, VEX and 24-hour reporting