View details of the security of your builds

Fluid Attacks’ CI Gate supports the DevSecOps methodology  applied in your projects. This tool acts as a security gate within your continuous integration and continuous deployment (CI/CD) environments, preventing vulnerable code from reaching production. That is, CI Gate monitors your software versions and, if it detects vulnerabilities that have not been remediated nor accepted , automatically breaks the build  to enforce their remediation, upholding your security standards. The rules to break the build  can be configured at the organization and group levels in the platform’s Policies section.

You can see details of each of CI Gate’s executions in the DevSecOps section. This page guides you through it.

DevSecOps table

Your group’s DevSecOps section features a comprehensive table that shows the execution history of CI Gate within your pipeline. A banner reminds you of your relevant policies currently applied in executions. Gain deeper insights into each execution by simply clicking on the corresponding date.

The following are brief descriptions of the table columns:

• Date: The date and time the CI Gate was executed in your pipeline
• Status: Whether vulnerabilities were found in the execution:
• Vulnerable: Indicates that CI Gate identified at least one vulnerability that has not been fixed
• Secure: Indicates that no unfixed vulnerabilities were found
• **Accepted vulnerabilities:** The total number of vulnerabilities detected that are tolerated by your policies 
• Unmanaged vulnerabilities: The total number of vulnerabilities detected that break the build
• Strictness: Whether breaking the build was enabled:
• Strict: CI Gate is configured to break the build if unmanaged vulnerabilities are detected, preventing deployment into production
• Tolerant: CI Gate only issues warnings for unfixed vulnerabilities, allowing deployment into production
• Type: The security testing technique(s) with which the vulnerabilities were detected, where the following values are offered:
• STATIC: Static application security testing (SAST)
• DYNAMIC: Dynamic application security testing (DAST)
• ALL: At least one vulnerability was found through SAST and at least one through DAST
• Git repository: The nickname of the Git repository  whose changes were scanned by CI Gate
• Identifier: The first eight characters of the CI Gate run’s unique alphanumerical identifier

Filter the DevSecOps table

By clicking on the filters button (

), you access several options to limit the information shown in the table.

Choose filters in DevSecOps

Apply filter

Search the DevSecOps table

Type on the search bar for the table to show you only the rows that contain your exact search term.

Download a report of the CI Gate executions

The platform allows you to download the information contained by the DevSecOps table in a comma-separated values (CSV) file. You just need to click on the Generate a report button. The report is made available in Downloads  after a few minutes.

Generate report button

Notification

View CI Gate execution details

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

A pop-up window appears, which provides a wealth of details about that specific run. You are presented with two tabs: Summary  and Execution log .

Summary

The first data in Summary is that already present in the table  plus the indication of the value of three policies applied in that execution. All this data is again presented in the second tab.

Here are brief definitions of these policies:

1. Severity threshold : The minimum CVSS score required for an unfixed vulnerability to break the build
2. Grace period: The number of days during which newly discovered vulnerabilities do not break the build
3. Days to technical debt : The number of days until vulnerabilities are considered technical debt and do not break the build

Below these details is a table with information about all vulnerabilities identified by CI Gate in its execution.

The table has the following columns:

1. Exploit Maturity: The degree to which the vulnerability might lead to a successful attack, as measured by the CVSS  (Common Vulnerability Scoring System) v4.0
2. Status: Indicates that the vulnerability is Open (is present) in the lines of code, inputs or ports
3. Type: The security testing technique(s) with which the vulnerabilities were detected, as defined above 
4. Specific: The exact lines of code, inputs (e.g., password fields) or ports where the vulnerability was found
5. Where: The file path where this vulnerability was found

You can apply filters to narrow down the information displayed in the table, facilitating targeted analysis.

Moreover, you can simply type what you are looking for in the search box, so that only the rows whose content matches your search are shown.

Execution log

Understanding CI Gate’s execution log content can sometimes be challenging. This page section offers valuable tips and key information to help you interpret it effectively and extract maximum value from the data. The following are main elements to take into account:

1. Arguments : The log’s content depends on the parameters or arguments used during agent execution. For illustration purposes, the screenshots below show an example of an execution with the argument --strict.

1. Report body: The core of the report is the detailed information about the detected vulnerabilities. Here is a brief explanation of the content characteristics shown for each of the latter:
2. title: The category that best describes the vulnerability following Fluid Attacks’ own classification 
3. url: The vulnerability URL  on the platform
4. state: Indicates the condition of the group regarding the type of vulnerability, where it is Vulnerable if the weakness is present
5. exploit: From the CVSS , probability of exploitation given the current state of techniques for it, exploit code availability, and actual exploitation “in the wild”
6. severity: The type of vulnerability’s severity score (from 0.1 to 10.0) using the CVSS
7. vulnerable: The total number of unfixed vulnerabilities
8. locations: The vulnerabilities that were identified, for which the following is informed:
9. type: Whether it is a vulnerability found by looking at the source code (static) or attacking the running application (dynamic)
10. technique: The security testing technique with which the vulnerability was detected
11. where: The file path where this vulnerability was found
12. specific: The indication of the exact lines of code, inputs (e.g., password fields) or ports where the vulnerability was found
13. state: Indicates that the lines of code, inputs or ports are Vulnerable (the vulnerability is present)
14. severity: This specific vulnerability’s severity score using the CVSS
15. compliance: Whether the vulnerability breaks the build

1. Summary: The report concludes with a summary highlighting the total number of unfixed vulnerabilities, the CI Gate execution time, the policies  verified, the vulnerability type’s name and age, and the information of whether the build was broken or passed.