Pirate Praveen 54117d12b7 New upstream version 15.5.4+ds1

2022-11-25 23:54:43 +05:30

11 KiB

Raw Blame History

type	stage	group	info
reference, howto	Govern	Compliance	To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments

Compliance report (ULTIMATE)

Introduced in GitLab 12.8 as Compliance Dashboard.

Renamed to compliance report in GitLab 14.2.

Replaced by merge request violations in GitLab 14.6 with a flag named compliance_violations_report. Disabled by default.

GraphQL API introduced in GitLab 14.9.

Generally available in GitLab 14.10. Feature flag compliance_violations_report removed.

Compliance report gives you the ability to see a group's merge request activity. It provides a high-level view for all projects in the group. For example, code approved for merging into production.

You can use the report to get:

A list of compliance violations from all merged merge requests within the group.
The reason and severity of each compliance violation.
A link to the merge request that caused each compliance violation.

View the compliance report for a group

Prerequisites:

You must be an administrator or have the Owner role for the group.

To view the compliance report:

On the top bar, select Main menu > Groups and find your group.
On the left sidebar, select Security & Compliance > Compliance report.

Severity levels scale

The following is a list of available violation severity levels, ranked from most to least severe:

Icon	Severity level
{severity-critical, 18, gl-fill-red-800}	Critical
{severity-high, 18, gl-fill-red-600}	High
{severity-medium, 18, gl-fill-orange-400}	Medium
{severity-low, 18, gl-fill-orange-300}	Low
{severity-info, 18, gl-fill-blue-400}	Info

Violation types

The following is a list of violations that are either:

Already available.
Aren't available, but which we are tracking in issues.

Violation	Severity level	Category	Description	Availability
Author approved merge request	High	Separation of duties	The author of the merge request approved their own merge request. Learn more.	Available in GitLab 14.10
Committers approved merge request	High	Separation of duties	The committers of the merge request approved the merge request they contributed to. Learn more.	Available in GitLab 14.10
Fewer than two approvals	High	Separation of duties	The merge request was merged with fewer than two approvals. Learn more.	Available in GitLab 14.10
Pipeline failed	Medium	Pipeline results	The merge requests pipeline failed and was merged.	Unavailable
Pipeline passed with warnings	Info	Pipeline results	The merge request pipeline passed with warnings and was merged.	Unavailable
Code coverage down more than 10%	High	Code coverage	The code coverage report for the merge request indicates a reduction in coverage of more than 10%.	Unavailable
Code coverage down between 5% to 10%	Medium	Code coverage	The code coverage report for the merge request indicates a reduction in coverage of between 5% to 10%.	Unavailable
Code coverage down between 1% to 5%	Low	Code coverage	The code coverage report for the merge request indicates a reduction in coverage of between 1% to 5%.	Unavailable
Code coverage down less than 1%	Info	Code coverage	The code coverage report for the merge request indicates a reduction in coverage of less than 1%.	Unavailable

Merge request drawer

Introduced in GitLab 14.1.

When you select a row, a drawer is shown that provides further details about the merge request:

Project name and compliance framework label, if the project has one assigned.
Link to the merge request.
The merge request's branch path in the format [source] into [target].
A list of users that committed changes to the merge request.
A list of users that commented on the merge request.
A list of users that approved the merge request.
The user that merged the merge request.

Separation of duties

We support a separation of duties policy between users who create and approve merge requests. Our criteria for the separation of duties is as follows:

Chain of Custody report

Introduced in GitLab 13.3.

Chain of Custody reports sent using email introduced in GitLab 15.3 with a flag named async_chain_of_custody_report. Disabled by default.

FLAG: On self-managed GitLab, by default sending Chain of Custody reports through email is not available. To make it available, ask an administrator to enable the feature flag named async_chain_of_custody_report. On GitLab.com, this feature is not available.

The Chain of Custody report allows customers to export a list of merge commits within the group. The data provides a comprehensive view with respect to merge commits. It includes the merge commit SHA, merge request author, merge request ID, merge user, date merged, pipeline ID, group name, project name, and merge request approvers. Depending on the merge strategy, the merge commit SHA can be a merge commit, squash commit, or a diff head commit.

To generate the Chain of Custody report:

On the top bar, select Main menu > Groups and find your group.
On the left sidebar, select Security & Compliance > Compliance report.
Select List of all merge commits.

The Chain of Custody report is either:

Available for download.
Sent through email. Requires GitLab 15.3 and later with async_chain_of_custody_report feature flag enabled.

Commit-specific Chain of Custody report

Introduced in GitLab 13.6.

Authenticated group owners can generate a commit-specific Chain of Custody report for a given commit SHA, either:

Using the GitLab UI:
1. On the top bar, select Main menu > Groups and find your group.
2. On the left sidebar, select Security & Compliance > Compliance report.
3. At the top of the compliance report, to the right of List of all merge commits, select the down arrow ({chevron-lg-down}).
4. Enter the merge commit SHA, and then select Export commit custody report. SHA and then select Export commit custody report.