CI Gate installation

Last updated: Oct 26, 2026

You can use the Fluid Attacks CI Gate on any x86_64 or aarch64 machine that has Docker installed. CI Gate must connect to the API. Thus, Internet access is necessary. You can also add this security gate to your CI/CD. Thus, your builds and releases do not include vulnerabilities that the Fluid Attacks platform reported.

To use CI Gate, these are the requirements:

1. Make sure that you have a Group token. You can generate this token in the DevSecOps section of the platform (Organization > Groups > GroupName > DevSecOps). In this section, you find the CI Gate card.

   

2. Click the Manage token button. A pop-up window opens, where you can generate the token. If you already generated one, click Reveal token.

   

To run the CI Gate on your local machine:

1. Make sure that your execution environment has the required dependency: Docker (>= 20.10.10).
2. To install Docker, follow the official guide.

Arguments

You can change the behavior of the CI Gate on your local machine or in your CI/CD pipeline. These are the arguments:

Required

Use one of these arguments to authenticate:

• --token: the Group token of your group (a service token), from Organization > Groups > GroupName > DevSecOps > Manage token.
• --group: your Fluid Attacks group. Use it to authenticate with CI OIDC without a stored token. For the setup, see OIDC federation.

Optional

• --breaking: Customizes the severity for the strict mode. Vulnerable locations with a severity below this threshold do not break the pipeline. The values go from 0.0 (recommended) to 10.0.

  • If you use it, and the related platform policy has a value, CI Gate uses the lower of the two values.
  • If you use it, and the related platform policy has no value, CI Gate uses the value of --breaking.
  • If you do not use it, and the related platform policy has a value, CI Gate uses the value of the policy.
  • If you do not use it, and the related platform policy has no value, CI Gate uses the default value, 0.0.

• --dynamic: Gets only the vulnerabilities of the INPUTS type. These are related to running environments, endpoints, URLs, and container images. They include these techniques: Web DAST, API DAST, CS, PTaaS, and RE.

  If you do not use it, CI Gate gets all the types of vulnerabilities.

• --feature-preview: Enables the feature preview mode. This mode controls the data source of the vulnerability information:

  • False uses a resolver that relies on OpenSearch.
  • True uses a resolver that relies on DynamoDB.

  The default is False.

• --inherited: Tells CI Gate which vulnerabilities from SCA to ignore when it breaks the build:

  • all: CI Gate ignores all the vulnerabilities that SCA detects.
  • build: CI Gate ignores the vulnerabilities in third-party components that your software uses only in the development stage.
  • run: CI Gate ignores the vulnerabilities in third-party components that your software uses in the production stage.

• --repo-name: The nickname of the Git repository on the Fluid Attacks platform. If you use it, CI Gate gets only the vulnerabilities of this repository.

• --repo-path: The path to look for in the report. CI Gate includes the static vulnerabilities that match these paths and discards the others. You can use globs in quotation marks, for example, path/to/product or "path/to/other/product/**" or "**/*.py".

  To give more than one path to CI Gate, use --repo-path one time for each path, for example, --repo-path path1 --repo-path path2 --repo-path "path3/*".

  CI Gate does not examine if these paths are in the repository. When the structure of the repository changes, examine and update the paths.

• -O / --output: If you use it, CI Gate saves the output of the execution in JSON format in the file that you specify.

• -p / --proxy: Sets the address of the HTTP proxy for the requests.

  The default is "".

• --static: Gets only the vulnerabilities of the LINES type. These are related to source code and include these techniques: AI SAST, SS, SAST, SCA, and SCR.

  If you do not use it, CI Gate gets all the types of vulnerabilities.

• --strict/--lax: Enables or disables the strict mode. In strict mode, CI Gate breaks the build if there are open or untreated vulnerabilities.

  The default is --lax.

• --verbose: Sets the level of detail of the report.

  • -v: Shows the non-compliant vulnerable locations that break the policy1, 2, and thus, the build in strict mode.
  • -vv: Shows all the vulnerable locations, compliant or not.

  The default is -vv.

• --verify-proxy-ssl/--no-verify-proxy-ssl: Enables or disables the validation of SSL certificates when CI Gate sends requests through an HTTP proxy. Disable it if the proxy uses self-signed certificates.

  The default is --verify-proxy-ssl.

  To trust your own certificate authority, for example, behind a proxy that inspects TLS traffic, mount a PEM bundle that contains it. Then set the SSL_CERT_FILE environment variable to its path. The bundle replaces the default roots. Thus, it must also contain the public roots that are necessary to reach the platform.

Run CI Gate on your local machine

This section has examples to run CI Gate on a local machine. You can use different arguments for your context.

When Docker is installed on your local machine, run this command to get the Docker image with all the dependencies of CI Gate:

docker pull fluidattacks/forces:latest

These are some examples to run the container:

• To check all findings, including static and dynamic:

  docker run --rm -ti fluidattacks/forces:latest forces --token <your-token> -vv

• To check static locations only:

  docker run --rm -ti fluidattacks/forces:latest forces --static --strict --token <your-token>

• To check dynamic locations only:

  docker run --rm -ti fluidattacks/forces:latest forces --dynamic --strict --token <your-token>

• To verify the locations of a specific repository:

  docker run --rm -ti fluidattacks/forces:latest forces --dynamic --strict --repo-name <nickname repo> --token <your-token>

• To break the pipeline only if CI Gate finds vulnerabilities with a severity of 4.5 or more:

  docker run --rm -ti fluidattacks/forces:latest forces --dynamic --strict --breaking 4.5 --token <your-token>

  The --rm and --ti parameters are optional. Use them as necessary for your context.

Run CI Gate on your CI/CD

To run CI Gate in the pipeline of your repository, see these examples.

Bitbucket Pipelines

On Bitbucket Pipelines, add these lines to your configuration file:

# bitbucket-pipelines.yml
pipelines:
  default:
    - step:
      name: Fluid-Attacks-CI-Gate
      services:
        - docker
      script:
        - docker pull fluidattacks/forces:latest
        - docker run fluidattacks/forces:latest forces --token <your-token>

GitLab

On GitLab, add these lines to your .gitlab-ci.yml:

forces:
  image:
    name: fluidattacks/forces:latest
script:
  - forces --token <your-token> --strict --repo-name <repository name>

Azure DevOps

On Azure DevOps, add these lines to your configuration file:

jobs:
  - job: Fluidattacks Agent
    pool:
      vmImage: "ubuntu-latest"
    steps:
      - script: |
          docker pull fluidattacks/forces:latest \
            && docker run fluidattacks/forces:latest forces --token

Jenkins

On Jenkins, this is an example of the configuration file:

pipeline {
  agent {
    label 'label'
  }
  environment {
    TOKEN = "test"
  }
  stages {
    stage('Forces') {
      steps {
        script {
          sh """
            docker pull fluidattacks/forces:latest
            docker run fluidattacks/forces:latest forces --token ${TOKEN} --repo-name
          """
        }
      }
    }
  }
}

GitHub

On GitHub, this is an example of the configuration file:

jobs:
  forces:
    runs-on: ubuntu-latest
    container:
      image: fluidattacks/forces:latest
      env:
        TOKEN:
        REPO_NAME:
    steps:
      - name: Run Agent check
        run: forces --token ${TOKEN} --strict --repo-name ${REPO_NAME}

Harness

On Harness, include this in the YAML file that defines your pipeline:

stages:
  - stage:
      name:
      identifier: AgentStage
      type: CI
      spec:
        cloneCodebase: false
        infrastructure:
          type: KubernetesDirect
          spec:
            connectorRef:
            namespace: default
        execution:
          steps:
            - step:
                type: Run
                name:
                identifier: RunAgentCheck
                spec:
                  connectorRef:
                  image: fluidattacks/forces:latest
                  shell: Bash
                  command: |
                    forces --token ${secrets.getValue("AGENT_TOKEN")}

Execution logs and results

After each execution of the CI Gate, you can see its logs in the DevSecOps tab of the platform. The tab is in Organization > Groups > GroupName > DevSecOps. For more information about this section, see the article "Prevent the deployment of builds with vulnerabilities."

You can also get the report in JSON format with the --output CLI argument. For example, if you run CI Gate with --output report.json, CI Gate creates a report.json file with this structure:

{
  "findings": [
    {
      "identifier": "111111111",
      "title": "083. XML injection (XXE)",
      "status": "vulnerable",
      "exploitability": "Proof-of-concept",
      "severity": 3.2,
      "url": "https://app.fluidattacks.com/v/111111111",
      "vulnerabilities": [
        {
          "type": "STATIC",
          "technique": "SAST",
          "where": "src/Parsers/XmlLoader.cs",
          "specific": "42",
          "state": "vulnerable",
          "severity": 3.2,
          "report_date": "2023-08-13 09:58:38-05:00",
          "root_nickname": "my-root",
          "exploitability": "Proof-of-concept",
          "treatment": {
            "status": "UNTREATED",
            "acceptance": null
          },
          "compliance": false,
          "scope": null,
          "epss": null,
          "reachability": null
        }
      ],
      "managed_vulns": 0,
      "unmanaged_vulns": 1
    }
  ],
  "summary": {
    "vulnerable": {
      "dynamic": {
        "API_DAST": 0,
        "CLOUD": 0,
        "CS": 0,
        "CSPM": 0,
        "DAST": 0,
        "MAST": 0,
        "PTAAS": 0,
        "RE": 0,
        "SCA": 0,
        "WEB_DAST": 0
      },
      "total_dynamic": 0,
      "static": {
        "SAST": 1,
        "SCA": 0,
        "SCR": 0,
        "AI_SAST": 0,
        "SS": 0
      },
      "total_static": 1
    },
    "overall_compliance": false,
    "elapsed_time": "0.4392 seconds",
    "total": 1
  }
}

The JSON report is the interface for scripts and tools that parse the CI Gate results. The console report is for people to read, and it can change between releases.

CI Gate creates the report file inside the container. Because of the --rm parameter, Docker removes the file when the container stops. To keep the file on your local machine, mount a volume. For example:

docker run --rm \
  -v $(pwd):/output \
  fluidattacks/forces:latest forces \
  --strict \
  -O /output/report.json \
  --repo-name <repository nickname> \
  --token $TOKEN

Troubleshooting

1. Make sure that your Docker engine version is 20.10.10 or a subsequent version.

   docker --version
   Docker version 20.10.10, build v20.10.10

   This is important because CI Gate uses GNU libc version 2.34 or a subsequent version. Docker 20.10.9 and earlier versions use a default seccomp profile. This profile does not support the clone syscall that GNU libc version 2.34 introduced.

2. Make sure that your Docker installation works. If it works, you can run a Hello World:

   docker run hello-world
   Hello from Docker!
   This message shows that your installation appears to be working correctly.
   ...

   If it does not work, see the Docker documentation and the Docker installation steps.

3. If you still have problems with CI Gate after these steps, contact [email protected].

   In the report, include as much information as possible to help reproduce the problem. For example:

   • The Docker engine and Server version: docker info
   • The host fingerprint: uname -a
   • The value of docker inspect fluidattacks/forces:latest
   • The organization, group, and repository name where you run the agent.

Footnotes

1. Grace period policy
2. Minimum breaking severity policy