Rules Screen

Manage what packages to replace from the UI

The rules screen is used to manage the package replacement rules when using the remote configuration deployment.

The Rules Screen only shows rules that have been defined on the Seal server using the web interface. Rules that have been defined in local configuration files are not saved on the server, and will not be shown.

Rules Table

Each rule has the following elements:

1. Project - The project the rules applies to. Either a specific project, or all the projects.

2. Vulnerable package - The package (including specific version) that must be replaced. Either a specific package, or all vulnerable packages.

3. Substitute version - The alternative version that should be used when encountering the vulnerable package in the relevant project. There are 3 options:

   1. The safest version - for example 3.9.0-safest. This will tell the Seal CLI to always pull the safest version Seal released. So if a new vulnerability is disclosed in the package and Seal releases a new sealed version addressing the new vulnerability (for this example - 3.9.0+sp2), it will automatically be used next time without any additional intervention.

   2. A specific sealed version - for example 3.9.0+sp1 (as shown in the screenshot below). This will pin the replacement version that you're using to a specific version. If a new vulnerability is disclosed in the package and Seal will release a new sealed version addressing the new vulnerability (for this example - 3.9.0+sp2), you will need to actively change the rule you're using.

   3. The original version - This will tell the Seal CLI not to replace the vulnerable version. This option only makes sense when you want to exclude a particular package from being remediated. For example, if you have a rule to use the safest version of aiohttp in all projects, but you don't want to patch it in a specific project, then you can create another rule specifying to use the original version in that specific project (because specific rules always take precedence).

Rules Order of Precedence

It's possible to create more than one rule that applies to the same scenario. For example, say we have a vulnerable package aiohttp version 3.9.0 in the ui project. We can define 4 different rules that will apply to it:

1. A rule for aiohttp version 3.9.0 in the ui project.

2. A rule for aiohttp version 3.9.0 in all projects.

3. A rule for all packages in the ui project.

4. A rule for all packages in all projects.

These rules might have conflicting instructions. One might say to use 3.9.0+sp1, one might say to use 3.9.0+sp2, one might say to use the safest 3.9.0 version, and one might actually specify to use the original 3.9.0 version.

In case of conflict, the following order of precedence applies:

1. A rule for a specific package in a specific project

2. A rule for all packages in a specific project

3. A rule for a specific package in all projects

4. A rule for all packages in all projects

Example:

Suppose there are two rules:

1. A rule to replace aiohttp version 3.9.0 in the ui project with version 3.9.0+sp1

2. A rule to replace aiohttp version 3.9.0 in all projects with version 3.9.0+sp2

What will happen is that aiohttp version 3.9.0 will be replaced with version 3.9.0+sp2 in all projects, except the ui project, where it will be replaced with version 3.9.0+sp1 instead.

Common Cases

Fixing everything with one rule

To automatically replace all vulnerable packages with their remediated version, where one exists, just create a rule that applies to all packages in all projects, and replaces it with the safest version, as shown in the screenshot below.

If you use such a rule, there will be no need to create rules for specific packages in the future.

Excluding a particular package

To exclude a particular package from being replaced due to some widely applicable rule (a rule that applies for all projects, or all packages) you can create a specific rule to use the original vulnerable version. The more specific rule will apply, so the package will not be replaced with its remediated version. See the rules order of precedence above.

For example, suppose you don't want the package golang.org/x/net version 0.28.0 to be fixed in goproject. Creating the rules below will mean that every other vulnerable package is replaced with the safest version Seal released, except for golang.org/x/net version 0.28.0 ingoproject.

Fixing a new vulnerability everwhere

It can be very cumbersome to fix every instance of a vulnerability in a commonly used package. The same vulnerability might be found in dozens of different repositories. Fixing them without Seal requires creating a pull request in every one of those repositories, and for the developers to make whatever code alterations are necessary to keep the code from breaking.

By creating a rule that applies for all projects, you can fix all instances of the vulnerability in one fell swoop. For example, the following rule would automatically fix the infamous log4shell vulnerability in all instances of the log4j version 1.2.17.