> 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/setup-containers/seal-my-container/renaming.md).

# Renaming packages inside containers

External scanners that compare an image's installed packages against a public vulnerability feed sometimes flag sealed packages as vulnerable. The package's version string in the database still looks like the upstream `openssl-3.3.2-r5` to the scanner — even though Seal has remediated the vulnerabilities — and the scanner reports a known CVE against that version.

Renaming sealed packages inside the image is the simplest way to make external scanners stop flagging them. The CLI rewrites the package-database entries with a `seal-` prefix, so the names in `apk info`, `dpkg-query`, and `rpm -q` no longer match the public feed. The underlying files (binaries, libraries, headers) are unchanged: applications that depend on the packages by their upstream names continue to resolve them correctly, because a virtual-package mechanism preserves the original-name lookups at runtime.

Renaming is the recommended default in Seal OS contexts and in Seal My Container. Enable it unless you have a specific reason not to.

## Enabling renaming

Set `SEAL_USE_SEALED_NAMES=1` in the environment before invoking `seal image fix`:

```bash
export SEAL_USE_SEALED_NAMES=1
export SEAL_TOKEN=<token>
export SEAL_PROJECT=my-app-image

seal image fix \
  my-registry.example.com/my-app:1.0.0 \
  --platform linux/amd64
```

The CLI passes the flag through to the inner `seal fix --os` step, which writes renamed package entries into the image's package database instead of the upstream names. The resulting image still installs and runs identically; only the names a scanner sees in the package database change.

## When you do not need renaming

For internal scanners that consume Seal's vulnerability feed directly, no extra configuration is needed and renaming is unnecessary. The scanner sees the sealed packages, looks them up in Seal's feed, and reports them as remediated. The scan comes out clean automatically; you do not need to do anything beyond running the scanner as usual.

For internal scanners that do not consume Seal's feed but do accept ignore-list or policy-file configuration (Snyk via `.snyk`, Grype via `.grype.yaml`, and so on), the CLI can edit those files to declare the sealed packages as acknowledged. That path is documented under [Internal scanner integrations](/integrations/internal-scanners.md) and is the right choice when the scanner is one you control.

Renaming is the right path when the scanner is **external** — owned by a customer, regulator, or another team that does not consume Seal's feed and that you cannot configure — and the only thing you can change is what is inside your image.

## Verifying the rename

After a renamed seal, inspect the image's package database:

{% tabs %}
{% tab title="Alpine" %}

```bash
docker run --rm <sealed-image> apk info | grep -i seal-
```

The sealed packages appear with the `seal-` prefix.
{% endtab %}

{% tab title="Debian / Ubuntu" %}

```bash
docker run --rm <sealed-image> dpkg-query -W | grep -i seal-
```

The sealed packages appear with the `seal-` prefix.
{% endtab %}

{% tab title="RHEL family" %}

```bash
docker run --rm <sealed-image> rpm -qa | grep -i seal-
```

The sealed packages appear with the `seal-` prefix.
{% endtab %}
{% endtabs %}

Applications inside the image that depend on the packages by their original names continue to work: opening files, linking against libraries, and running binaries all resolve the same paths as before. The rename is a database-level rewrite, not a filesystem rewrite.

If no renamed entries appear after `seal image fix`, `SEAL_USE_SEALED_NAMES=1` was not set in the environment when the command ran. Re-run with the variable exported in the same shell as the `seal image fix` invocation.

## Related

* [Package renaming](/integrations/package-renaming.md): the canonical home for renaming as a strategy, including the per-ecosystem naming convention.
* [Common issues](/setup-containers/seal-my-container/common-issues.md): edge cases when running the renamed image.
* [Internal scanner integrations](/integrations/internal-scanners.md): the alternative path when the scanner is one you control and will accept Seal's findings via API or a policy file.