Platform policy sync

Last updated: Sep 15, 2026


When an authenticated SAST (sast), SCA (sca), or secrets scanning (ss) run resolves to a group, it automatically fetches two policies already configured on Fluid Attacks' platform for the scanned Git root and that group, and applies them to that run:

Platform policyWhat it does to the scan
Excluded subpaths for the Git rootReplaces the scan's local exclude list
Minimum CVSS score to break the build for the groupReplaces the scan's local severity-breaking threshold

This means you can manage exclusions and the severity gate in one place — the platform — instead of keeping a local configuration file in sync with them.

Requirements

Two things are always required: the run must resolve to a group, and the scanner must be able to resolve a root nickname for the directory it is scanning.

Resolving a group

All three scanners resolve a group either by:

  • passing --group with a Group token (short-lived via OIDC, or a long-lived INTEGRATES_API_TOKEN secret), or
  • omitting --group and authenticating with an INTEGRATES_API_TOKEN that belongs to a group's service account — the group is resolved for you, or
  • a browser login, as long as --group is passed alongside it.

Which runs are eligible

  • SAST and SCA only fetch platform context for a client-distributed execution — the official Docker image or the GitHub Action.
  • SS ships as a standalone binary and attempts it on every execution.

Resolving a root nickname

All three scanners derive the Git root's nickname from the repository's remote URL (the same nickname shown on the platform's Git repositories table), or from namespace in your configuration file if you set one. If neither is available — for example, scanning a bare directory with no git remote and no namespace — the scan proceeds without platform context.

How it works

  1. The scan authenticates as described above.
  2. It resolves the Git root's nickname and asks the platform for that root's exclusions and the group's severity-breaking threshold.
  3. Whichever of the two values the platform has configured is applied to the run, overriding whatever the scan's local configuration file set for that value. A value the platform has not configured (for example, no severity policy set) is left alone, and your local configuration is used instead.

Non-blocking by design

Fetching platform context never fails a scan. If authentication fails, the platform is unreachable, the credential cannot access the group, or the root's nickname cannot be resolved, the scan logs a warning and proceeds with whatever exclusions and severity threshold are set locally.

Example

SAST and SCA are delivered as Docker containers, so a CI/CD job runs the scan inside the container image rather than installing a binary. GitLab CI, authenticating as a group through OIDC (see OIDC federation for the trust setup):

# .gitlab-ci.yml
sast:
  image: docker.io/fluidattacks/sast:latest
  id_tokens:
    INTEGRATES_OIDC_TOKEN:
      aud: https://app.fluidattacks.com
  script:
    - sast scan . --group my-group

This run is attributed to my-group, and picks up my-group's severity-breaking threshold plus this repository's configured exclusions — no local configuration file needed for either.

SS, by contrast, ships as a standalone binary, so its job installs it directly on the runner instead of pulling a container image:

# .gitlab-ci.yml
secrets-scan:
  image: ubuntu:latest
  id_tokens:
    INTEGRATES_OIDC_TOKEN:
      aud: https://app.fluidattacks.com
  script:
    - curl -fsSL https://public.fluidattacks.com/ss/install.sh | sh
    - ss scan --group my-group .

On this page