> 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-the-platform.md).

# Working with the platform

This chapter opens **Using the Seal Platform**, the day-2 operating manual for the Seal Platform. The previous sections covered **setup**, the one-time work of integrating Seal with your code, your builds, your registries, and your hosts. This section covers **operation**: what happens repeatedly after setup, week after week, as new vulnerabilities are discovered and new builds run.

The recurring rhythm fits the four scan-driven Seal products: **Seal Apps**, **Seal OS**, **Seal My Container**, and **Seal Vendor Apps**. **Seal Base Images** is the exception — see "Where each product fits" below.

## The recurring rhythm

Day-to-day operation of the platform cycles through four steps:

1. **Review** what Seal has discovered. The [Protection page](/discovering/protection-page.md) shows every vulnerable package across your Seal Projects, with state badges that say whether a sealed version is available, pending deploy, or already in use. The [Dashboard](/discovering/dashboard.md) gives the tenant-wide aggregate over time. Reviewing is the trigger for everything that follows.
2. **Decide what to seal**. Most teams seal everything Seal can; some have policies that gate which sealed versions they accept (a specific iteration, a specific cutoff date, a specific package excluded as a false positive). The decision is encoded either as a Sealing Rule in the Seal Platform or as a manifest pin in your source — depending on which deployment method you chose during setup. The deployment method also determines where decisions live: the Seal UI for **Remote** mode, `.seal-actions.yml` for **Local** mode, or your dependency manifest for **Artifact Server** and **Manual** deployments.
3. **Let the pipeline run**. The next CI build picks up the new rule or the new manifest pin and replaces the vulnerable package with the sealed version. Nothing about the build pipeline needs to change once it is set up; the rule or pin is the only moving part.
4. **Verify the sealed version was pulled.** Check the Protection page after the build completes. The package's state badge moves from **Ready to seal** through **Pending deploy** to **Sealed** once the build has pulled the sealed version from the Seal Artifact Server. This confirms the sealed version reached your build; it does not confirm the build itself succeeded — that is your CI's domain.

The cycle repeats. A package version has a row on the Vulnerable packages tab only when it is in use **and** has at least one open vulnerability. Each version — the origin, `sp1`, `sp2`, and so on — is its own row, and each row's state is computed from that version's own flags. The origin-version row sits in **Sealed** as long as a newer sealed iteration than the one in use exists. When Seal publishes a newer iteration that addresses a newly disclosed vulnerability in the iteration currently in use, the previously-in-use iteration gains its own row (because it now has open vulnerabilities), and the row's state walks the lifecycle until that iteration too is superseded.

## Where each product fits

For the four scan-driven products, the rhythm holds; only the specifics of "let the pipeline run" differ:

| Product               | "Pipeline" means                                                                                                                                      |
| --------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Seal Apps**         | Your application's CI/CD build, with the Seal CLI integrated or your package manager pointed at the Seal Artifact Server.                             |
| **Seal OS**           | Either an image build (`seal fix --os` inside a `Dockerfile`) or a host-side patching job (`seal fix --os` against a live VM or bare-metal host).     |
| **Seal My Container** | The centralized re-seal pipeline triggered by registry push events, running `seal image fix` against each newly pushed image.                         |
| **Seal Vendor Apps**  | A scheduled or vendor-release-triggered `seal image fix` against the vendor's published tag, with the sealed result landing in your private registry. |

The "review" and "verify" steps look the same across these four — the Protection page and the Dashboard aggregate findings into one view, tagged by Seal Project so you can see which is which.

**Seal Base Images is different.** There is no scan, no `seal fix` step, and no pulls from the Seal Artifact Server: the customer pulls a sealed image from Seal's image registry and that is it. The Protection page does not list packages from Seal Base Images deployments because there are no discovery signals to populate it with — Seal does not see the customer's environment in that flow. Day-2 operation of Seal Base Images is closer to a third-party-dependency upgrade cycle than to the four-step rhythm above: track when Seal publishes a new iteration of the image, decide when to roll forward, edit the `FROM` line, redeploy. The Working with Seal Base Images chapter (later in this section) covers the specifics.

Each product has a dedicated "Working with…" chapter later in this section that drills into its Day-2 specifics.

## What the rest of this section covers

The chapters that follow drill into the parts of the rhythm:

* The **Seal UI tour** is a navigation cheat-sheet to the UI's top-level pages.
* **Sealing Rules** is the canonical home for the rule-creation mechanic that drives the Remote and Local deployment methods.
* The five **Working with…** chapters cover the per-product specifics of the rhythm — what changes from one product to another within the same four steps.
* **Scanner Exclusions** covers the mechanism that tells the Seal CLI to rename a package on disk in your build so external scanners stop flagging it by name.
* The **Seal AI Agent** (chatbot in the Seal UI) and the **Seal Engineer** (schedulable automated-workflow runtime) sit alongside the human-driven workflow as alternative ways to drive the same rhythm.
* The **Notification Center**, **Reports Manager**, and **Usage page** cover what triggers a notification, how to build reports for leadership, and how the tenant's consumption is tracked.

## Related

* [Application and OS setup](/setup-apps-os/choosing-deployment-method.md): the setup mechanics for Seal Apps and Seal OS.
* [Container and image setup](/setup-containers.md): the setup mechanics for Seal Base Images, Seal My Container, and Seal Vendor Apps.
* [The Protection page](/discovering/protection-page.md): the primary review view.
* [The Dashboard](/discovering/dashboard.md): the tenant-wide aggregate view.