Seal Vendor Apps

Seal the open-source content of vendor-supplied container images you run.

Seal Vendor Apps is for vendor-supplied container images — for example, a Kafka image from Confluent — that your team runs as-is without building. The seal step replaces the open-source content inside the vendor image (OS packages, language runtimes, bundled open-source artifacts) while leaving the vendor's own application code untouched. The result is a sealed copy of the vendor image that you push to your own private registry and deploy from internally.

Why this is a separate product

Mechanically, the seal step is the same OS-and-runtime sealing that drives Seal OS in CI/CD and Seal My Container. What makes Seal Vendor Apps distinct is the operational context:

• Seal cannot publish a sealed copy of the vendor's image. Vendor licenses typically forbid redistribution. That rules out a Seal Base Images-style flow where Seal hosts a pre-sealed copy you pull from Seal's registry.

• You apply the seal in your own environment. The sealed result lives inside your private registry, for your own internal use. It is not redistributable: do not push it to a public registry, do not share it across organizational boundaries, and do not treat it as a derivative work you can ship. The licensing posture of the sealed image is the same as the licensing posture of the unsealed vendor image — sealing does not change what the vendor's license permits.

• The vendor's application code stays as the vendor shipped it. The seal step only touches the OS layer, the language runtime, and any bundled open-source dependencies the vendor included (typically JAR files, with Python wheels as a secondary case). The vendor's own binaries, configuration, and proprietary libraries are not modified.

What gets sealed inside a vendor image

A vendor container typically packs three kinds of content:

• OS packages from the base distribution (apk / deb / rpm).

• Already-built open-source artifacts that the vendor compiled into the image: JAR files, Python wheels, and similar. These are post-build artifacts, not manifests; the vendor's own source is not in the image.

• The vendor's proprietary code, configuration, and scripts, which ship under their own license.

The Seal CLI has a separate sealing path for each of the first two:

• seal fix --os seals the OS-package layer. Same mechanism as Seal OS in CI/CD.

• seal fix --fs <ecosystem> seals already-built application artifacts on the image's filesystem. --fs java recursively scans for vulnerable JARs and rewrites them with sealed content; --fs python does the same for wheels. This is the complementary step to Seal OS for any image whose application layer was built outside your own build pipeline. Vendor images are the canonical case, but the same technique applies whenever you need to seal JARs or wheels you did not build from source.

The vendor's proprietary code is the third category and is never modified by either step.

Two ways to run the seal step

Both approaches produce equivalent sealed images. The choice is mostly about how much control you want over the surrounding Dockerfile.

• seal image fix <vendor-image> — the CLI orchestrates docker pull, generates a one-stage wrapper Dockerfile that runs both seal fix --os and seal fix --fs java / inside (sealing the OS layer and any JAR files anywhere in the image), runs docker build, and pushes the result to the destination tag you supply via --tag. The simpler path; one command. Covered by the seal image fix reference in the Seal My Container chapter (the command is the same).

• A Dockerfile that runs the sealing steps yourself — you write a Dockerfile whose FROM line references the vendor image, drop in the Seal CLI, and run the sealing steps as explicit RUN lines: seal fix --os for the OS layer, plus seal fix --fs java <path> and seal fix --fs python <path> for whichever directories of artifacts you want sealed. Your team controls every flag (--silence for known false positives, --summarize to a specific log path, additional RUN steps before or after the seal). Slightly more code; more flexibility. The OS-side mechanics are the same as Sealing OS packages in a Dockerfile, just with a vendor FROM line.

Pick the first when the default behavior is what you want. Pick the second when you need explicit control over the surrounding build, when the vendor packed artifacts in non-default locations the seal image fix defaults do not cover, or when the image has Python wheels to seal.

Sealing against a moving vendor tag

The seal step can operate against any reference the vendor publishes, including moving tags like :latest. A pipeline that re-runs the seal step on a schedule against confluentinc/cp-kafka:latest always pulls whichever release the vendor has currently tagged as latest, then seals it. The resulting sealed image in your registry is pinned (you control its tag), even though the source was moving.

This is the recommended pattern for most teams: re-seal on a schedule against the vendor's current release tag, so the sealed copy in your registry stays current as the vendor publishes new versions. The alternative — pin to a specific vendor version and re-pipeline when you decide to roll forward — is also workable, but it requires explicit version tracking.

Chapter contents

• Implementing the vendor-image pipeline: both approaches above, with the surrounding CI shape, tag conventions, renaming for external scanners, and how deployments reference the sealed result.

Before you start

• A vendor image you run, and a Docker login that already pulls it. (If you already deploy from the vendor's image, this is in place.)

• A private registry you own and control, with write access for the seal pipeline.

• Docker installed on the host where the seal step runs.

• The Seal CLI installed on the host (or downloaded as a RUN ADD step inside the Dockerfile).

• SEAL_TOKEN and SEAL_PROJECT set in the host's environment.

Related

• Seal Vendor Apps: the product-family page.

• Seal My Container: the sister product for sealing images your team builds itself.

• Sealing OS packages in a Dockerfile: the Dockerfile pattern referenced by the second approach above.