Platform policy sync

Last updated: Oct 27, 2026

When an authenticated SAST (sast), SCA (sca), or secrets scanning (ss) run identifies its group, it automatically gets two policies from the Fluid Attacks platform. One policy is for the scanned Git root, and one is for that group. Then, the run applies them:

Platform policy	What it does to the scan
Excluded subpaths for the Git root	Replaces the scan's local `exclude` list
Minimum CVSS score to break the build for the group	Combines with the scan's local severity-breaking threshold, see below

Thus, you can manage exclusions and the severity gate in one place, the platform. You do not have to keep a local configuration file synchronized with them.

The severity-breaking threshold applies only when you set the run to break: with --strict, strict: true, or a local strictness_threshold. If not, the run reports its vulnerabilities and does not fail. The output shows the threshold of the group and tells that the run did not apply it.

When you set the run to break, the threshold is the strictest (lowest) value of the local strictness_threshold and the threshold of the group. With only strict, it is the threshold of the group, or each vulnerability if the group has no threshold. A vulnerability at the threshold also breaks the run. The output always shows the applied threshold and where it comes from. To continue to break the run on each vulnerability, declare strictness_threshold: low.

This is separate from NOFLUID comments and the .fluidattacks.yaml file, which are read from your source code and always apply, authenticated or not.

Requirements

Two things are always necessary: the run must identify a group, and the scanner must find a root nickname for the directory that it scans.

Resolving a group

The three scanners get a group in one of these ways:

With --group and a Group token (short-lived from OIDC, or a long-lived INTEGRATES_API_TOKEN secret).
Without --group, with an INTEGRATES_API_TOKEN of the service account of a group. The scanner finds the group for you.
With a browser login, if you also use --group.

Which runs are eligible

SAST and SCA get platform context only for executions that clients run with the official Docker image or the GitHub Action.
SS is a standalone binary and tries to get it on each execution.

This means a local ss scan --group my-group . run, signed in via ss login, does pick up my-group's platform policies — while the equivalent local sast or sca run does not.

Resolving a root nickname

The three scanners get the nickname of the Git root from one of these sources:

The remote URL of the repository. This is the same nickname that the Git repositories table of the Fluid Attacks platform shows.
namespace in your configuration file, if you set one.

If there is no Git remote and no namespace, the scan continues without platform context.

How it works

The scan authenticates as described above.
It finds the nickname of the Git root. Then, it gets the exclusions of that root and the severity-breaking threshold of the group from the platform.
The scan applies each of the two values that the platform has configured. These values replace the values of the local configuration file of the scan. If the platform does not have a value (for example, no severity policy), the scan uses your local configuration for that value.

The platform's exclusions replace your local exclude list for that scanner — they are not merged with it. If you rely on both, make sure the platform's exclusions already cover what your local file excludes, or expect the local entries to be dropped for that run.

Non-blocking by design

If the scanner cannot get the platform context, the scan does not fail. The scan logs a warning and continues with the local exclusions and severity threshold in these conditions:

The authentication fails.
The scanner cannot connect to the platform.
The credential cannot access the group.
The scanner cannot find the nickname of the root.

Example

SAST and SCA are delivered as Docker containers. Thus, a CI/CD job runs the scan inside the container image and does not install a binary. This example uses GitLab CI and authenticates as a group with OIDC (for the trust setup, read OIDC federation):

# .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

The platform attributes this run to my-group. The run gets the severity-breaking threshold of my-group and the configured exclusions of this repository. You do not have to use a local configuration file for them.

SS is different: it is a standalone binary. Thus, its job installs it directly on the runner and does not pull 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 .