# Package states Every vulnerable package on the [Vulnerable packages tab](/new-documentation/new-docs/protection-page/vulnerable-packages-tab.md) is in exactly one of six **package states**. The state captures where the package sits in its remediation lifecycle: whether a sealed version exists, whether you have asked Seal to build one, whether you have created a Sealing Rule, whether the CLI has applied it, and whether Seal can fix it at all. | State | Meaning | | ----------------------- | ---------------------------------------------------------------------------------------------------- | | **Generate available** | No sealed version exists yet for this package and version. Seal can attempt to build one on request. | | **Version in progress** | Seal is actively building a sealed version. | | **Ready to seal** | A sealed version exists; no Sealing Rule has been created yet. | | **Pending deploy** | A Sealing Rule exists, the Seal CLI runs in CI, and the next CLI run will replace the package. | | **Sealed** | The sealed version is in use. | | **Unfixable** | Seal cannot build a sealed version for this package. | ## State machine The typical path is **Generate available → Version in progress → Ready to seal → Pending deploy → Sealed**, but there are variations driven by the deployment method and by whether matching Sealing Rules already exist when Seal finishes a build. ```mermaid graph TD GA[Generate available] -->|Generate fix| VP[Version in progress] VP -->|build fails| U[Unfixable] VP -->|build succeeds| RTS[Ready to seal] VP -->|matching rule exists or Automatic Remediation| PD[Pending deploy] RTS -->|create a Sealing Rule| PD RTS -->|Artifact Server pull| S[Sealed] PD -->|next CLI run| S ``` A newly discovered vulnerable package usually starts in **Generate available**, but it can start in **Ready to seal** (if Seal already has a sealed version in its catalog), **Unfixable** (if Seal has already determined no fix is possible), **Version in progress** (if Seal is already mid-build), or **Sealed** (if your build is already pulling a sealed version). ## The states in detail ### Generate available No sealed version exists for this package and version, and the package is in a Seal-supported ecosystem. The row's primary action is **Generate fix**. Clicking **Generate fix** queues a backend build and moves the package to **Version in progress**. See [Triggering Generate fix](/new-documentation/new-docs/generate-fix.md). ### Version in progress Seal is actively building a sealed version. The build typically takes **24-72 hours**. While it runs, the row shows a progress indicator instead of an action button. When the build finishes, the package moves to **Ready to seal** (success) or, when a Sealing Rule already targets the package or the Seal Project uses the Automatic Remediation deployment method, directly to **Pending deploy**. If the build fails, the package moves to **Unfixable**, which is rare. ### Ready to seal A sealed version exists, but no Sealing Rule applies to the package yet. What you do next depends on your deployment method. | Deployment method | Action | What happens to the state | | ------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------- | | **Remote** | Click **Seal** for a project-specific Sealing Rule, or **Seal in all projects** in the per-row menu for a tenant-wide rule. | Changes immediately to **Pending deploy**. | | **Local** | Add a local Sealing Rule to the project's `.seal-actions.yml` file. If source control is connected, you can open a pull request from the Projects page. | Changes to **Pending deploy** once source control is connected and a scan picks up the change. | | **Artifact Server** | Pin the sealed version in your dependency manifest and run your CI. | Stays as **Ready to seal** until your build pulls the sealed version, then changes directly to **Sealed**. | | **Manual** | Download the sealed package from the Repository page and use it however you use packages today. | Stays as **Ready to seal**. Seal has no signal that you applied the package. | ### Pending deploy A Sealing Rule exists for the package, the Seal Project's deployment method runs the CLI in CI (Remote, Local, or Automatic Remediation), and the next CLI run will replace the vulnerable package with the sealed version. The package is in **Pending deploy** by definition only while a CLI-driven CI run is the next step. The package moves to **Sealed** after the next CLI run. If the Sealing Rule is deleted before the run, the package returns to **Ready to seal**. The Artifact Server and Manual deployment methods do not run the CLI in CI, so packages in those projects bypass Pending deploy entirely. ### Sealed Seal has confirmed that the sealed version is in use. The package keeps appearing on the Vulnerable packages tab (the underlying origin version is still vulnerable), but the badge confirms your build is using the sealed counterpart. The same package also appears on the [Sealed packages tab](/new-documentation/new-docs/protection-page/sealed-packages-tab.md), with attestation downloads. If a new vulnerability is later discovered in the sealed version itself, the original package stays in **Sealed**. The sealed version appears as its own row on the Vulnerable packages tab with its own action button. If the original Sealing Rule targets the safest sealed version (not pinned to a specific one), the row automatically promotes to **Pending deploy** when Seal releases the next sealed version of the package; otherwise you create a Sealing Rule for the new sealed version explicitly. ### Unfixable Seal cannot build a sealed version for this package. The reasons: * **The package is malicious.** Malicious packages have no sealed counterpart by definition. The Vulnerable packages tab marks them with a red **Malicious** badge in the action column, with a tooltip telling you to remove the package from your code. * **A Generate fix build failed.** Rare. Contact your Seal account team; they can look at the specific build log and either retry, fix the underlying patch, or confirm the package needs another remediation path. * **There is no fix that preserves compatibility.** Seal does not build sealed versions when the only available fix is a breaking change. A [private version](/new-documentation/new-docs/seal-approach/sealed-packages.md#private-versions) may be available; ask your Seal account team. ## Filter labels The Vulnerable packages tab's **Availability** filter uses slightly different display labels for the same six states: "Already sealed" (Sealed), "Fix available" (Ready to seal), "Fix in preparation" (Version in progress), "Generate fix" (Generate available), "Pending deploy" (Pending deploy), and "Fix not available" (Unfixable). ## Related * [The Vulnerable packages tab](/new-documentation/new-docs/protection-page/vulnerable-packages-tab.md): where states are surfaced. * [Triggering Generate fix](/new-documentation/new-docs/generate-fix.md): the action that drives Generate available packages into Version in progress. * [Sealing Rules](https://github.com/seal-community/gitbook/blob/main/new-docs/using-the-platform/sealing-rules/README.md): what creating a rule does. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.sealsecurity.io/new-documentation/new-docs/package-states.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.