Package states
The six package states a vulnerable package can be in, how they transition, and what to do for each.
Every vulnerable package on the Vulnerable packages tab 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.
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.
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.
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.
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, 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 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: where states are surfaced.
Triggering Generate fix: the action that drives Generate available packages into Version in progress.
Sealing Rules: what creating a rule does.
Last updated