### Release notes Compliance operates on a sliding scale for many organizations as they strike a balance between meeting requirements and ensuring developer velocity is not impacted. Merge request approval policies help to operationalize security and compliance in the heart of the DevSecOps workflow - the merge request. We're introducing a new `fail open` option that can be enabled per policy to offer flexibility to teams rolling out controls in their organization, to ease the transition and modulate enforcement. When a merge request approval policy is configured to fail open, MRs will now 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 ### Iteration 1 As a first phase for this Epic we would like to start with simplified MVC to already offer this functionality to interested customers. The idea for MVC is quite simple: * we add toggle to YAML mode only, * with the toggle enabled (potentially something like `fallback_behavior: { fail: closed }`) we will behave as we are right now, * with the toggle disabled (potentially something like `fallback_behavior: { fail: open }`) we will not require approvals when policy or project is misconfigured, * we use `fallback_behavior: { fail: open }` format to allow for further extensions in the future, potentially we could have a list of scenarios where we want to have different scenarios or some exceptions, like we had for many previous features * the fail open option can be defined _per policy_. For this iteration: * If users choose "fail open", if required scanners defined in the condition did not run or produce any artifacts, we would ignore findings for the given scanner/rule. * If we fail open, we would only block MRs if we detect any violations that match the scan result policy rules. Users will be responsible for handling scan execution separately - via scan execution policies, compliance pipelines, or even by working with development teams individually. We will only be concerned with when scan results that are detected "fail" or violate the policy rules. * If two conflicting policies are enforced on a project, fail closed behavior will take precedence. E.g. two policies blocking criticals/highs for dependency scanning, one is fail open, one is fail closed. We would honor the fail closed behavior for the policy. The feature should be enabled first through a feature flag and we will continue with Iteration 2 and will wait to receive customer feedback/validation before removing the flag. ### Iteration 2 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 | |----------|-----------------------| |  |  | ### 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 -->