Use a configuration file

Last updated: Oct 6, 2026

The most flexible way to run any of Fluid Attacks' scanners is with a YAML configuration file.

Here is a simple example showing the recommended configuration of the SAST CLI:

namespace: myapp
output:
  file_path: ./Fluid-Attacks-Results.csv
  format: CSV
working_dir: .
language: EN
sast:
  include:
    - .
  exclude:
    - glob(**/node_modules/**)
    - glob(**/test/**)

Common configuration file keys

There are some common keys that apply to all of Fluid Attacks' scanners. Here is a breakdown of what each key in the configuration file represents.

All keys are optional, so you can customize scans to your needs. Therefore, the tool should function correctly even if some keys are missing from the configuration file.

namespace

namespace indicates a name for the analysis, typically the name of the repository being analyzed. For example:

namespace: my_app

working_dir

working_dir indicates the path to the repository you want to analyze. If configuring paths in the apk, sast, or sca keys, write such paths relative to this directory. For example:

working_dir: /absolute/path/to/directory

commit

Use commit to include the current commit SHA of the repository you want to analyze, only if you require it in the SARIF results file. For example:

commit: e59607b9de3ef4c13d292705fg3da1ff0c67eb38

language

language indicates the language for the vulnerability report. Valid values are EN (English) and ES (Spanish). The default value is EN if not specified. For example:

language: ES

output

output indicates where scan results are stored and in what format. By default, vulnerability reports are displayed in the terminal. You can use these options:

• file_path: Defines the output file location
• format: Defines the output format, which can be CSV (comma-separated values), SARIF (Static Analysis Results Interchange Format), or ALL (generates both CSV and SARIF simultaneously)

For example:

output:
  file_path: relative/path/to/file
  format: CSV

checks

checks specifies which weaknesses to look for. See the documentation of weaknesses in Fluid Attacks' classification, which includes detailed descriptions, to make your choice. If this key is not present, the target is checked for all vulnerabilities. This is generally recommended to ensure comprehensive scans.

The following is an example for checking against F050 (Guessed weak credentials) and F279 (Root detection control bypass):

checks:
  - F050
  - F279

tracing_opt_out

Set tracing_opt_out to true to prevent the scanner from sending anonymized telemetry to Fluid Attacks' servers. Defaults to false.

tracing_opt_out: true

strict

strict configures the scan to run in strict mode, failing the execution (breaking the build) if any vulnerabilities are found (with an exit code 1). Ideal for using the scanner as a CI/CD job. Enable strict mode as follows:

strict: true

strictness_threshold

strictness_threshold is supported by the SAST, SCA, and DAST scanners. It sets a severity floor for pipeline gating. When configured, the scan exits with code 1 only if at least one vulnerability is found at or above the specified severity level. Valid values are none, low, medium, high, and critical.

strictness_threshold: high

For example, setting strictness_threshold: high breaks the pipeline only when a high or critical vulnerability is found, while low and medium findings are still reported but do not interrupt the execution.

Specify paths in the include/exclude subsections

In the sast, sca and apk keys, include and exclude read each path as a line of a .gitignore file, the same way the platform does when it removes out-of-scope files from the repositories it downloads. The same rule therefore selects the same files in include and in exclude, and in the scanner and in the platform. Paths are relative to the working directory (if the working_dir key is not defined, the working directory is automatically set to the directory from which you called the scanner execution).

You can specify your paths in these ways:

• Using the path of a file or a directory, for example:

namespace: namespace
working_dir: /test/directory
sast:
  include:
    - src/main/java/org/test/Test.java
    - src/main/java/org/test/utils/

• Using patterns, for example:

namespace: namespace
working_dir: /test/directory
sast:
  include:
    - .
  exclude:
    - docs
    - "*.min.js"
    - src/**/test*.py
    - "!src/test_keep.py"

The rules that apply are those of a .gitignore file:

• A pattern without a slash, like docs or *.min.js, matches at any depth. A pattern with a slash in the middle or at the start, like src/*.py or /docs, is relative to the working directory.
• A trailing slash, like docs/, matches only directories and everything under them.
• * and ? do not cross a slash. ** does: src/**/test*.py matches src/test_a.py and src/a/b/test_a.py, and **/*.py matches Python files at any depth, including the root of the working directory.
• [abc] and [a-z] match one character of the set. Escape a bracket with a backslash to match it literally, as in file\[1\].txt. A path that exists in the working directory, like app/[id]/, is always read literally.
• A line that starts with ! brings a path back after an earlier rule rejected it. A path under a directory that was rejected as a whole cannot be brought back.
• A line that is not a valid pattern is skipped with a warning, and the other lines still apply.
• . selects everything in the working directory. It is the recommended value of include. .git and node_modules are never analyzed.

The glob(...) form is still accepted, and glob(**/*.py) is read as **/*.py. Use the plain pattern in new configurations.

The recommended configuration is to scan all paths of working_dir by using . in the include option:

sast:
  include:
    - .

Next, see the section specific to each scanner to know what other keys are supported in each case:

• MAST scanner
• Container scanner
• CSPM scanner
• DAST scanner
• SAST scanner
• SCA scanner
• Secret Scanning scanner

Authenticate

Authenticating attributes the scan to your Fluid Attacks group. Every Fluid Attacks scanner authenticates each run with a Group token, supplied either short-lived via OpenID Connect (pass --group; nothing stored) or as a long-lived INTEGRATES_API_TOKEN secret.

See Authentication for setup.