### Problem to solve Companies need to enforce a compliant path to production. ### Target audience <!--- For whom are we doing this? Include either a persona from https://design.gitlab.com/#/getting-started/personas or define a specific company role. e.a. "Release Manager" or "Security Analyst" --> Release Managers and Security compliance analysts ### Further details <!--- Include use cases, benefits, and/or goals (contributes to our vision?) --> Enterprises have various compliance needs, and some compliance can be handled through proper auditing and a standardized, prescriptive deployment pipeline, but some compliance targets *need* to enforce certain aspects of the path to production. e.g. that certain security tests have run and passed, that qualified people trigger deployment to production, that build images are created in a certain fashion, etc. ### Proposal Lock down each of: 1. CI/CD code 1. CI/CD code execution 1. CI/CD data 1. Build execution e.g. Enforce code+runner+data+binauthz 1. Lock `.gitlab-ci.yml` so only admins can modify it. There are actually a number of ways to do this; these are related and you can imagine more: - https://gitlab.com/gitlab-org/gitlab-ee/issues/8429 - https://gitlab.com/gitlab-org/gitlab-ee/issues/9187 - https://gitlab.com/gitlab-org/gitlab-ee/issues/9203 2. Lock runners so code+data can't be misused. There are probably also more ways to secure the runners here as well. - https://gitlab.com/gitlab-org/gitlab-ce/issues/53906 - https://gitlab.com/gitlab-org/gitlab-runner/issues/3699 - https://gitlab.com/gitlab-org/gitlab-runner/issues/3188 - https://gitlab.com/gitlab-org/gitlab-runner/issues/3745 3. Lock attestation signature token so only available to locked code, and use it for signing during CI pipeline or release creation (https://gitlab.com/gitlab-org/gitlab-ee/issues/7268). Optionally, enforce various kinds of attestations (security test ran, compliance checks, etc., possibly using https://gitlab.com/gitlab-org/gitlab-ce/issues/56030) 5. Lock cluster so only compliant builds are executed (e.g. `binauthz`) (https://gitlab.com/gitlab-org/gitlab-ee/issues/7840) Variation: 1. Encourage `include`ing a local YML so devs can customize part of the pipeline, but compliant YML is parsed after, so overrides. 1. Tie project or group variables to certain named jobs, which you ensure are unmodified by virtue of above. e.g. environment-specific variables are insufficient if someone can create a new job that also deploys to `production` which then steals attestation signature token and spoofs a payload. These should be summarized in a blog post (https://gitlab.com/gitlab-com/www-gitlab-com/issues/3678) detailing how to secure your pipelines and delivery. ### What does success look like, and how can we measure that? Enterprise companies adopt GitLab for compliant deployment to production. ### Links / references ### Customers Interested https://gitlab.my.salesforce.com/001610000111p4B