# Release notes Scan execution policy templates help you quickstart the process of creating scan execution policies based on common use cases. Choose from three templates: * Merge request security * Scheduled scanning * Merge release security Once your use case is selected, you can choose which GitLab security scans to enable with the template and get immediately up and running! As your use of scan execution policies grow and as more advanced use cases are identified, you can swap to the custom configuration to extend the policy further with more specific branch patterns, pipeline sources, and more. # Problem to solve 1. Improve flexibility of scan execution conditions, allowing users to optimize pipeline execution time. 2. Ensure the trigger conditions are intuitive. # Customer feedback #### 1. Scan execution policies trigger conditions do not work smoothly with MR approval policies Current recommendations require enforcement of jobs to run on all branches<span dir=""> </span>by using `*` or `all branches` in the policy configuration. This ensures that any branch that _may_ end up being merged into `main` have necessary scans running (that MR approval policies depend on). The artifact must then be produced for _both_ branches and consumed to perform evaluation of the two branches. Ideally, configuration of a scan execution policy should by default ensure that the criteria are met for MR approval policies, minimizing the effort on security, compliance, and development teams to ensure proper configuration. #### **2. Desire to reduce infrastructure cost by filtering the cases where pipelines are required to run** > I block Scan Execution Policy / Compliance Framework Pipeline from running SAST and other selected scanners on every commit / change made by the Developer > > **Reason**: Since it would translate to more Runner time on each change translating to more Infrastructure cost for Customer. > > **Challenge if we implement it:** Developer won't receive a Continuous Feedback and will eventually have to fix the issues later once they are ready to Merge. > > What Customer is proposing instead is to allow [Merge Request based selection](https://docs.gitlab.com/ee/ci/variables/predefined_variables.html#predefined-variables-for-merge-request-pipelines) criteria along with existing branch selection Conditions in Scan Execution Policy. # Proposal #### ## Old proposals <details> <summary> :bulb: 1. Add new trigger conditions </summary> 1. Add new trigger conditions for `branches targeting the default branch` and `branches targeting the default branch` to policy editor. 2. Add YAML option for `target_default` and `target_protected`. <table> <tr> <th>Policy editor</th> <th>YAML</th> </tr> <tr> <td>  </td> <td> ```yaml ## "branches targeting the default branch" option in editor - type: pipeline branch_type: target_default ## "branches targeting any protected branch" option in editor - type: pipeline branch_type: target_protected ``` </td> </tr> </table> </details> #### Add condition types, add new SEP trigger conditions for injecting scan execution #### Add condition types, add new SEP trigger conditions for injecting scan execution | Choose condition type | Branches targeting the default branch | |-----------------------|---------------------------------------| |  |  | ### Additional details - Any proposal 1. Users could avoid choosing `*` to enforce the jobs to run on all branches (some of which may not target the default branch). 2. Continue to support the ability to alternatively run on all pipelines on a specific branch, all protected branches, or specific protected branches. This is necessary for instance to simply enforce scans, such as DS, on all pipelines on the default branch. 3. The work in the Pipeline Execution Policy will allow for the most flexibility currently, as you can define very custom CI logic. We can work to understand which patterns are used here most commonly and provide insight to support them more natively in the policy editor to make it easier to create policies OOTB without using YAML. 4. Note: If we allow configuration of rules around which pipeline sources to enforce within, this could also now conflict with the choice between latest and default security templates. <!--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--> <!--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-->