### Description This epic captures planned requirements that are anticipated for Security Policies to achieve `Viable` maturity. 1. Support to create custom CI jobs/scripts that can be enforced against my development team projects consistently and reliably. 2. OOTB and custom CI jobs should be secure and should confidently enforce compliance. 3. Scan result (merge request approval) policies allow customers to flexibly enforce compliance controls and simplify AppSec and Compliance Manager workflows. 4. Scan result (merge request approval) policies should align with users' expectations and address the majority of use cases -- ensuring results are accurate, easy to understand, and issues can be easily identified/addressed. 5. Policies should be easily managed across an organization and its many business units granularly and in a scalable fashion. Creating policies and opting projects into enforcement should be smooth, clear, and it should be easy to get a sense of how policies are enforced across an organization. 6. Policies should be flexible based on common use cases, so compliance can be rigidly enforced where necessary or so policies can be light touch in other cases where appropriate (such as during testing/rollout of policies). 7. It should be possible to implement key security and compliance controls, with extensibility to support more use cases in the future. Key controls include: scan enforcement, vulnerability management approvals, and compliance approvals. Key use cases include: 1. Merge Request Approvals 2. Repository Settings Enforcement 3. Merge Request Settings Enforcement 4. Push Settings Enforcement 8. Managing security policies and their enforcement (including through compliance framework management) should be controllable, such as through custom permissions, so organizations can limit permissions/access for linking or scoping projects into enforcement. 9. There should be mechanisms that support easily testing and rolling out security policies granularly and scalably across projects in an organization. For example, this may require one or more options below: 1. Iterating on changes to a policy and the ability to test new behaviors before enabling. 2. Adjusting how rigidly policies are enforced. 3. Testing potential impact (MRs/projects) prior to enabling a policy. 4. Enabling policies in audit mode and observing behavior without impact. 10. The limitations of how many policies of a given policy type, and how many rules within a policy are supported, should be extended to a reasonable amount (beyond 5 per type). Errors/warnings/limits around the number of policies/rules created should be clear and visible to users as they create policies and impossible to exceed the limits. 11. To meet GitLab’s threshold for `Viable`, GitLab must be dogfooding and able to show "significant use" of the features by GitLab the company. Use cases include: 1. License Approval Policies for License Compliance by our Legal team - https://gitlab.com/gitlab-org/gitlab/-/issues/400221 2. Scan Result Policies for engaging AppSec and Development teams in DevSecOps workflows 3. Support for ITGC Compliance requirements - https://gitlab.com/groups/gitlab-com/Finance-Division/itgc-compliance-gitlab.com/-/epics/15 4. Scan Execution Policies for enforcing necessary scanners or compliance jobs/scripts to run 12. Once the above are addressed, to mature the feature to `Viable`, we must complete a Category Maturity scorecard with at least a 3.14 rating for the JTBD. See [Maturity documentation](https://about.gitlab.com/direction/maturity/). _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 --> *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 -->