Authentication
Last updated: Aug 12, 2026
Authenticating a scan attributes every run to whoever ran it. How you authenticate depends on who is running the scan: a person at a workstation signs in as themselves, while a pipeline or container authenticates as your group.
Authentication is currently optional and never blocks a scan, but a future release will require it. We recommend adopting it now so your runs are attributed to your group.
Start here
| Who runs the scan | Authenticates as | How |
|---|---|---|
| You, on your own machine | You | Browser login |
| A pipeline or container | Your group | A Group token, supplied one of the two ways below |
If you are setting up CI/CD, you want a Group token. If you are running a scanner on your laptop, sign in through your browser and skip the token entirely.
Authenticating as your group
A Group token is a credential scoped to your group, used by Fluid Attacks' command-line scanners and the CI Gate. Supply it in one of two ways.
| Way to supply it | Best for | What you store |
|---|---|---|
| Short-lived, via OpenID Connect | Any system that can mint OIDC tokens | Nothing — minted per job |
| Long-lived secret | Systems that cannot mint OIDC tokens | The Group token, as a secret |
Short-lived, via OpenID Connect (recommended)
Your CI/CD provider mints a short-lived, signed token for each job,
your scan names its group with --group,
and Fluid Attacks verifies it against a trust you define once,
issuing your group's access for that run.
There is no secret to store or rotate.
Follow the OIDC federation guide to set it up.
Long-lived secret
Where OIDC is not available,
generate a long-lived Group token and store it as a secret.
Generate it from your group's DevSecOps → Manage token flow
(see
CI Gate configuration),
then expose it to the scan as the INTEGRATES_API_TOKEN environment variable:
export INTEGRATES_API_TOKEN="<your-group-token>"
ss scan --strict .The token is used only to identify the caller; it is never printed or written to logs.
For scanners delivered as Docker containers, pass --group inside the docker run command and hand the token to the container as an environment variable
(-e INTEGRATES_OIDC_TOKEN or -e INTEGRATES_API_TOKEN).
Which should I use?
- Running a scan yourself, on your own machine? Sign in through your browser. Nothing to store, and the run is attributed to you.
- Can your CI/CD system or runtime mint OpenID Connect tokens? GitHub Actions, GitLab CI, Azure DevOps, Kubernetes, and many others can. Prefer OIDC — it avoids storing a long-lived secret.
- If it cannot, store a long-lived Group token.
The two group options authenticate the run identically; they differ only in whether a long-lived secret is stored. A browser login is different in kind: it authenticates you, not your group, and a supplied Group token takes precedence over it.
A separate personal API token authenticates you to the GraphQL API, not a scan — see API basics.
OWASP Benchmark results
Know about the Fluid Attacks scanner true positive rate of 100 on the OWASP Benchmark. A guide is included to reproduce the results in vulnerability detection.
Browser login
Sign in to the Fluid Attacks CLI through your browser, so scans on your own machine are attributed to you without storing a long-lived token.