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 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 | Replaces 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.
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 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
--groupwith a Group token (short-lived via OIDC, or a long-livedINTEGRATES_API_TOKENsecret), or - omitting
--groupand authenticating with anINTEGRATES_API_TOKENthat belongs to a group's service account — the group is resolved for you, or - a browser login,
as long as
--groupis 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.
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
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
- The scan authenticates as described above.
- It resolves the Git root's nickname and asks the platform for that root's exclusions and the group's severity-breaking threshold.
- 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.
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
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-groupThis 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 .Findings exclusion
Learn about the NOFLUID functionality of the Fluid Attacks scanner as well as other methods which allow developers to exclude specific findings from reports.
Secure Context
Learn how a developer writes new code with Fluid Attacks Secure Context, what the feature does, and what its limits are.