I've adapted the original content to be more closely aligned with our recent customer conversations and ~"group::compliance" vision discussions. A new [discovery issue](https://gitlab.com/gitlab-org/gitlab/issues/38026) has been created and the original content preserved in this issue, commented out. This epic's description now aligns with the parent [Compliance Management Strategy](https://gitlab.com/groups/gitlab-org/-/epics/720) and sets a better foundation for building upon project-level compliance features. ### Problem to Solve Organizations are bound by compliance Frameworks that govern their industry. Companies have policies and procedures to address the various requirements of those frameworks. Within GitLab, a project is where most of a company's operational activities occur and these activities must be compliant. Currently, organizations cannot sufficiently transfer their internal requirements into GitLab. This creates non-compliant GitLab environments and requires customers to build expensive and time-consuming in-house solutions to manage their compliance programs. ### What's Next & Why * Project Tagging for Compliance * Customers manage projects based on their compliance requirements. The specific settings and configurations that are required for compliance only apply to a certain number of projects. GitLab needs to provide a mechanism for customers to delineate regulated vs. non-regulated projects to provide better flexibility for managing mixed environments. * Selective Enforcement * Once projects are clearly demarcated as compliant with a specific compliance framework, customers could apply the settings in https://gitlab.com/gitlab-org/gitlab/issues/39060 only to compliance-tagged projects, such as "SOX compliant" projects, leaving all other projects unrestricted. * Pre-defined, "sensible" defaults * With Project Tagging to identify regulated projects, we can derive the appropriate settings and configurations to provide "out of the box" defaults for new projects. This would help customers spin up new projects with all of the necessary settings and restrictions in place for specific compliance frameworks, which reduces the administrative overhead of compliance management within GitLab. <!-- ### Problem to solve Customers need to ensure each of their environments adhere to a compliance level. The broad scope of GitLab means we can do things that other tools can't. Compliance is a large and expensive pain point for a lot of enterprises that GitLab can help address. Examples: * Setting limits on things that are found, e.g. X failures is okay; X+1 is a blocker * Some environments have deployment windows in which they cannot see deploys * Every X days a pen test is run on the environment or a security review is triggered * Blocking releases that make things work ## Current situation This is currently hand-rolled via scripts outside of GitLab crosslinking with one or multiple external systems. The external systems keeps track of every compliance level applicable to a customer's organization. Each app/project then gets a configuration file which specifies which compliance level is needed for each app/project. This causes a lot of inflexibility where builds break and review apps break that should work. It is also a huge burden on the customer. ### Intended users * [Delaney (Development Team Lead)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#delaney-development-team-lead) * [Sasha (Software Developer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sasha-software-developer) * [Sam (Security Analyst)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sam-security-analyst) * All management stakeholders who adhere to any auditing process. For example in a finance institution (Security, Quality, Development department heads) ### Further details Sid's unfiltered recording on Compliance https://www.youtube.com/watch?v=rFuTUXiCOQc Raw notes from Sid: >>> Environments have compliance levels like sox2, gdpr, HIPAA, financials, etc. Compliance levels have policies, like running Sast, or not having more than a certain new severity, everything has a peer review, every code item linked to an issue or jira ticket, no deploys during the holidays, all requirements are confirmed with tests, etc. Policies have overrides, like from anyone, a maintainer, a security team, or an environment owner, etc. What not to do (add to principles: 1. Don't allow people to constrain or affect all runners, jobs, CI configuration, or merge request. You never want to break a build or a review application. 1. Never block improvements that don’t make the situation worse. These things might be solving an important need. 1. Don’t store it both in code and the UX since that is very hard. 1. Have sensible defaults for compliance levels and policies so people can quickly become more compliant by marking environments with a compliance level. Reporting functions: 1. Allow people to see all environments currently out of compliance without an override (dependency became vulnerable, etc.) 1. All environments with an override. 1. For an environment proof what compliance policies where met >>> @jeremy's response: https://www.youtube.com/watch?v=Th9zgS7JEss&feature=youtu.be ### Proposal Implement `Compliance Levels` per `Project`. This oversight mechanism should not be mapped to a CI pipeline or a Merge Request but rather to the `Project`. The requirements for each `Project` drives the level of compliance and the compliance list it needs. For example: * Financial transaction application requires a strict set of compliance * Company marketing website requires a much lesser set of compliance As such the project which the pipeline deploys to shall dictate the list of compliance. Compliance Framework: 1. Maintaining standards over code 1. Maintaining standards over the processes that created it Make it _really_ easy to find the exceptions to policies, if you have policies/whatever your policies are. A dashboard allows folks to see the project, but also roll up to see it at higher levels. This is esp importance for Executives who want to be sure that every project is meeting its compliance rules. This framework at the project level makes more sense since people think about the world at the project-level. This would prevent a merge if the policies aren’t met. It would still allow review apps. The rejected ideas are for blocking on the level of a: - build (not compatible with features like review apps, and DAST) - Protected branch (more complex than every merge, hard to articulate a use case) - Push (should be able to make proposals, not compatible with other features, need time to test) - Environment (more complex than per project) So projects have frameworks, and framework have policies, policies have requirements and overrides. A merge request in an a project with policies needs to meet them before allowing a merge. For every project, merge, deploy, and environment you can see the framework, policies, requirements, and overrides. You can get an overview of things that are out of compliance because: - the framework got added later - The policy was changed - It drifted out of compliance (vulnerability discovered in a dependency) - It was overridden (allow people to hide this) #### Components * `Projects` - A list of projects which allows a list of compliance to be configured. * `Certification` - The whole list of compliance frameworks and levels used by an organization. Each level maps to the compliance requirements. We don’t want to call it requirement since we already have requirement management. * `Policies` - This is an actionable step (a manual step, running a given gitlab feature, forking a sub workflow) For example: running SAST, not having more than a certain new severity, needs peer review, needs security analyst review, needs an issue created or a jira ticket, no deploys during certain days. Policies can also match regulatory frameworks, e.g. HIPPA; Custom set of rules, but should also have templates/standards * `Environment Compliance Definition` - This links each environment to its compliance levels. => Sid: If we have this should we also have something to link compliance level to policies? I assume we reuse policies in multiple compliance levels. ### Permissions and Security ### Documentation ### Testing ### What does success look like, and how can we measure that? ### Hurdles * Compliance is split across multiple stages in GitLab- manage, verify, create, release, etc ### What is the type of buyer? This would be an Ultimate feature targeted at Executives ### Links / references -->