Project-level Compliance

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

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.
  2. Never block improvements that don’t make the situation worse. These things might be solving an important need.
  3. Don’t store it both in code and the UX since that is very hard.
  4. 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.)
  2. All environments with an override.
  3. 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
  2. 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

Edited by Sid Sijbrandij