Remote Sealing Rules
Create, edit, and delete Sealing Rules stored on the Seal Platform.
Remote Sealing Rules are stored on the Seal Platform and managed in the Seal UI. The Seal CLI in remote mode reads them from the platform at run time. This is the default rule storage for the Remote and Automatic Remediation deployment methods.
For the rule model, the four rule types, the substitute-version options, and precedence, see the Sealing Rules overview. This page covers the UI flows for managing remote rules.
Only users with the Sealer or Admin role can create, edit, or delete Sealing Rules.
Creating a Sealing Rule
There are four entry points in the Seal UI. The first three start from a vulnerable package row, so the origin package is already chosen for you; the fourth lets you create a rule from scratch. Pick the one that fits the situation.
The three row-based flows (Seal button, Seal in all projects, drawer) always use the safest sealed version as the substitute. To pin to a specific -sp[N] or to use the origin version as an exception, you have to create the rule on the Sealing rules tab — that is the only entry point with a version picker.
From the Seal button on a Vulnerable packages tab row
The most direct path when you have a vulnerable row in front of you.
On the Vulnerable packages tab, find the package. Its package state must be Ready to seal.
Click Seal on the row.
Confirm in the Sealing instructions modal.
This flow creates a project-specific rule for the package on the row. It is the only fixed-scope create path — there is no scope toggle in this modal. To seal the same package tenant-wide, use the per-row menu instead (next).
From the per-row "..." menu — Seal in all projects
When you have a vulnerable row in front of you and want to seal the package across every Seal Project.
On the Vulnerable packages tab, open the "..." menu on the row.
Click Seal in all projects.
Confirm.
This creates a tenant-wide, specific-package rule.
From the package drawer
The drawer that opens when you click a Vulnerable packages row offers a more flexible create flow than the row's Seal button: it lets you pick between project-specific and tenant-wide before saving.
Click a vulnerable row to open its drawer.
Open the Sealing instructions tab in the drawer.
Pick the scope: New single project rule (project-specific) or New rule for all projects (tenant-wide).
Click Seal at the bottom of the drawer.
The drawer's create flow is package-specific (the origin package is the row you opened the drawer from) and always uses the safest version. To pin to a specific -sp[N], use the Sealing rules tab.
From the Sealing rules tab — New rule
The from-scratch path, and the only entry point that exposes the full rule shape.
Open the Sealing rules tab.
Click New rule in the tab header. A new editable row appears at the top of the table.
Fill in the form fields:
Project — a specific Seal Project, or All projects for a tenant-wide rule.
Vulnerable package to replace — a specific package and version, or All packages for a blanket rule.
Substitute version — a specific
-sp[N](pinned), Safest version (un-pinned), or the origin version itself (used as an exception inside a broader rule).
Save.
This is the only flow that can create a rule covering all packages, and the only flow that lets you pin to a specific -sp[N] or pick the origin version as the substitute. Anything beyond a simple "seal this row" goes through here.
Editing a Sealing Rule
Edits happen on the Sealing rules tab.
Open the Sealing rules tab.
Click the row's edit icon.
Change the substitute version, the project, or the package target. The same form as the create flow.
Save.
The CLI picks up the edited substitute on the next build. If your edit produces a rule identical to an existing one, the UI shows a Rule already exists confirmation.
Deleting a Sealing Rule
Deletions are available from three places. The Sealing rules tab is the most flexible; the other two only work for the simplest case.
From the Sealing rules tab
The canonical place. Click the delete icon on the row. Works for every rule type — project-specific, tenant-wide, package-specific, all-packages.
From the per-row "..." menu — Unseal package
On the Vulnerable packages tab, the "..." menu on a sealed row has an Unseal package action that deletes the rule sealing the package in this row. Only works when:
the package is sealed by a remote rule (it is hidden in CLI local mode); and
exactly one rule applies to the package — specifically a project-specific, package-specific rule.
If a broader rule (tenant-wide, or all-packages) also applies to the package, the row menu's Unseal option is hidden or the drawer's Unseal flow tells you to go to the Sealing rules tab instead. The reasoning is that a row-level action cannot safely express "delete the broad rule that also affects other packages or projects".
From the package drawer — Unseal
The drawer's Sealing instructions tab on a sealed row shows an Unseal button. Same constraints as the row menu's Unseal: it deletes the single project-specific, package-specific rule applying to that row. When more than one rule applies, the drawer shows a notice directing you to the Sealing rules tab.
When you must use the Sealing rules tab
You want to delete a tenant-wide rule.
You want to delete an all-packages rule.
Multiple rules apply to a package (for example, a tenant-wide rule plus a project-specific exception) and you want to remove or change one of them. Pick the specific rule to delete on the Sealing rules tab.
Local Sealing Rules cannot be deleted from the Seal UI at all — they live in .seal-actions.yml and are edited in the file directly. See Local Sealing Rules.
Related
Sealing Rules overview: the rule model, the four rule types, substitute-version options, and precedence.
Local Sealing Rules: the file-based counterpart for Local-mode deployments.
The Sealing rules tab: the list view of remote rules.
The Vulnerable packages tab: where most create flows start.
Last updated