> 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/cli-integration/remote-mode/package-renaming.md).

# Package Renaming

The CLI renames the package artifact during installation (e.g., `pcre` becomes `seal-pcre`).

* **How it works:** Since the remediated version is effectively a fork, renaming it makes the change explicit. Scanners simply won't find the vulnerable package name in the manifest or binary.
* **Best for:** External audits, customer-run scans, and scanners not supported by API integration.

```bash
seal fix --mode=XXX --use-sealed-names=TRUE
```

### CI Integration Workflow

Regardless of the CI system, the golden rule of Seal CLI integration is **Timing**.

> **Timing Rule:** The Seal CLI must run **immediately after** packages are fetched/installed, but **before** the project is compiled or built.

#### Common Integration Patterns

1. **Standard CI (Jenkins, GitLab CI, CircleCI):** Add a shell step to download the CLI and run the `seal fix` command after your dependency fetch step (e.g., after `npm install` or `go mod download`).
2. **GitHub Actions:** Seal Security provides a dedicated GitHub Action. Simply add it to your workflow file `.github/workflows/main.yml`.
3. **Docker:** Add the CLI run command directly into your `Dockerfile` (often strictly for the build stage to keep the final image slim).