Authentication

Last updated: Jul 17, 2026


Authenticating a scan attributes every run to your Fluid Attacks group. Fluid Attacks' command-line scanners and the CI Gate authenticate with a CI Gate token, a credential scoped to your group. Supply it in one of two ways.

Two ways to supply it

Way to supply itBest forWhat you store
Short-lived, via OpenID ConnectAny system that can mint OIDC tokensNothing — minted per job
Long-lived secretSystems that cannot mint OIDC tokensThe CI Gate token, as a secret

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 CI Gate 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-ci-gate-token>"
ss scan --strict .

The token is used only to identify the caller; it is never printed or written to logs.

Which should I use?

  • 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 CI Gate token.

Both authenticate the run to your group identically; they differ only in whether a long-lived secret is stored.

A separate personal API token authenticates you to the GraphQL API, not a scan — see API basics.

On this page