Scanner Exclusions

A workaround for false positives that external scanners raise against packages Seal does not consider vulnerable.

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 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.

• 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

Creating, editing, and deleting exclusions all happen on the Scanner exclusions tab.

All flows live on the Scanner exclusions tab 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: the list-view reference on the Protection page.

• Package renaming: the sibling mechanism that handles sealed packages.

• Choosing your deployment method: which deployments do and do not run the CLI in CI.