> 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/using-platform/working-with-seal-vendor-apps.md). # Working with Seal Vendor Apps Seal Vendor Apps seals vendor-supplied container images — Confluent's Kafka image, Oracle's database images, a vendor-shipped runtime, and so on — that you run without building yourself. The pipeline pulls the vendor's image, seals its OS layer and bundled open-source content, and pushes a sealed copy to your private registry. Your deployments then pull from there instead of from the vendor's registry. The day-2 rhythm parallels Seal My Container: a pipeline runs, produces a sealed image, your deployments pick it up. The mechanics differ in three ways — the source image is the vendor's (you don't control when it changes), the destination tag is in your registry (not the source registry, because the sealed copy is not redistributable), and the trigger is either a schedule or a vendor-release event (not a customer-side push). Setup mechanics — `seal image fix` vs the custom-`Dockerfile` approach, registry authentication, tag conventions — live under [Seal Vendor Apps](/setup-containers/seal-vendor-apps.md). This chapter covers the recurring rhythm. ## The recurring rhythm The four steps from [Working with the platform](/using-platform/working-with-the-platform.md), specialized for Seal Vendor Apps: 1. **Review** the Vulnerable packages tab on the [Protection page](/discovering/protection-page.md), filtered to the Seal Project the pipeline reports to. Rows arrive as the pipeline runs against each vendor image you track. 2. **Decide what to seal.** The seal step always runs in all mode and replaces every vulnerable OS package and every vulnerable JAR Seal has a sealed version for. There is no per-rule control; the decision is per vendor image (which images flow through the pipeline) and per cadence (how often to re-seal them). 3. **Let the pipeline run.** A scheduled job or a vendor-release-triggered job invokes `seal image fix` (or the equivalent custom-`Dockerfile` build) against the vendor image, producing a sealed copy under a tag in your private registry. 4. **Verify.** The Protection page reflects the seal step's outcome — rows move to **Sealed** as the pipeline reports its run. Your deployments roll forward to the new sealed tag through your normal release process.
The Protection page on the Vulnerable packages tab

The Protection page reflects each vendor-image seal pass.

## Two trigger patterns Both are documented in the setup chapter; the day-2 implications: * **Scheduled against a moving vendor tag.** A periodic job runs the pipeline against `confluentinc/cp-kafka:latest` (or whatever moving tag the vendor publishes). Each run pulls the vendor's current release plus the latest sealed packages and produces a sealed image under a date-stamped destination tag. The cadence (nightly, weekly, monthly) is your choice. Most customers run this pattern; it adapts to vendor releases automatically. * **Pinned, on vendor-release events.** When the vendor ships a specific version you want to adopt, run the pipeline against the pinned vendor tag and produce a sealed counterpart. Right for regulated environments where each production deploy must reference a specific vendor release. Some teams run both: a scheduled pipeline for routine refresh, plus on-demand runs against specific vendor tags when a known release needs to land in production. ## Knowing what is inside a vendor image A useful step before standing up a pipeline for a vendor image is getting a sense of what is inside: the base distribution, the bundled language runtime if any, and the vendor's own application content. The vendor's documentation typically describes this, and your team's existing image-inspection tooling can confirm. The clearer the picture going in, the easier it is to predict how the seal pass will behave on each subsequent re-seal. Your Seal account team can advise if anything in the image is unfamiliar or if you are unsure whether a particular distribution or runtime is covered. ## When the vendor publishes a new version Vendor releases are external events. Two paths: * **Scheduled pipelines pick up new versions on their next scheduled run** — the next nightly job pulls whatever `:latest` resolves to that day and produces a sealed copy. No customer action. * **Pinned pipelines need an explicit trigger.** When the vendor announces a release you want to adopt, kick off the pipeline against the new vendor tag and update the deployment manifests to reference the new sealed tag. Most teams use the scheduled pattern for routine vendor updates and reach for the pinned pattern only when a release needs particular scrutiny. ## When Seal publishes a newer iteration Like Seal My Container, the sealed copy in your registry is static once produced. New sealed iterations affect future seal passes, not past ones: * Scheduled pipelines pick up newer sealed iterations on their next run — the seal step always pulls the latest sealed packages Seal has for the affected OS layer. * For pinned tags that have not been re-sealed in a while, the next manual run brings them current. For a high-severity vulnerability that needs the new iteration into production faster than the schedule, run the pipeline manually against the affected vendor tag. ## Common situations ### The pipeline fails on a specific vendor image The image-build step inside the pipeline logs the failure. Common categories: * The vendor's image uses a distribution Seal does not support, or a distroless variant the seal step cannot operate on. * The pipeline's host lost authentication to the vendor's registry or to your own. Check both sets of credentials. * The vendor's image is unusually large and exceeds the host's disk or memory. Provision a larger host for the seal pass. ### A deployment fails after a sealed vendor image lands In the overwhelming majority of cases, a deployment failure that follows shortly after a sealed image lands has nothing to do with the substitution. Some other change in the same release cycle is more likely the cause — a vendor-side change in the image itself, a configuration drift in the deployment, an unrelated regression. Check your deployment logs first. If you still suspect the sealed packages, redeploy the previous sealed tag (or the vendor's original image, if you have it available) to confirm the hypothesis. Once you confirm the sealed image is the cause, contact your Seal account team with the affected vendor tag, the sealed tag, and the deployment logs. ### The sealed image is fine in dev but fails in production Most often a configuration delta, not a seal-step delta. The sealed image is the same artifact in both environments. Compare the deployment manifest, environment variables, and config maps between dev and prod; the seal pass is rarely the differentiator. ## What this deployment looks like to the rest of Seal The CLI does run and does report back, so the Protection page sees what Seal Vendor Apps has sealed — the same way it sees what other CLI-driven products see. Email notifications about newly available sealed versions work normally for the Seal Project the pipeline reports to. `seal image fix` does not consult Sealing Rules. The seal step inside the generated Dockerfile always runs in all mode, regardless of what rules are configured for the Seal Project. The Sealing rules tab being empty or non-empty has no bearing on what this command does. Customers who use the custom-`Dockerfile` approach (Approach 2 in the setup chapter) can write the `seal fix --os` invocation themselves and pass `--mode=remote` or `--mode=local` if they need Sealing Rules to apply — in that case the same rule mechanics apply as for any other CLI-driven product. The Seal Project the pipeline reports to is logically one per vendor image (or one per logical grouping of related vendor images). Sharing one `SEAL_PROJECT` across unrelated vendor images leads to scans clobbering each other; see the [setup chapter](/setup-containers/seal-vendor-apps.md) for the recommended naming. ## A reminder on redistributability The sealed image contains the vendor's application code. The vendor's license likely forbids redistribution. The sealed image is for **your internal use only**: do not push to public registries, do not share across organizational boundaries, do not treat it as a derivative artifact you can ship. Sealing the image does not change what the vendor's license permits. The setup chapter has more on this. ## Related * [Seal Vendor Apps](/setup-containers/seal-vendor-apps.md): the setup chapter, including both Approach 1 (`seal image fix`) and Approach 2 (custom `Dockerfile`). * [Implementing the vendor-image pipeline](/setup-containers/seal-vendor-apps/vendor-image-pipeline.md): the per-pattern setup detail. * [Working with Seal My Container](/using-platform/working-with-seal-my-container.md): the sister day-2 chapter for images you built yourself.