CI Gate executions

Last updated: Oct 27, 2026

---

Fluid Attacks' CI Gate supports the DevSecOps methodology in your projects. This tool is a security gate in your continuous integration and continuous deployment (CI/CD) environments. It stops vulnerable code before it gets to production.

CI Gate monitors your software versions. If it detects vulnerabilities that are not remediated or accepted, it automatically breaks the build. Thus, your team must remediate them, and your security standards stay high.

You can configure the rules to break the build at the organization and group levels, in the Policies section of the Fluid Attacks platform. You can see the details of each CI Gate execution in the DevSecOps section. This page describes this section.

DevSecOps table

The DevSecOps section of your group has a table with the full execution history of CI Gate in your pipeline. A banner shows the policies that the executions apply at this time. To see more details about an execution, click its date.

These are short descriptions of the table columns:

• Date: The date and time that CI Gate ran in your pipeline
• Status: Shows if the execution found vulnerabilities:
  • Vulnerable: CI Gate identified one or more vulnerabilities that are not fixed
  • Secure: CI Gate found no unfixed vulnerabilities
• Within policy: The total number of detected vulnerabilities that obey your policies
• Unmanaged vulnerabilities: The total number of vulnerabilities detected that break the build. A vulnerability is unmanaged when all these conditions are true at the same time:
  • It is open (not fixed or accepted as a risk).
  • Its severity score is equal to or more than the configured severity threshold.
  • The number of days since its report is equal to or more than the configured grace period.
  • Its age is less than the configured days to technical debt limit (if there is a limit).
• Strictness: Shows if CI Gate can break the build in that execution:
  • Strict: CI Gate breaks the build if it detects unmanaged vulnerabilities. This prevents deployment to production
  • Tolerant: CI Gate only shows warnings for unfixed vulnerabilities and the build can go to production
• Type: The security testing technique(s) that detected the vulnerabilities. These are the possible values:
  • STATIC: Static application security testing (SAST)
  • DYNAMIC: Dynamic application security testing (DAST)
  • ALL: SAST found one or more vulnerabilities and DAST found one or more vulnerabilities
• Git repository: The nickname of the Git repository with the changes that CI Gate scanned
• Identifier: The first eight characters of the unique alphanumeric identifier of the CI Gate run

Filter the DevSecOps table

Click the filters button to see the options to limit the information in the table.

Search the DevSecOps table

Type in the search bar of the table to see only the rows that contain the same text as your search term.

Download a report of the CI Gate executions

You can download the information of the DevSecOps table as a comma-separated values (CSV) file. Click the Generate a report button. The report is available in Downloads after a short time.

View CI Gate execution details

In the DevSecOps section, to see more details about a CI Gate execution, click its date.

A pop-up window opens with many details about that run. The window has two tabs: Summary and Execution log.

Summary

Summary first shows the data that is also in the table. It also shows the value of three policies that the execution applied. The second tab also shows all this data.

These are short definitions of these policies:

• Severity threshold: The minimum CVSS score that an unfixed vulnerability must have to break the build
• Grace period: The number of days during which newly discovered vulnerabilities do not break the build
• Days to technical debt: The number of days until vulnerabilities become technical debt, which does not break the build

Below these details, a table shows information about all the vulnerabilities that CI Gate identified in its execution.

The table has these columns:

• Exploit Maturity: The probability that the vulnerability causes a successful attack, as the CVSS v4.0 measures it
• Status: Shows that the vulnerability is Open (is present) in the lines of code, inputs or ports
• Type: The security testing technique(s) that detected the vulnerabilities, as defined above
• Specific: The exact lines of code, inputs (for example, password fields) or ports where Fluid Attacks found the vulnerability
• Where: The file path where Fluid Attacks found this vulnerability

You can apply filters to limit the information that the table shows. With filters, you can analyze only the data that you select.

You can also type a search term in the search box. The table then shows only the rows whose content matches your search.

Execution log

The content of the CI Gate execution log is not always easy to read. This section gives important information to help you get the most from the log.

These are the primary elements of the log:

• Arguments: The content of the log depends on the parameters or arguments of the agent execution. As an example, the screenshots below show an execution with the argument --strict.

  

• Report body: The primary part of the report is the detailed information about the detected vulnerabilities. This is a short explanation of the content shown for each vulnerability:

  • title: The category that best describes the vulnerability, following Fluid Attacks' own classification
  • url: The vulnerability URL on the platform
  • state: The condition of the group for the weakness. It is vulnerable if the weakness is present
  • exploit: From the CVSS, the probability of exploitation, from the current exploitation techniques, the availability of exploit code, and real exploitation "in the wild"
  • severity: The severity score of the weakness (from 0.1 to 10.0), with the CVSS
  • vulnerable: The total number of unfixed vulnerabilities
  • locations: The identified vulnerabilities, with this information:
    • type: Shows if Fluid Attacks found the vulnerability in the source code (static) or with attacks on the running application (dynamic)
    • technique: The security testing technique that detected the vulnerability
    • where: The file path where Fluid Attacks found this vulnerability
    • specific: The lines of code, inputs (for example, password fields) or ports where Fluid Attacks found the vulnerability
    • state: Shows that the lines of code, inputs or ports are vulnerable (the vulnerability is present)
    • severity: The severity score of this vulnerability, with the CVSS
    • compliance: Shows if the vulnerability breaks the build
  

• Summary: The report ends with a summary. The summary shows these items:

  • The total number of unfixed vulnerabilities
  • The CI Gate execution time
  • The policies that CI Gate verified
  • The name and age of the vulnerability type
  • If the build broke or passed