> 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/internal-scanners/how-cli-sync-works.md).

# How CLI-driven sync works

Every scanner integration covered in this chapter runs as part of the same `seal fix` invocation that does the substitution. The sync is a post-step inside the same CLI run; there is no separate command to schedule or monitor.

## The lifecycle of a sync

1. The CI pipeline reaches the Seal CLI step, configured with the scanner credentials.
2. The Seal CLI runs `seal fix` in the configured fix mode (local, remote, or all). It substitutes vulnerable packages with their sealed iterations per the deployment method's rule source.
3. The Seal CLI builds a list of the vulnerabilities sealed by this run. For each vulnerability:
   * **API-sync integrations** call the scanner's API to mark the corresponding finding as remediated, dismissed, or ignored (depending on what the scanner accepts).
   * **Policy-file integrations** append an entry to the scanner's policy file (`.snyk` or `.grype.yaml`) in the repository checkout. The file is written before the build moves on; committing the file into the branch is your responsibility.
4. The CLI exits. The scanner observes the new state on its next scan (for policy-file integrations) or immediately (for API-sync integrations).

## What gets updated

Only the vulnerabilities sealed by this run. A sync does not retroactively process vulnerabilities sealed by earlier runs or by other Seal Projects; each run handles what it just sealed.

Vulnerabilities that are open in your codebase but not yet sealed (no sealed version, or no Sealing Rule) stay open in the scanner. The integration does not suppress findings Seal has not addressed.

## What does not get updated

* **Out-of-band scans.** Snyk and Black Duck both support scans triggered outside CI (the IDE plugin, the web UI's "scan now"). These read the same underlying project state, so API-sync updates apply to them as well. Scans on a Git branch that has not yet received the policy-file commit do not see the suppression.
* **Other scanners.** A run configured for Snyk only does not push updates to Black Duck, even if Black Duck would alert on the same vulnerability. Each integration is independent.
* **Other Seal Projects.** Each `seal fix` run carries one `SEAL_PROJECT` value. The sync is attributed to that project; other Seal Projects are not affected.

## When the sync runs vs when the substitution runs

The substitution itself happens early in `seal fix`. The sync runs after, once the CLI knows what it has sealed. If the substitution fails, the sync does not run; there is nothing to report.

If the sync fails (a bad token, an unreachable scanner endpoint), the CLI logs the failure and exits with an error code. The substitution itself is unaffected; your build has the sealed packages in place even if the scanner's state was not updated.

## Frequency

There is no separate cadence for the sync. It runs every time `seal fix` runs. In a Remote-mode deployment, that is every build. In a Local-mode deployment, that is also every build. In an Automatic Remediation deployment, that is every build, with every sealable vulnerability covered.

## Reattribution and re-runs

Re-running `seal fix` against the same checkout reissues the sync. For API-sync integrations, the second call typically no-ops (the finding is already in the target state). For policy-file integrations, the CLI deduplicates: re-running `seal scan --generate-snyk-policy` against an already-up-to-date `.snyk` does not produce a new entry per vulnerability.

## Related

* [Seal Apps via the Seal CLI in CI/CD](/setup-apps-os/cli-in-cicd.md): the CLI integration these sync mechanics ride on.