Make Security Approval Policies more Robust (#9102) · Epics · GitLab.org

Make Security Approval Policies more Robust

### Current scenario So far approval rules are synced only based on the head pipeline (and base pipeline when comparison is involved). Recently this feature has been enhanced to no only affect new merge requests but also all [existing open merge requests](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/92010). Therefore whenever policies are changed, new rules are generated for each of the related open MRs which in their turn require a rerun of the head pipeline in order to sync those new rules against the security report of the head pipeline. ### Limitations The current approach considers only the head pipeline which seems to be limited when trying to cover the following use cases: 1. Approvals are not required when security jobs are removed from the pipeline. 1. Approvals are required when security jobs are included in the pipeline and their conditions are met. 1. Although detached pipelines do not contain security jobs, [it is not desirable](https://gitlab.com/gitlab-org/gitlab/-/issues/368441) that approvals are not required. 1. Whenever policy changes and new approval rules are created, approval rules [are expected](https://gitlab.slack.com/archives/CU9V380HW/p1661370389622819) to be [synced against](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/92947) the pipeline even if they are detached. 1. When security policies consider **only** whether or not vulnerabilities are pre-existing on the default branch (for example, in a `detected` or `confirmed` state) then the policy engine still requires the pipeline to fully complete **and** it still requires security scans to run. Ideally the engine should be intelligent enough to not assume that all vulnerabilities have been resolved if a vulnerability report was never generated (the scans did not run) and ideally the approvals would not be required from the beginning without having to wait for the entire pipeline to complete. ## Proposal ### Permissions and Security ### Documentation ### Availability & Testing ### What does success look like, and how can we measure that? ### What is the type of buyer? ~"GitLab Ultimate" ### Is this a cross-stage feature? ### Links / references *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.*  *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.*

epic