Local Mode

The rules for sealing packages are defined in a .seal-actions.yml file located within your project's root directory.

• Pros: Fully tracked by source control (Git). Every change requires a Pull Request, keeping developers in full control of the remediation process.

• Cons: Decentralized. Security teams cannot force a fix without engineering involvement.

seal fix --mode=local

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.

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.