Discovery: Project-level Compliance

A separate discovery issue has been created for exploring the specific feature of adding compliance controls to projects based on this discussion.

Problem to solve

Projects in a GitLab environment are subject to the policies of a customer's organization. These policies are based on compliance Frameworks that govern their industry. A customer organization may be required to comply with multiple frameworks. GitLab must enable customers to translate internal company policy to their GitLab projects to help manage their compliance.

Compliance is a large, expensive pain point and GitLab should make solving this problem easier, not more difficult.

Current Solutions

Customers build in-house services or processes to use data from GitLab to hack together Compliance monitoring solutions. This requires time and effort that detracts from their ability to focus on other, value-adding activities.

Some solutions incorporate external (to GitLab) systems, which are designed specifically to spot Compliance gaps or issues.

These custom solutions add unnecessary complexity to a GitLab instance, which can cause breakages or detrimental slowdowns as environments change. Non-native solutions are inherently difficult to maintain.

Intended users

• Delaney (Development Team Lead)
• Sasha (Software Developer)
• Sam (Security Analyst)
• All management stakeholders who adhere to any auditing process. For example in a finance institution (Security, Quality, Development department heads)

Proposal

Implement Compliance Controls 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 applications require PCI-DSS compliance, which requires very strict and prescriptive controls
• A Company marketing website may only be subject to frameworks like GDPR, which is less prescriptive about controls but still important

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 controls. A dashboard allows folks to see all projects in a group. This aggregate view is critical for executives and internal audit personnel to manage their compliance programs.

Compliance Controls at the project level makes sense because Projects are where the operations happen. This would prevent a merge if the controls aren’t met. It would still allow review apps. We should not block the following activities based on controls:

• 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 Groups have Frameworks, and Framework have Controls, Controls have Requirements and Overrides.

A merge request in a project with Controls needs to meet them before allowing a merge. For every project, merge, deploy, and environment you can see the framework, controls, requirements, and overrides.

You can get an overview of things that are out of compliance because:

• the framework got added later
• The controls were 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, each with specific Compliance Controls
• Frameworks - The list of compliance frameworks an organization adheres to. Each framework maps to specific Compliance Controls. 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. Controls can also match regulatory frameworks, e.g. HIPPA; Custom set of rules, but should also have templates/standards
• Group Compliance Definition - This links each Group to its compliance frameworks.

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

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

Links / References

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