> For the complete documentation index, see [llms.txt](https://docs.sealsecurity.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.sealsecurity.io/setup-containers/seal-my-container/seal-image-fix-reference.md). # The seal image fix command and flags `seal image fix` is the Seal CLI subcommand that seals the OS layer of a pre-built container image. The image is pulled from a registry, rebuilt with the seal step inside a generated `Dockerfile`, and pushed back. The pull and push use the host's Docker credentials; the seal step uses the Seal token passed in as a BuildKit secret. ## Synopsis ``` seal image fix --platform [--tag ] [persistent flags] ``` The image is a **positional argument**, not a `--image` flag. The image reference is whatever form your Docker daemon understands (`registry/repo:tag`, `registry/repo@sha256:...`, or a short form against the default registry). ## Required arguments | Position | Meaning | | --------- | ------------------------------------------------------------------------------------------------------- | | `` | The fully-qualified reference of the image to seal. Must be pullable from the host running the command. | ## Flags `seal image fix` has two flags of its own; everything else comes from the persistent flag set shared with the rest of the CLI. | Flag | Required | Default | Meaning | | ------------ | -------- | ---------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `--platform` | yes | — | The Docker platform to pull and build for, in the same syntax as `docker --platform` (`linux/amd64`, `linux/arm64`, and so on). Required even when the image is single-architecture; the CLI passes the value through to `docker pull` and `docker build`. | | `--tag` | no | the source image's reference | The fully-qualified reference to push the sealed result to. If omitted, the sealed image is pushed back to the exact same reference it was pulled from — overwriting the source tag in place. **This is the canonical pattern**: every deployment that already pulls the original reference picks up the sealed version on its next pull, with no manifest, no `Dockerfile`, and no Helm-values changes. Pass `--tag` only when you specifically want the sealed result to land at a different reference (a parallel tag, a different repository, or a separate registry). | Persistent flags relevant to `seal image fix`: | Flag | Meaning in the `image fix` context | | ---------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `-v` / `-vv` / `-vvvv` | Verbosity. The output of the underlying `seal fix --os` step inside the build appears in the build log; higher verbosity prints more detail when diagnosing a problem. | | `--config ` | Path to a Seal CLI config file (`.seal-config.yml`). The same configuration model as the rest of the CLI applies. | | `--clean` and `--remove-cli` | Passed through to the inner `seal fix --os` step. The CLI sets `--remove-cli` automatically inside the generated `Dockerfile` so the binary does not ship in the resulting image. | ## Environment variables | Variable | Required | Purpose | | ----------------------- | -------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `SEAL_TOKEN` | Yes | The Seal token, passed into the build via BuildKit's `--secret id=SEAL_TOKEN,env=SEAL_TOKEN`. It is not baked into the resulting image. | | `SEAL_PROJECT` | Yes | The Seal Project ID to attribute the seal to. The first run with a `SEAL_PROJECT` value that does not exist creates the project automatically. | | `SEAL_USE_SEALED_NAMES` | No | Set to `1` to rename sealed packages inside the image so external scanners do not flag them. See [Renaming packages inside containers](/setup-containers/seal-my-container/renaming.md). Defaults to off. | The same `SEAL_PROJECT` caveat that applies to `seal fix --os` applies here: if the same image build also runs `seal fix` for application dependencies separately, **use a different `SEAL_PROJECT`** for the two so the second scan does not bury the first's discovery on the Protection page. The mechanism is documented in [Seal OS in CI/CD](/setup-apps-os/seal-os-cicd.md#use-a-separate-seal-project-for-seal-fix-os). ## What runs under the hood `seal image fix` is a thin wrapper around three `docker` invocations: 1. `docker pull --platform ` — fetches the source image into the local Docker daemon. 2. `docker build --secret id=SEAL_TOKEN,env=SEAL_TOKEN -t -f .` — runs a build whose `Dockerfile` is generated by the CLI. BuildKit must be enabled (it is by default in current Docker versions). 3. `docker push ` — pushes the sealed image to the destination registry. The generated `Dockerfile` is `FROM ` followed by two `RUN` steps: 1. `seal fix --os --mode=all --clean` — seals the OS-package layer. Same logic as the standalone command documented in [Seal OS in CI/CD](/setup-apps-os/seal-os-cicd.md). 2. `seal fix --fs java / --mode=all --clean` — recursively scans the image's filesystem from `/` for JAR files and seals any whose contents match a vulnerable library Seal recognizes. This is the post-build application-layer step; it covers JARs the image already shipped with, including JARs you did not build yourself. The generated `Dockerfile` is written to a temporary working directory and removed after the build. It is not customer-editable. To seal Python wheels in addition to OS packages and JARs, run `seal fix --fs python ` against the relevant directory in a custom `Dockerfile`. See [Seal Vendor Apps](/setup-containers/seal-vendor-apps.md) for the pattern. ## Example The canonical invocation, which seals the image in place and pushes back to the same tag: ```bash export SEAL_TOKEN= export SEAL_PROJECT=my-app-image seal image fix \ my-registry.example.com/my-app:1.0.0 \ --platform linux/amd64 ``` After this completes, `my-registry.example.com/my-app:1.0.0` in the registry is the sealed version; the unsealed bits are gone. Every consumer that pulls the tag on its next run gets the sealed image without any change to its `Dockerfile`, Helm values, or deployment manifest. To land the sealed result at a different tag (for example, to keep the unsealed version around for rollback or comparison), add `--tag`: ```bash seal image fix \ my-registry.example.com/my-app:1.0.0 \ --platform linux/amd64 \ --tag my-registry.example.com/my-app:1.0.0-sealed ``` This pushes the sealed image to `my-app:1.0.0-sealed` and leaves `my-app:1.0.0` untouched. Use this form when downstream pull policy is explicit about which tag to pick up. ## Multi-architecture images `seal image fix` operates on a single platform per invocation, set by `--platform`. For a multi-arch image, run the command once per architecture and assemble the manifest list afterwards with `docker buildx imagetools create` or the equivalent: ```bash seal image fix my-registry.example.com/my-app:1.0.0 --platform linux/amd64 --tag my-registry.example.com/my-app:1.0.0-sealed-amd64 seal image fix my-registry.example.com/my-app:1.0.0 --platform linux/arm64 --tag my-registry.example.com/my-app:1.0.0-sealed-arm64 docker buildx imagetools create \ -t my-registry.example.com/my-app:1.0.0-sealed \ my-registry.example.com/my-app:1.0.0-sealed-amd64 \ my-registry.example.com/my-app:1.0.0-sealed-arm64 ``` Wrap this in a small script when you need it; the CLI does not provide a single-shot multi-arch convenience flag. ## Exit behavior The command exits with status `0` when it has successfully pushed the sealed image. A non-zero exit means one of the underlying steps failed; common causes are documented in [Common issues](/setup-containers/seal-my-container/common-issues.md). The CLI's stderr names the specific failure — usually a Docker error (pull denied, push denied, build failed) or a Seal error (token rejected, image's distribution unsupported). ## Related * [Authenticating with your container registry](/setup-containers/seal-my-container/authenticating-registry.md): the registry credentials the underlying `docker pull` and `docker push` use. * [Implementing the centralized re-seal pipeline](/setup-containers/seal-my-container/centralized-pipeline.md): the canonical production setup that calls this command. * [Common issues](/setup-containers/seal-my-container/common-issues.md): the failures that come up most often. * [Seal OS in CI/CD](/setup-apps-os/seal-os-cicd.md): the parallel chapter that runs the same seal step inside a `Dockerfile` you write yourself.