> For the complete documentation index, see [llms.txt](https://docs.sealsecurity.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.sealsecurity.io/legacy-documentation/web-interface/rules-screen.md).
# Rules Screen
The rules screen is used to manage the package replacement rules when using the [remote configuration](/legacy-documentation/deployments/remote-configuration.md) deployment.
{% hint style="warning" %}
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](/legacy-documentation/deployments/local-configuration.md) files are not saved on the server, and will not be shown.
{% endhint %}
## 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](#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` in`goproject`.
### 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](https://en.wikipedia.org/wiki/Log4Shell) vulnerability in all instances of the `log4j` version `1.2.17`.