Seal OS in CI/CD

Running the Seal CLI in CI/CD to seal the OS-level packages inside your Linux container images.

Seal OS remediates vulnerabilities in OS-level packages: the Alpine apk, Debian and Ubuntu apt, and Red Hat / CentOS / Amazon Linux rpm packages that ship inside a Linux container image alongside your application. The CLI command for this work is seal fix --os.

The deployment shape is almost always the same: seal fix --os runs inside a Dockerfile during docker build, after the base image's package manager has installed the OS packages and before the rest of the build finalizes the image. The resulting image ships with the sealed versions of the OS packages in place of the vulnerable originals.

This chapter is the canonical setup home for the Seal OS path through CI/CD. The same CLI also runs on a connected live host (a Linux VM or bare-metal server with outbound to Seal); the mechanics are identical to the in-Dockerfile flow described here, with the seal step invoked from the host's patching runbook instead of the image build. For environments where hosts cannot reach Seal at all, see On-prem and air-gapped environments.

• seal fix --os reference: commands, flags, and environment variables.

• Sealing OS packages in a Dockerfile: the per-distribution patterns for apk, apt, and rpm images.

• Integrating with your container build pipeline: wiring the Dockerfile build into the CI system that drives your image releases.

Before you start

• A Linux container image you build yourself (an image whose Dockerfile is in your source tree). Seal OS on vendor-supplied images you do not rebuild is covered by Seal Vendor Apps, not this chapter.

• A token for authentication, set in the build environment as SEAL_TOKEN. Production tokens for production-equivalent CI; development tokens for developer machines and feature-branch pipelines.

• A Seal Project for the CLI to attribute its activity to, supplied as SEAL_PROJECT. The first run with a SEAL_PROJECT value that does not exist creates the project automatically. If the same build also runs seal fix for application dependencies, use a different Seal Project for it; see "Use a separate Seal Project for seal fix --os" below.

• Network access from the container build environment to the Seal Platform and to the per-distribution Seal OS artifact servers (apk.sealsecurity.io, deb.sealsecurity.io, rpm.sealsecurity.io).

How the CLI seals OS packages

seal fix --os detects the distribution of the container it is running inside, identifies which OS packages are installed and vulnerable, pulls the sealed versions from the matching Seal OS artifact server, and replaces the package files on disk. After the replacement, the CLI updates the package-manager database (apk, dpkg, rpm) so its view of what is installed matches the sealed versions actually on disk. The resulting image is structurally indistinguishable from one built against the upstream packages: the same files in the same paths, with the same package-manager metadata, only with the vulnerabilities backported out.

Three OS-package families are supported today:

Family	Distributions	Seal OS artifact server
apk	Alpine Linux	apk.sealsecurity.io
deb	Debian, Ubuntu	deb.sealsecurity.io
rpm	Red Hat Enterprise Linux, CentOS, Rocky Linux, AlmaLinux, Amazon Linux	rpm.sealsecurity.io

The CLI selects the right family based on the image it runs inside; you do not configure it explicitly.

When in the build the CLI runs

seal fix --os replaces installed OS packages on the filesystem of the container being built. A container always inherits some OS packages from its base image; on top of that, most Dockerfiles install additional packages (typically through RUN apk add / RUN apt-get install / RUN dnf install) and may upgrade some of the base-image packages along the way.

Run seal fix --os after every step that installs or upgrades OS packages, so the full installed set is in scope: the base image's packages plus anything your Dockerfile added or bumped. Running it earlier means the additions and bumps that came later are not considered, and the image ships with only the initial subset sealed.

The other constraint is privilege. The CLI needs to write to the package-manager database, which means it must run while the build is still USER root. If a USER directive has dropped privileges before the seal step, the step fails.

Sealing Rules and OS packages

The CLI's fix mode applies the same way for OS packages as for application dependencies: in remote mode the CLI fetches Sealing Rules from the Seal Platform; in local mode it reads them from .seal-actions.yml; in all mode it replaces every vulnerable OS package it has a sealed version for, without consulting any rule. The three modes map to the same three deployment methods that the application-dependency path uses.

Use a separate Seal Project for seal fix --os

If your build also runs seal fix for application dependencies, do not point both invocations at the same SEAL_PROJECT. Each CLI scan reports the packages it discovered to the project; the next scan against the same project marks every package the previous scan reported (and the current one did not) as stale, so they drop off the Protection page. Because seal fix discovers application packages and seal fix --os discovers OS packages — two disjoint sets — running them back to back against the same SEAL_PROJECT makes the second run silently bury the first run's discovery.

The on-disk fixes in both invocations still happen correctly. Only Seal's view of the project's package coverage is affected.

The recommended setup is to create two Seal Projects per image — for example, my-app for the application-dependency scan and my-app-os for the OS-package scan — and pass the corresponding SEAL_PROJECT to each seal fix and seal fix --os invocation respectively. Both projects can sit under the same tenant; the rest of the configuration (tokens, Sealing Rules, the deployment method) is per-project.

Related

• Choosing your deployment method: the decision page for the five deployment methods.

• Seal Apps via the Seal CLI in CI/CD: the parallel chapter for application dependencies. The two share the CLI binary, the fix-mode model, and the token configuration; they diverge only in which seal fix subcommand runs.

• On-prem and air-gapped environments: the alternate workflow when hosts cannot reach Seal directly.