> 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 Day-to-day rhythm of Seal Apps when the Seal CLI runs in all mode and every vulnerable package is replaced automatically. 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 version. Once the sealed version 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 version 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 version. As long as a newer sealed version 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: * Until a new sealed version is published, the row is in **Generate available**. Seal proactively monitors your vulnerable packages and seals relevant new vulnerabilities as they come out, so most of the time you will see the row move on its own from **Generate available** to **Ready to seal** without any manual step. * If someone in your tenant triggers Generate fix, the row is in **Version in progress** until the sealed version ships. * 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 version 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 version In the overwhelming majority of cases, a CI failure that follows shortly after a new sealed version 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 version 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 sealed version, 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 sealed version 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.