<!--- Please read this! Before opening a new issue, make sure to search for keywords in the issues filtered by the "regression" or "type::bug" label: - https://gitlab.com/gitlab-org/gitlab/issues?label_name%5B%5D=regression - https://gitlab.com/gitlab-org/gitlab/issues?label_name%5B%5D=type::bug and verify the issue you're about to submit isn't a duplicate. ---> ### Summary In a Scan execution policy, it is possible to [prevent users from using [skip_ci] to bypass security scans](https://docs.gitlab.com/user/application_security/policies/scan_execution_policies/#skip_ci-type). It is also possible to [setup scheduled scans](https://docs.gitlab.com/user/application_security/policies/scan_execution_policies/#schedule-rule-type) that will be run daily or weekly. However when combining these, the skip_ci setting of false is not applied. ### Steps to reproduce 1. Setup a Scan Execution Policy similar to below: <details> <summary>Policy yaml</summary> ``` scan_execution_policy: - name: Daily Scan description: '' enabled: true policy_scope: projects: excluding: [] skip_ci: allowed: false rules: - type: schedule cadence: 0 0 * * * branch_type: protected timezone: Etc/UTC actions: - scan: secret_detection ``` </details> 2, In a test project create a commit with a commit message that ends with `[skip_ci]`. 3. Apply the daily scan security policy to the test project 4. check-in on it the next day  Notice that non of the scans ran for any of the branches. The behaviour works as expected if the SEP is set to `triggered` instead of `scheduled`. ### Example Project - [Skip_CI example project](https://gitlab.com/cmarais_ultimate_group/ticket_work/616282_skip_ci_sep/business/test_project) ### What is the current *bug* behavior? Users are able to bypass the security scans using [skip_ci] if the security scans are scheduled. This is not true if the security scans are `triggered`. ### What is the expected *correct* behavior? The [skip_ci] setting should apply to scheduled scans as it works for triggered scans. ### Relevant logs and/or screenshots Policy set to `triggered`  Policy set to 'scheduled'  ### Output of checks <!-- If you are reporting a bug on GitLab.com, uncomment below --> <!-- This bug happens on GitLab.com --> <!-- and uncomment below if you have /label privileges --> <!-- or follow up with an issue comment of `@gitlab-bot label ~"reproduced on GitLab.com"` if you do not --> ### Possible fixes <!-- If you can, link to the line of code that might be responsible for the problem. --> <!-- If you don't have /label privileges, follow up with an issue comment of `@gitlab-bot label ~"type::bug"` -->