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 --osruns inside aDockerfileduringdocker build. Image builds are the trigger; every release of the image carries an up-to-date sealed OS layer.On live hosts —
seal fix --osruns 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 --osflag reference. Lives atseal fix --osreference.
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
seal fixIf 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.ymlin 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 withseal 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 --osconsults in remote and local modes.
Last updated