> 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/all-mode.md).

# All Mode

The CLI automatically replaces *any* vulnerable package it encounters with a sealed version.

* **Pros:** "Set and forget." Zero configuration and no PRs required.
* **Cons:** Least amount of granular control. Every package fixed counts towards your quota. Low visibility into specific changes until they happen.

```bash
seal fix --mode=all
```

### Handling Vulnerability Scanners

Using sealed packages can sometimes confuse vulnerability scanners, as they may look at the package version number and assume it is still vulnerable.

Choose the strategy that fits your auditing requirements:

#### Strategy 1: API Integration (Recommended for Internal Scanners)

Seal supports direct API integrations with a variety of major scanners (Snyk, BlackDuck, GitHub Advanced Security, Ox Security, etc.).

* **How it works:** The Seal CLI communicates with your scanner's API to synchronize findings, marking specific vulnerabilities as "remediated" within the scanner's dashboard.
* **Best for:** Internal scans and operational dashboards.

#### Strategy 2: Package Renaming (Recommended for External/Audit Scanners)

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=xxxx --
```

#### Strategy 3: Manual Ignore

Manually marking alerts as "False Positive" or "Ignored" in your scanner's UI.

* **Best for:** Small teams or one-off exceptions.
