Updating to a new base image release

Roll forward when Seal publishes a newer sealed iteration of the upstream image you depend on.

Seal publishes new sealed iterations of each base image when:

• A newly disclosed vulnerability in the underlying packages has a backportable fix, and the next iteration (sp2, sp3, and so on) includes it.

• The upstream image publishes a new build of the same tag (a new build-timestamp), and Seal seals the new build.

Either way, the published reference changes. Your Dockerfiles, Helm charts, and Kubernetes manifests are pinned to a specific reference, so they keep pulling the previous sealed iteration until you choose to roll forward.

This is deliberate. Builds against a stable reference are reproducible; updates are explicit moments in your delivery process where the team gets to review, test, and approve the change.

How to learn that a new iteration shipped

Your Seal account team notifies you when a new sealed iteration of an image you depend on becomes available. For high-severity disclosures that drive a new iteration on short notice, the same channel applies. If you want to confirm the latest available iteration for an image you already use, ask your account team directly.

The update mechanics

The update is a one-line change to the FROM reference. For a Dockerfile:

- FROM <seal-registry>/python:3.12.9-slim-bullseye-20250408T180700Z-sp2
+ FROM <seal-registry>/python:3.12.9-slim-bullseye-20250408T180700Z-sp3

For a Helm values file:

  image:
    repository: <seal-registry>/python
-   tag: 3.12.9-slim-bullseye-20250408T180700Z-sp2
+   tag: 3.12.9-slim-bullseye-20250408T180700Z-sp3

Commit, build, test, deploy. Treat the change like any other base-image bump.

Iterating the sealed iteration only vs. moving the build-timestamp

Two distinct kinds of update:

• Sealed-iteration bump (sp2 → sp3): same underlying upstream snapshot, more vulnerabilities sealed. Low-risk; the underlying packages are unchanged, only patched. The diff is the set of newly sealed CVEs.

• Build-timestamp bump (20250408T180700Z → 20250612T134200Z): a different upstream snapshot of the same tag. The upstream image author published a new build; Seal sealed the new build. This is a larger change because the underlying packages may have moved (kernel headers, distro patches, third-party packages bundled with the language runtime); review accordingly.

Either way, the reference is one immutable string. There is no rolling tag for a sealed image; every reference resolves to one specific image both today and tomorrow.

Rolling back

The previous sealed iteration is still available in the registry; rolling back is the same one-line change in the reverse direction:

- FROM <seal-registry>/python:3.12.9-slim-bullseye-20250408T180700Z-sp3
+ FROM <seal-registry>/python:3.12.9-slim-bullseye-20250408T180700Z-sp2

Rollbacks should be rare. Sealed iterations preserve the package layout and behavior of the upstream image; a regression specific to a sealed iteration is uncommon. If you encounter one, roll back, then contact your Seal account team with the symptoms — the same channel they would use to advise on a new iteration.

Coordinating with mirrors

For environments that mirror sealed images into an internal registry, the update flow has one extra step: copy the new iteration into the internal registry before the FROM change lands, so the build does not stall on a missing image.

The order is:

1. crane copy (or equivalent) the new iteration into the internal registry.

2. Open the PR with the FROM update.

3. Merge once the mirror is in place and CI passes.

For continuous-mirror setups (Harbor pull-through, ECR Pull Through Cache, and so on), step 1 happens automatically on first pull; the explicit copy is only needed for one-shot mirrors.

Coordinating with Sealing Rules

Seal Base Images sit outside the Sealing Rule model. Sealing Rules govern how the Seal CLI replaces vulnerable packages inside a customer-built image or codebase. A base-image update is not a Sealing Rule change; it is a base-image-reference change, owned by whoever owns the relevant Dockerfile or Helm chart in your team's IaC.

The corollary: a base-image-only deployment does not need Sealing Rules at all. Customers who use Seal Base Images exclusively (no seal fix step, no manifest-pinning) and the Sealing Rules tab is empty are operating the platform correctly.

Related

• Pulling a sealed base image: the reference format the update changes.

• Mirroring to your internal registry: the mirror-coordination step in the update flow.

• Using Seal Base Images with Kubernetes and Helm: the Helm-values pattern for the bump.