> 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/integrations/package-renaming.md).

# Package renaming

External scanners cannot be updated through an API; by definition, you do not control them. When such a scanner runs against your software, it sees the origin package's name and version and, even though the underlying iteration is a sealed (already-remediated) version, the scanner emits the same vulnerability alert as it would against the unsealed origin.

Renaming is Seal's recommended configuration for working with external scanners. When the Seal CLI runs with renaming enabled, every sealed package it installs is recorded under a `seal-` prefixed name. The scanner reads the manifest and sees `seal-<package>`, which it does not match against the vulnerability database, so the alert does not fire. The package itself is the sealed iteration; the prefix is the only difference visible to the scanner.

The magic, and the reason this works rather than breaking your build, is that consuming code is unaffected. References to the original package name still resolve to the sealed iteration; nothing in your application source has to change. Renaming applies at the package-manager layer, not at the import or require layer.

Use renaming to eliminate false positives from external scanners. Don't use renaming for scanners your organization runs internally; for those, the [internal scanner integrations](/integrations/internal-scanners.md) update the scanner's findings directly and need no renaming.

## In this chapter

* [Renaming sealed packages](/integrations/package-renaming/renaming-sealed.md): enabling the `seal-` prefix on every sealed package the CLI installs.
* [Renaming non-vulnerable packages that trigger false positives](/integrations/package-renaming/renaming-non-vulnerable.md): the Scanner Exclusion path for packages that are not vulnerable but still get flagged.

For the per-ecosystem naming pattern Seal applies when renaming, see [Naming and versioning conventions: Renamed packages](/reference/naming-and-versioning/renamed-packages.md).

## Why scanners produce false positives in the first place

Scanners that emit false positives against sealed packages do so for one of two reasons:

* **Incorrect version ranges in the vulnerability advisory.** The advisory's "affected versions" range is too broad and matches a version that is not in fact affected.
* **Retracted or disputed vulnerabilities.** The vulnerability has been retracted or its applicability is disputed, but the scanner's vulnerability database has not caught up.

In either case the scanner is matching on the package name and version string. Renaming avoids the match.