Working with Seal OS

The day-to-day rhythm of remediating OS-package vulnerabilities with Seal OS, once setup is done.

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 on a Linux host or inside a Linux container. The everyday work cycles through the same review-decide-build-verify rhythm as Seal Apps, but the shape of "build" differs between deployment contexts. Subpages for each:

• In CI/CD — seal fix --os runs inside a Dockerfile during docker build. Image builds are the trigger; every release of the image carries an up-to-date sealed OS layer.

• On live hosts — seal fix --os runs against a running Linux host (a VM or bare-metal server) with outbound access to Seal's hosted artifact servers. Scheduled patching runs are the trigger; sealed OS packages replace the host's installed ones in place.

• In air-gapped environments — hosts with no outbound access. The Seal CLI is not used; sealed packages are mirrored from Seal to an internal repository and the host's native package manager applies them.

What this chapter does not cover

• The setup mechanics of either deployment shape. Those live under Seal OS in CI/CD (for CLI-driven flows, in CI or on a connected host) and On-prem and air-gapped environments (for environments where hosts cannot reach Seal directly).

• The Sealing Rules mechanic. Seal OS uses the same model as Seal Apps; see Sealing Rules.

• The seal fix --os flag reference. Lives at seal fix --os reference.

What is shared across the two contexts

These elements apply regardless of where seal fix --os runs.

One Seal Project per scan, separate from seal fix

If a host or image also runs seal fix for application dependencies, point each seal fix invocation at a different Seal Project. Each CLI scan reports its discovered set of packages; the next scan against the same project marks every package it does not see as stale, and stale packages drop off the Protection page. Because seal fix and seal fix --os scan disjoint sets (application packages vs OS packages), running both against one SEAL_PROJECT makes the second run silently bury the first run's discovery. Use two Seal Projects per host or image — for example, my-app for the application scan and my-app-os for the OS scan — both under the same tenant.

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

Fix modes apply the same way

seal fix --os accepts the same fix-mode flag as seal fix: remote, local, or all. The three modes map to the same Sealing Rule sources as for Seal Apps:

• Remote — the CLI fetches remote rules from the Seal Platform.

• Local — the CLI reads rules from .seal-actions.yml in the working directory (typically the build context for image builds, or a known location on the host for live patching).

• All — every vulnerable OS package the CLI has a sealed version for is replaced, no rules consulted. Most Seal OS deployments use this mode because the typical intent is "seal everything sealable in the OS layer."

The Sealing Rules chapter covers the rule model itself. The day-2 rhythm differs by deployment context (covered in the subpages), not by fix mode.

The OS-package family is auto-detected

The CLI reads the target's /etc/os-release (or the in-build equivalent) and selects the right family: apk for Alpine, deb for Debian and Ubuntu, rpm for Red Hat, CentOS, Rocky Linux, AlmaLinux, and Amazon Linux. Sealed packages come from the matching artifact server (apk.sealsecurity.io, deb.sealsecurity.io, rpm.sealsecurity.io). There is no per-family CLI configuration.

The family-specific details — package metadata format, the database the CLI updates after substitution, which native commands customers use to verify on the host — appear where they matter in the subpages.

Sealing application artifacts in the same image

When an image carries both OS packages and already-built application artifacts (JAR files, Python wheels) that you did not build yourself — a sibling case Seal OS does not cover on its own — pair seal fix --os with seal fix --fs <ecosystem> <path> in the same Dockerfile. The --fs step recursively scans a directory and seals vulnerable artifacts in place.

The canonical case is a Seal Vendor Apps pipeline, where the vendor packed JARs into the image. The same technique applies anywhere artifacts exist as built bytes rather than source: re-sealing a container you built before, sealing wheels delivered by a separate team's build, and so on. See Seal Vendor Apps for the full pattern.

Related

• Working with the platform: the cross-product framing of the same rhythm.

• Seal OS in CI/CD: the setup chapter for image builds.

• Seal Vendor Apps: the canonical chapter for seal fix --fs, paired with seal fix --os.

• On-prem and air-gapped environments: the setup chapter for environments where hosts cannot reach Seal directly.

• Sealing Rules: the rule model seal fix --os consults in remote and local modes.