ss

Last updated: Oct 27, 2026

ss is Fluid Attacks' native binary for secrets detection. It scans your source code for hardcoded credentials, API keys, tokens, and similar sensitive data. When a detection rule has a verifier, ss also sends a request to the provider to learn if the secret is active. Thus, you can first examine the credentials that give access at this time. Different from the Docker-based scanners, ss is a single self-contained binary that runs without Docker. By default, it runs without authentication. If you want, you can authenticate to attribute runs to your Fluid Attacks group.

Installation

Linux and macOS

Run the one-line installer:

curl -fsSL https://public.fluidattacks.com/ss/install.sh | sh

This installs the ss binary to /usr/local/bin by default.

Verify the installation

ss --version

Quick scan

To scan a directory or file without a configuration file:

ss scan /path/to/your/project

The scanner shows the findings directly in the terminal. Use --strict to exit with code 1 when the scanner finds secrets. This is useful to block CI/CD pipelines:

ss scan /path/to/your/project --strict

Scan with a configuration file

For more control of paths, output format, and scan behavior, give a YAML configuration file with --config:

ss scan --config ss-config.yaml

Secret verification

Many detection rules have a verifier. A verifier describes an API request to the provider. The result of this request tells if a secret is active. When a match is from one of these rules, ss sends that request during the scan and classifies the secret from the answer. Verification runs automatically in quick scans and in configuration file scans. You do not have to change the configuration, and you cannot disable it.

For each match, ss sends one request to the provider that issued the secret (for example, the Google APIs discovery service for a GCP API key). The request uses only the detected value. The request times out after five seconds and does not follow redirects. ss does not show the secret value or write it to logs.

Verification outcomes

E: is the exploit maturity metric of the CVSS v4.0 vector. E:A (attacked) shows an active secret. E:U (unreported) shows a secret that ss cannot confirm. Findings from rules without a verifier always have E:U.

ss removes inactive secrets before it writes the results. Thus, they do not count for --strict. Only secrets that are active or that ss cannot check block a pipeline.

Where the outcome appears

• Terminal: shows only the reported findings. The summary at the end of the scan includes the number of removed inactive secrets.
• CSV: the verified column holds active, unverifiable, or the reason why the rule has no verifier (described below). The cvss_v4 column contains the E: metric.
• SARIF: the cvss_v4 property of each result contains the E: metric.

Rules without a verifier

An HTTP request cannot check all secrets. When a rule has no verifier, the verified column of the CSV report tells why:

Authenticate (optional)

By default, ss runs without authentication. If you want, you can authenticate to attribute the runs to your Fluid Attacks group.

If you run ss on your own machine, you do not have to use a Group token. Run ss login one time to sign in through your browser. You do not have to keep a secret.

In other conditions, authenticate with the Group token of your group, in one of these ways:

• Long-lived secret: set the INTEGRATES_API_TOKEN environment variable to a Group token. Get it from Organization → Groups → GroupName → DevSecOps → Manage token in the platform.
• Short-lived, from OIDC: this method is for systems that can issue OpenID Connect tokens (CI/CD, AWS, GCP, Kubernetes, and more). Use --group <your-group>, and ss gets a token for each run with no stored secret. On GitHub Actions, ss gets the token automatically. On other systems, give the token as the INTEGRATES_OIDC_TOKEN environment variable.

If the two tokens are available, the scanner uses the stored secret.

For the full guide, read Authentication. It includes the OIDC federation setup. For pipeline examples, read CI/CD integration.

The scanner uses the token only to identify the caller. It does not show the token or write it to logs.

Common scenarios

Scan only specific directories (monorepo)

ss:
  include:
    - services/api/
    - services/web/
  exclude:
    - services/legacy/

Block the pipeline on findings

To block a pipeline with strict mode, read Distributed binaries.

Troubleshooting

For common installation troubleshooting (permission denied, PATH issues), read Distributed binaries.

Too many false positives

If ss reports a value that is not a secret, send an email to [email protected] with the rule name, the file and the line of the finding.

A known secret is not reported

If ss finds a secret and the provider reports it as inactive, ss removes the finding from the results and counts it in the scan summary as an inactive secret. The value stays in your source code. Remove it and rotate the related credentials.

No output file is produced

Make sure that output.file_path is set in your configuration file and that the extension is .sarif or .csv. Other extensions cause an error.

Cannot use '--config' and a path together

You cannot use --config and a positional path argument together. Use only one of them:

# Config file mode
ss scan --config ss-config.yaml

# Quick scan mode
ss scan /path/to/project