> 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-apps/automatic-remediation.md). # Under Automatic Remediation In the Automatic Remediation deployment method, the Seal CLI runs in all mode inside your CI/CD pipeline and replaces every vulnerable package it can with the safest sealed version. There are no Sealing Rules to manage; the substitution decision is "always yes" for every row Seal can seal. Day-to-day work in this method is the lightest of the five: the platform pulls; you watch. ## The recurring rhythm The four steps from [Working with the platform](/using-platform/working-with-the-platform.md), specialized for Automatic Remediation: 1. **Review** the Vulnerable packages tab on the [Protection page](/discovering/protection-page.md) for context — what is being sealed, what is in **Unfixable** state (Seal cannot help), what is in **Generate available** state (worth triggering). 2. **Decide what to seal.** Nothing to do per row; the CLI in all mode replaces every package in **Ready to seal** state. 3. **Let the next CI build run.** Every CI build pulls the safest sealed versions for everything sealable. 4. **Verify.** Rows in **Ready to seal** state should move to **Sealed** after the next build. ## What stays under your control Automatic Remediation does not consult Sealing Rules. Customers who want the "seal everything" behavior but with the ability to write exceptions through the Seal UI should use the **Remote** deployment method instead and create a tenant-wide "all packages" rule on the [Sealing rules tab](/discovering/protection-page/sealing-rules-tab.md). That rule has the same effect as Automatic Remediation when nothing else applies, and you can write more specific rules to override it — for instance, to keep one package on its origin version in one Seal Project as an exception. See [Sealing Rules — Use cases](/using-platform/sealing-rules.md#use-cases) for the pattern. Within Automatic Remediation itself, the lever you have is [Trigger Generate fix](/discovering/generate-fix.md) — for rows in **Generate available** state, ask Seal to build a sealed iteration. Once the iteration is published, Automatic Remediation picks it up on the next build.
Generate fix button on a row and the Availability filter dropdown showing Generate available

The Generate fix action on a Generate available row, alongside the Availability filter.

## When new vulnerabilities are disclosed against a sealed iteration A package version has a row on the Vulnerable packages tab only when it is in use **and** has at least one open vulnerability. The row's state reflects what is being done about those open vulnerabilities. Under Automatic Remediation, every row that can be substituted is substituted on the next build. Take a Seal Project Automatic Remediation has been sealing `ejs@2.7.4` for, using `sp1`: * The `ejs@2.7.4` row sits in **Sealed** — open vulnerabilities, with Automatic Remediation substituting the current safest sealed iteration. As long as a newer iteration than the one in use exists, the row stays in **Sealed**. * `ejs@2.7.4-sp1` itself has no row on the Vulnerable packages tab as long as it has no open vulnerabilities. When a new vulnerability is disclosed that affects `sp1`, `sp1` gains its own row. The state of that row tracks Seal's response: * While Seal has not yet started a new sealed iteration, the row is in **Generate available**. * Once Seal is actively building, the row is in **Version in progress**. * Once Seal publishes `sp2`, the row moves to **Pending deploy** — Automatic Remediation will substitute `sp2` on the next build, without any customer action. * After the next CI build, `sp1`'s row returns to **Sealed**, because `sp2` is now in use. ## Common situations ### A new vulnerability is disclosed in a package you already use A row appears for the affected package version. Critical and high-severity vulnerabilities are typically picked up by Seal automatically within hours; lower-severity ones may sit in **Generate available** until a customer triggers them. Once a sealed iteration is available, the next Automatic Remediation build pulls it and the row moves to **Sealed**. ### A developer adds a new vulnerable dependency The CLI step discovers and replaces the package in the same build, in one pass. The row briefly appears in **Ready to seal** during discovery and moves to **Sealed** by the end of the build, because all-mode substitutes everything it can in a single run. ### CI fails after Automatic Remediation pulled a new sealed iteration In the overwhelming majority of cases, a CI failure that follows shortly after a new sealed iteration has nothing to do with the substitution. Some other change in the same build cycle is the cause. Check your CI logs and your commit history first. If you still suspect the sealed iteration is the cause, the simplest test is to switch the project temporarily to Remote with a tenant-wide all-packages rule pinned to the previous iteration, re-run, and see whether the build passes. If it does, contact your Seal account team with the logs and the sealed version involved. Because every iteration rolls forward automatically, customers who need reproducibility more than they need always-on safest-version coverage should consider Remote with a tenant-wide all-packages rule and per-package pins for the cases where stability matters. ## Related * [Sealing Rules — Use cases](/using-platform/sealing-rules.md#use-cases): the UI-driven equivalent that allows exceptions. * [Seal Apps via the Seal CLI in CI/CD](/setup-apps-os/cli-in-cicd.md): the setup chapter Automatic Remediation assumes. * [The CLI fix mode](/setup-apps-os/cli-in-cicd/cli-fix-mode.md): how to verify all mode is what the CI is invoking. * [Triggering Generate fix](/discovering/generate-fix.md): the action for rows in **Generate available** state.