### Release notes Building on the previous [iteration](https://gitlab.com/groups/gitlab-org/-/epics/10816), we are introducing a new option within the policy editor allowing users to toggle security policies to fail open or fail closed. This enhancement extends the YAML support to allow for simpler configuration within the editor view. When a merge request approval policy is configured to fail open, MRs will only be blocked if a policy rule is violated for projects with the security analyzer properly configured. If an analyzer is not enabled for a project or does not successfully produce results for the policy to evaluate, the policy will no longer consider this a violation for the given rule and analyzer. This approach allows for progressive rollout of policies as teams work to ensure proper scan execution and enforcement. ### Problem to solve As a security engineer or compliance manager, I want to slowly roll out security policies and increase the level of enforcement once I'm confident in it's accuracy, so that our policies are not disruptive for current development workflows. I'd like to be able to modify my security policies to fail open or fail closed, which modifies the permissiveness of the policies. When failing open: - If a scan job (that is under enforcement) does not run or produce an artifact, do not block the MR / require approval. - In this case, development teams become responsible for proper configuration of their scanners and if some projects do not require a particular scan, they are not required to run the scanner for that project as they would be when failing closed. When failing closed: - If a scan job (that is under enforcement) does not produce an artifact, assume the project is non-compliant, and block the MR unless it's been approved by an eligible reviewer. - In this case, the more restrictive policy would require development teams to ensure scanners properly run on their projects, or it will lead to more approval requirements. Security policy creators may also modify policies to exclude projects from enforcement that are out of scope for enforcement. ### Intended users Policy editors (AppSec engineers, DevSecOps engineers, Compliance Managers) - these users are responsible for creating policies enforced globally and the impact to potentially hundreds or thousands of projects and all developers working there is stress inducing to say the least. This capability is a tool to offer flexibility where possible. ### User experience goal 1. Users may modify each policy to be more or less restrictive by choosing "Fail open" or "Fail closed" in the policy editor UI via a radio button. What checks are modified by this logic could be flexible as we add capabilities. This iteration would extend the support in YAML into the UI. 2. The checkbox option will be available **per policy**, so one policy may be defined for SAST that is `fail closed`, while users may want to first test a separate policy for Dependency Scanning where they'd prefer to `fail open`. If a policy has multiple rules enabled and toggle it to `fail open`, this would apply to all rules in the policy. 3. In this iteration, we'll extend the cases supported when a user selects `fail open`: 1. For scanners that require builds, when a project does not have a build pipeline. 2. Required number of approvals became higher than available, valid approvers. 3. When a security policy fails for an unspecified reason. ### Design | Settings | Settings with tooltip | Policy Drawer | |----------|-----------------------| - | |  |  |  | ### Further details ### Permissions and Security ### Documentation ### Availability & Testing **Test Cases** 1. A policy blocks MRs for secret detection and dependency scanning if the findings are critical or high. But, for this policy, "fail open" is selected. An MR is opened with a number of commits. Secret detection runs and there are no critical or high severity findings. Dependency scanning is not being enforced on the project and does not run, no artifacts are produced, or the job fails and no artifacts are produced. The MR is not blocked, no approvals are required. 2. A policy blocks MRs for secret detection and dependency scanning if the findings are critical or high. But, for this policy, "fail open" is selected. An MR is opened with a number of commits. Secret detection runs and there is a high severity finding. Dependency scanning is not being enforced on the project and does not run, no artifacts are produced, or the job fails and no artifacts are produced. The MR is blocked and requires approval because there was a finding detected for secret detection. 3. A policy blocks MRs if there are any findings at all for any GitLab scanner (all scanners selected) but set to "fail open". In a project containing no scanners, no MRs would ever be blocked. But if they add SAST into their `.gitlab-ci.yml` and there are any findings, the MR would require approval. 4. A policy blocks MRs if there are any findings at all for any GitLab scanner (all scanners selected) but set to **"fail closed".** In a project containing no scanners, _all MRs would be blocked_ until all scanners are properly configured per the policy rules. ### Available Tier ### Feature Usage Metrics ### What does success look like, and how can we measure that? ### What is the type of buyer? ### Is this a cross-stage feature? ### What is the competitive advantage or differentiation for this feature? ### Interested customers - https://gitlab.my.salesforce.com/0016100001C55u1 - https://gitlab.my.salesforce.com/0016100001I58rd - https://gitlab.my.salesforce.com/0016100000sPtxl ### Links / references <!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION --> *This page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.* <!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION -->