List Sealing Rules
Description: Retrieves the list of sealing rules configured for your tenant, with options to filter the results by project name and vulnerable package name.
A sealing rule says, for example, "in project my-backend-service, replace log4j-core 2.14.1 with log4j-core 2.14.1+sp1". Other rules can apply tenant-wide, or to every package in a project. Multiple rules can match the same package; broader rules (e.g. tenant-wide, or <ANY> package) set the default, and narrower rules act as targeted overrides.
For background on how rules are authored and managed, see The Sealing Rules tab.
Path: https://external.sealsecurity.io/authenticated/api/v1/sealing-rules
Method: GET
Authentication: See detailed explanation here.
Request Parameters
This endpoint accepts the following optional query parameters to filter the results:
project_name_filter
string
Filter rules by project name. When omitted, returns rules for every project, including tenant-wide rules. When set to a substring, returns rules whose project_name contains it (case-insensitive); does not match tenant-wide rules. When set to <ANY>, returns only tenant-wide rules.
Any string, or <ANY>
package_name_filter
string
Filter rules by vulnerable package name. Same three-way behavior as project_name_filter: omitted returns all, a substring filters case-insensitively, and <ANY> returns only rules that cover all packages.
Any string, or <ANY>
limit
integer
Maximum number of sealing rules to return in a single page.
1 to 100 (default 50)
cursor
string
Opaque pagination cursor returned by a previous response's next_page. Omit on the first request.
Any string returned by a previous call
When both filters are provided, results must satisfy both (logical AND).
Only Remote (server-side) sealing rules — those created via the Seal UI or API — are returned. Local rules defined in a project's .seal-actions.yml are not included.
Response
The API returns a paginated JSON object containing a page of sealing rules and an opaque cursor for fetching the next page.
Response Structure:
JSON
Response Fields:
items
array of sealing rule objects
The page of sealing rules. See the table below for each object's fields.
next_page
string or null
Opaque cursor for the next page. Pass it back as the cursor query parameter to fetch the next page; null when there are no further pages.
The sealing rule object is composed of the following fields:
project_name
string
The Seal project the rule applies to, or <ANY> to apply tenant-wide.
vulnerable_package_name
string
The name of the vulnerable package the rule replaces, or <ANY> (paired with vulnerable_package_version: <ANY>) to match every package.
vulnerable_package_version
string
The version of the vulnerable package the rule replaces, or <ANY> (paired with vulnerable_package_name: <ANY>) to match every version.
sealed_package_name
string
The name of the sealed package that replaces the vulnerable one, or <ANY> when vulnerable_package_name is also <ANY>.
sealed_package_version
string
One of: a specific sealed version string (pinned), <SAFEST> (resolves to the safest version at apply-time), or <ORIGIN> (do not seal, keep the origin version).
created_on
string
The date and time (ISO 8601 format, UTC) when the rule was created.
Sentinel values:
The response uses three reserved sentinel strings to express values that a normal package, project, or version name cannot. Each sentinel is enclosed in angle brackets.
<ANY>
project_name, vulnerable_package_name, vulnerable_package_version, sealed_package_name
Wildcard. The rule matches any value for that field. vulnerable_package_name, vulnerable_package_version, and sealed_package_name are paired: when one is <ANY>, all three are.
<SAFEST>
sealed_package_version
Un-pinned. Resolves at apply-time to the safest available version of the matched package.
<ORIGIN>
sealed_package_version
For this specific origin version, leave it as-is. Useful as a narrow exception that overrides a broader rule. <ORIGIN> only applies to rules that target a concrete vulnerable version; it cannot pair with vulnerable_package_version: <ANY>.
Example Requests and Responses
1. List the first page of sealing rules:
To retrieve every rule, follow next_page until it is null.
Request (cURL):
Bash
Example Response (Truncated):
JSON
2. Filter rules by project name:
Request (cURL):
Bash
Example Response:
JSON
3. Get only tenant-wide rules (those that apply to every project):
Request (cURL):
Bash
Example Response:
JSON
4. Filter by package name and paginate:
Request (cURL):
Bash
Example Response (first page, truncated):
JSON
To fetch the next page, pass the previous response's next_page value as the cursor query parameter:
Bash
Last updated