Security gates

Last updated: Oct 27, 2026

---

Manage your organization's security gates

On the Fluid Attacks platform, you can define the policies that control how your organization accepts vulnerabilities, manages user access, and prioritizes remediation work.

To see these policies, open the Policies section in the collapsible menu.

Policies has three sections. In the first section, you can define policies about the temporary acceptance of vulnerabilities, breaking the build, and platform usage. To learn about the other two sections, read "Vulnerability acceptance" and "Vulnerability prioritization attributes".

In Organization, you find the security gates configuration that your organization applies by default to each new group. To change it, click Edit. A pop-up window shows the eight available policies. This page describes them in the subsequent sections. To save your changes, click Confirm.

Temporary acceptance

These four thresholds apply only to the temporary acceptance of each vulnerability in Vulnerabilities. They do not limit the organization-level policies for weakness types that your team submits and approves on the Vulnerability acceptance page. On that page, a Manager can approve a temporary or permanent acceptance policy for a full weakness type, with no limits from these settings. In the interface and on the Understand roles page, these fields also have the names Days maximum, Acceptances maximum, and Severity range.

Maximum number of calendar days a finding can be temporarily accepted

Shows the number of days that your organization can accept a vulnerability temporarily. The maximum value is 999 calendar days.

This policy affects the executions of CI Gate, because temporarily accepted vulnerabilities do not break the build. Set this value carefully. If vulnerabilities stay unremediated for long periods, they cause risks to your applications.

Maximum number of times a finding can be accepted

Shows the maximum number of times that your organization can accept a vulnerability temporarily. When a vulnerability gets to this limit, your organization cannot accept it temporarily again. This also applies if the vulnerability gets other treatments or if it is present again after your team remediated it.

Minimum CVSS score allowed for temporary acceptance

Shows the minimum Common Vulnerability Scoring System (CVSS 4.0) score (0.0 to 10.0) that a vulnerability must have to be temporarily accepted.

Maximum CVSS score allowed for temporary acceptance

Shows the maximum CVSS 4.0 score that a vulnerability can have to be temporarily accepted.

Permanent acceptance does not have day, count, or severity limits like these. Fluid Attacks did not add them, because an Organization Manager or Group Manager must approve a permanent acceptance before it has effect.

DevSecOps

Grace period where newly reported vulnerabilities will not break the build

Shows the number of days during which newly discovered vulnerabilities do not make CI Gate break the build. Set this value carefully, because unremediated vulnerabilities can cause risks to your applications.

Number of days until vulnerabilities are considered technical debt and do not break the build

Shows the period (in days) before a vulnerability becomes "technical debt", which does not break the build. During that number of days, an open vulnerability continues to break the build. This applies when its severity score is equal to or more than the threshold and the grace period is over. After this period, an open vulnerability does not break the build.

Minimum CVSS score of an open vulnerability to break the build

Shows the minimum severity score that an open vulnerability must have to break the build. Below this threshold, an open vulnerability does not break the build at any time. For example, with a threshold of 7.0, an open vulnerability with a score of 6.9 does not break the build, before or after the grace period. But a vulnerability with a score of 7.5 breaks the build if it stays open for more than the grace period. This applies only during the configured days to technical debt limit.

Number of days after which a member is removed due to inactivity

Shows the inactivity period (in days) before the platform automatically removes a member from the organization. The default value is 90 days. The removed member loses all access and must request a new invitation to join again. Only an Organization Manager can send this invitation.

Manage your security gates at a group level

Groups get the security gate policies of their organization. But, you can customize these policies at the group level. In Groups in Security gates, you can see the current configuration of each group that you have access to. To change this configuration, click Edit.

In the pop-up window, define the policies of your group. The previous sections of this page describe each policy. When you finish, click the Confirm button.

When you confirm, you get an email notification announcing the policy change.

On the platform, you can also change the security gates configuration of one or more groups to the configuration of the organization. To do this, select the group(s). Then, click Reset to organization policies.