> 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/using-platform/scanner-exclusions.md).

# Scanner Exclusions

A Scanner Exclusion is a workaround for a specific annoyance: an external scanner — a customer's downstream Snyk run on the artifact you ship, a Wiz scan in the deployment environment, an auditor's compliance scan — reports a package as vulnerable when it is not actually vulnerable in your build. The scanner is wrong. The pressure on you to "upgrade" the package, often coming from people who do not have visibility into why the report is incorrect, is the problem.

A Scanner Exclusion tells the Seal CLI to rename that specific package on disk during the build by prepending `seal-` to its name. The external scanner then looks up `seal-x` in its vulnerability database, finds nothing, and stays quiet. The false-positive pressure goes away.

The feature is **off by default**. An Admin enables it from **Settings > Preferences**. Once enabled, the [Scanner exclusions tab](/discovering/protection-page/scanner-exclusions-tab.md) on the Protection page and the create / edit / delete affordances appear.

Most teams never need this feature. It exists for the narrow case where you ship artifacts to customers (or pass through auditors) running scanners that draw incorrect conclusions.

## When this applies vs Package renaming

External scanners can raise false positives in two distinct situations. The two have different remediations.

* **The package has real vulnerabilities and you are using a sealed version.** The external scanner does not consume Seal's vulnerability feed and matches packages by name; it reports the sealed package as vulnerable. Use `SEAL_USE_SEALED_NAMES=1` when invoking the Seal CLI. Every sealed package the CLI produces is renamed in the output, and the scanner stops matching. This is the common case for any customer shipping sealed artifacts to a downstream consumer with their own scanner. See [Package renaming](/integrations/package-renaming.md).
* **The package has no real vulnerabilities, but an external scanner reports one anyway.** No sealed version exists, because there is nothing to seal. Use a Scanner Exclusion. The exclusion targets a specific (project, ecosystem, package, version) and the CLI renames just that package on disk.

The two mechanisms handle disjoint sets: `SEAL_USE_SEALED_NAMES` covers every sealed package the CLI produces; Scanner Exclusions cover specific non-sealed packages where the external scanner is incorrect.

Packages targeted by Scanner Exclusions usually do **not** appear on the Vulnerable packages tab. Seal does not consider them vulnerable. You learn about them from the external scanner's report, not from the Seal UI.

## What a Scanner Exclusion is

A four-field record:

| Field         | Meaning                                                                                                                                                         |
| ------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Project**   | The Seal Project this applies to, or "All projects" for a tenant-wide exclusion.                                                                                |
| **Ecosystem** | The package manager / ecosystem (`pip`, `maven`, `apk`, `deb`, `rpm`, and so on). The Seal CLI implements exclusions per ecosystem; see the support list below. |
| **Package**   | The package name as the package manager identifies it.                                                                                                          |
| **Version**   | The specific version of the package.                                                                                                                            |

There is no "rename to" field. The CLI prepends a fixed `seal-` prefix to the package's name when it matches an exclusion.

## Creating, editing, deleting

<figure><img src="/files/TqTtyfRBWDVUYOUTvg7u" alt="Scanner exclusions tab populated with several exclusion rows"><figcaption><p>Creating, editing, and deleting exclusions all happen on the Scanner exclusions tab.</p></figcaption></figure>

All flows live on the [Scanner exclusions tab](/discovering/protection-page/scanner-exclusions-tab.md) on the Protection page. Only users with the **Sealer** or **Admin** role can manage exclusions.

To create one, open the tab, click **New exclusion** in the tab header, fill in the four fields, and save. The exclusion takes effect on the next CLI run for the relevant Seal Project.

Per-row Edit and Delete actions on the same tab handle the rest.

There is no Vulnerable-packages-tab row action for Scanner Exclusions, because the affected packages typically have no rows there.

## How exclusions are applied

The Seal CLI fetches the active exclusions for the Seal Project at the start of each run and renames the matching packages on disk, prepending `seal-` to each one. The package manager's database is updated to reflect the new name; the build's output ships with the renamed packages in place.

Two CLI-side conditions have to hold for this to happen:

1. The CLI has to run. Deployments that do not run the CLI in your pipeline (Artifact Server, Manual) cannot apply Scanner Exclusions.
2. The CLI has to run in **`remote` fix mode**. The CLI fetches the platform's exclusion list only in remote mode; in `local` or `all` mode the platform-stored exclusions are not consulted.

## Ecosystem support

Scanner Exclusions are implemented per ecosystem in the Seal CLI. Currently supported:

* OS package managers: apk, deb (apt-get, dpkg, and dpkg-less rootfs), rpm/yum
* Application ecosystems: Maven, Gradle, Python (pip and wheel files), Go modules, Ruby (Bundler)
* Java filesystem scanning (`seal fix --fs java`)

Not currently supported: npm, Yarn, pnpm, NuGet, .NET, Composer (PHP). For those ecosystems, the only available customer-side response to a false positive from an external scanner is to address it on the scanner side.

A Scanner Exclusion does not change Seal's view of the package. The Vulnerable packages tab and the rest of the Seal UI continue to behave as they would otherwise. The exclusion only changes what external scanners see when they scan the build's output.

## Related

* [The Scanner exclusions tab](/discovering/protection-page/scanner-exclusions-tab.md): the list-view reference on the Protection page.
* [Package renaming](/integrations/package-renaming.md): the sibling mechanism that handles sealed packages.
* [Choosing your deployment method](/setup-apps-os/choosing-deployment-method.md): which deployments do and do not run the CLI in CI.