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

# SentinelOne integration

<figure><img src="/files/aE78uXsVOEnIRdyyuZ5a" alt="SentinelOne" width="280"><figcaption></figcaption></figure>

The Seal CLI calls the SentinelOne CNAPP API after every `seal fix` run and updates the matching SentinelOne scanner policy to exclude the vulnerabilities Seal has sealed.

## Before you start

* A SentinelOne API token with permissions to update scanner policies in the target scope.
* Your SentinelOne tenant URL.
* The scope under which the relevant scanner policy lives. SentinelOne policies are scoped (for example, by site or account); you need the scope type and the IDs that identify your scope.
* A tag value Seal can use to identify the specific scanner policy to update. Apply the same tag to the policy in SentinelOne and configure it here.

## Configuration

Set these in your CI environment:

```bash
SEAL_SENTINELONE_URL=<your sentinelone tenant url>
SEAL_SENTINELONE_TOKEN=<sentinelone api token>
SEAL_SENTINELONE_SCOPE_TYPE=<scope type, for example: site, account>
SEAL_SENTINELONE_SCOPE_IDS=<comma-separated scope ids>
SEAL_SENTINELONE_TAG=<tag identifying the scanner policy>
```

Or in `.seal-config.yml` at the project root:

```yaml
sentinelone:
  url: <your sentinelone tenant url>
  token: <sentinelone api token>
  scope-type: <scope type>
  scope-ids:
    - <scope id 1>
    - <scope id 2>
  tag: <tag identifying the scanner policy>
```

## How findings are updated

For each vulnerability Seal sealed in the run, the CLI looks up the SentinelOne scanner policy carrying the configured tag within the configured scope, then adds the vulnerability to the policy's CVE-exception list. SentinelOne's next scan against the same scope stops reporting those vulnerabilities.

If no policy with the configured tag exists in the scope, the integration logs the mismatch and the build fails. Create the matching policy in SentinelOne (with the tag set) before running the CLI.

## Verify

After a `seal fix` run with the integration configured, open the targeted SentinelOne scanner policy. The CVE exceptions list should include each vulnerability Seal sealed in this run.

## Related

* [How CLI-driven sync works](/integrations/internal-scanners/how-cli-sync-works.md)