| [Credentials inventory](credentials_inventory.md) | {{<iconname="check-circle">}} Yes | {{<iconname="dotted-circle">}} No | {{<iconname="dotted-circle">}} No | Keep track of the credentials used by all of the users in a GitLab instance. |
| [Granular user roles<br/>and flexible permissions](../user/permissions.md) | {{<iconname="check-circle">}} Yes | {{<iconname="check-circle">}} Yes | {{<iconname="check-circle">}} Yes | Manage access and permissions with five different user roles and settings for external users. Set permissions according to people's role, rather than either read or write access to a repository. Don't share the source code with people that only need access to the issue tracker. |
| [Push rules](../user/project/repository/push_rules.md) | {{<iconname="check-circle">}} Yes | {{<iconname="check-circle">}} Yes | {{<iconname="check-circle">}} Yes | Control pushes to your repositories. |
| Separation of duties using<br/>[protected branches](../user/project/repository/branches/protected.md#require-code-owner-approval-on-a-protected-branch) and<br/>[custom CI/CD configuration paths](../ci/pipelines/settings.md#specify-a-custom-cicd-configuration-file) | {{<iconname="dotted-circle">}} No | {{<iconname="dotted-circle">}} No | {{<iconname="check-circle">}} Yes | Leverage the GitLab cross-project YAML configurations to define deployers of code and developers of code. See how to use this setup to define these roles in the [Separation of Duties deploy project](https://gitlab.com/guided-explorations/separation-of-duties-deploy/blob/master/README.md) and the [Separation of Duties project](https://gitlab.com/guided-explorations/separation-of-duties/blob/master/README.md). |
| [Security policies](../user/application_security/policies/_index.md) | {{<iconname="check-circle">}} Yes | {{<iconname="check-circle">}} Yes | {{<iconname="check-circle">}} Yes | Configure customizable policies that require merge request approval based on policy rules, or enforce security scanners to execute in project pipelines for compliance requirements. Policies can be enforced granularly against specific projects, or all projects in a group or subgroup. |
For more information on all GitLab compliance features to ensure your GitLab group meets common compliance standards, see
| [Compliance frameworks](../user/group/compliance_frameworks.md) | {{<iconname="dotted-circle">}} No | {{<iconname="check-circle">}} Yes | {{<iconname="dotted-circle">}} No | Describe the type of compliance requirements projects must follow. |
| [Compliance pipelines](../user/group/compliance_pipelines.md) | {{<iconname="dotted-circle">}} No | {{<iconname="check-circle">}} Yes | {{<iconname="dotted-circle">}} No | Define a pipeline configuration to run for any projects with a given compliance framework. |
| [Merge request approval policy approval settings](../user/application_security/policies/merge_request_approval_policies.md#approval_settings) | {{<iconname="dotted-circle">}} Yes | {{<iconname="check-circle">}} Yes | {{<iconname="dotted-circle">}} Yes | Enforce a merge request approval policy enforcing multiple approvers and override various project settings in all enforced groups or projects across your GitLab instance or group. |
| [Merge request approval policy approval settings](../user/application_security/policies/merge_request_approval_policies.md#approval_settings) | {{<iconname="check-circle">}} Yes | {{<iconname="check-circle">}} Yes | {{<iconname="check-circle">}} Yes | Enforce a merge request approval policy enforcing multiple approvers and override various project settings in all enforced groups or projects across your GitLab instance or group. |
## Audit management
...
...
@@ -60,26 +45,38 @@ summary lists of audit data. Between these two, compliance teams can quickly
identify if problems exist and then drill down into the specifics of those issues.
These features can help provide visibility into GitLab and audit what is happening:
| [Audit events](audit_event_reports.md) | {{<iconname="check-circle">}} Yes | {{<iconname="check-circle">}} Yes | {{<iconname="check-circle">}} Yes | To maintain the integrity of your code, audit events give administrators the ability to view any modifications made in the GitLab server in an advanced audit events system, so you can control, analyze, and track every change. |
| [Audit reports](audit_event_reports.md) | {{<iconname="check-circle">}} Yes | {{<iconname="check-circle">}} Yes | {{<iconname="check-circle">}} Yes | Create and access reports based on the audit events that have occurred. Use pre-built GitLab reports or the API to build your own. |
| [Auditor users](auditor_users.md) | {{<iconname="check-circle">}} Yes | {{<iconname="dotted-circle">}} No | {{<iconname="dotted-circle">}} No | Auditor users are users who are given read-only access to all projects, groups, and other resources on the GitLab instance. |
| [Compliance center](../user/compliance/compliance_center/_index.md) | {{<iconname="dotted-circle">}} No | {{<iconname="check-circle">}} Yes | {{<iconname="check-circle">}} Yes | Quickly get visibility into the compliance posture of your organization through compliance standards adherence reporting and violations reports. Manage your groups compliance frameworks centrally. |
| [Audit events](audit_event_reports.md) | {{<iconname="check-circle">}} Yes | {{<iconname="check-circle">}} Yes | {{<iconname="check-circle">}} Yes | To maintain the integrity of your code, audit events give administrators the ability to view any modifications made in the GitLab server in an advanced audit events system, so you can control, analyze, and track every change. |
| [Audit reports](audit_event_reports.md) | {{<iconname="check-circle">}} Yes | {{<iconname="check-circle">}} Yes | {{<iconname="check-circle">}} Yes | Create and access reports based on the audit events that have occurred. Use pre-built GitLab reports or the API to build your own. |
| [Audit event streaming](audit_event_streaming/_index.md) | {{<iconname="check-circle">}} Yes | {{<iconname="check-circle">}} Yes | {{<iconname="check-circle">}} Yes | Stream GitLab audit events to a HTTP endpoint or third party service, such as AWS S3 or GCP Logging. |
| [Auditor users](auditor_users.md) | {{<iconname="check-circle">}} Yes | {{<iconname="dotted-circle">}} No | {{<iconname="dotted-circle">}} No | Auditor users are users who are given read-only access to all projects, groups, and other resources on the GitLab instance. |
## Policy management
Organizations have unique policy requirements, either due to organizational
standards or mandates from regulatory bodies. The following features help you
define rules and policies to adhere to workflow requirements, separation of duties,
| [Credentials inventory](credentials_inventory.md) | {{<iconname="check-circle">}} Yes | {{<iconname="dotted-circle">}} No | {{<iconname="dotted-circle">}} No | Keep track of the credentials used by all of the users in a GitLab instance. |
| [Granular user roles<br/>and flexible permissions](../user/permissions.md) | {{<iconname="check-circle">}} Yes | {{<iconname="check-circle">}} Yes | {{<iconname="check-circle">}} Yes | Manage access and permissions with five different user roles and settings for external users. Set permissions according to people's role, rather than either read or write access to a repository. Don't share the source code with people that only need access to the issue tracker. |
| [Push rules](../user/project/repository/push_rules.md) | {{<iconname="check-circle">}} Yes | {{<iconname="check-circle">}} Yes | {{<iconname="check-circle">}} Yes | Control pushes to your repositories. |
| [Security policies](../user/application_security/policies/_index.md) | {{<iconname="check-circle">}} Yes | {{<iconname="check-circle">}} Yes | {{<iconname="check-circle">}} Yes | Configure customizable policies that require merge request approval based on policy rules, or enforce security scanners to execute in project pipelines for compliance requirements. Policies can be enforced granularly against specific projects, or all projects in a group or subgroup. |
## Other compliance features
These features can also help with compliance requirements:
| [Email all users of a project,<br/>group, or entire server](email_from_gitlab.md) | {{<iconname="check-circle">}} Yes | {{<iconname="dotted-circle">}} No | {{<iconname="dotted-circle">}} No | Email groups of users based on project or group membership, or email everyone using the GitLab instance. These emails are great for scheduled maintenance or upgrades. |
| [Enforce ToS acceptance](settings/terms.md) | {{<iconname="check-circle">}} Yes | {{<iconname="dotted-circle">}} No | {{<iconname="dotted-circle">}} No | Enforce your users accepting new terms of service by blocking GitLab traffic. |
| [External Status Checks](../user/project/merge_requests/status_checks.md) | {{<iconname="dotted-circle">}} No | {{<iconname="dotted-circle">}} No | {{<iconname="check-circle">}} Yes | Interface with third-party systems you already use during development to ensure you remain compliant. |
| [Generate reports on permission<br/>levels of users](admin_area.md#user-permission-export) | {{<iconname="check-circle">}} Yes | {{<iconname="dotted-circle">}} No | {{<iconname="dotted-circle">}} No | Generate a report listing all users' access permissions for groups and projects in the instance. |
| [License approval policies](../user/compliance/license_approval_policies.md) | {{<iconname="dotted-circle">}} No | {{<iconname="dotted-circle">}} No | {{<iconname="check-circle">}} Yes | Search dependencies for their licenses. This lets you determine if the licenses of your project's dependencies are compatible with your project's license. |
| [Lock project membership to group](../user/group/access_and_permissions.md#prevent-members-from-being-added-to-projects-in-a-group) | {{<iconname="dotted-circle">}} No | {{<iconname="check-circle">}} Yes | {{<iconname="dotted-circle">}} No | Group owners can prevent new members from being added to projects in a group. |
| [LDAP group sync](auth/ldap/ldap_synchronization.md#group-sync) | {{<iconname="check-circle">}} Yes | {{<iconname="dotted-circle">}} No | {{<iconname="dotted-circle">}} No | Automatically synchronize groups and manage SSH keys, permissions, and authentication, so you can focus on building your product, not configuring your tools. |
| [LDAP group sync filters](auth/ldap/ldap_synchronization.md#group-sync) | {{<iconname="check-circle">}} Yes | {{<iconname="dotted-circle">}} No | {{<iconname="dotted-circle">}} No | Gives more flexibility to synchronize with LDAP based on filters, meaning you can leverage LDAP attributes to map GitLab permissions. |
| [Linux package installations support<br/>log forwarding](https://docs.gitlab.com/omnibus/settings/logs.html#udp-log-forwarding) | {{<iconname="check-circle">}} Yes | {{<iconname="dotted-circle">}} No | {{<iconname="dotted-circle">}} No | Forward your logs to a central system. |
| [Restrict SSH Keys](../security/ssh_keys_restrictions.md) | {{<iconname="check-circle">}} Yes | {{<iconname="dotted-circle">}} No | {{<iconname="dotted-circle">}} No | Control the technology and key length of SSH keys used to access GitLab. |
| [Email all users of a project,<br/>group, or entire server](email_from_gitlab.md) | {{<iconname="check-circle">}} Yes | {{<iconname="dotted-circle">}} No | {{<iconname="dotted-circle">}} No | Email groups of users based on project or group membership, or email everyone using the GitLab instance. These emails are great for scheduled maintenance or upgrades. |
| [Enforce ToS acceptance](settings/terms.md) | {{<iconname="check-circle">}} Yes | {{<iconname="dotted-circle">}} No | {{<iconname="dotted-circle">}} No | Enforce your users accepting new terms of service by blocking GitLab traffic. |
| [Generate reports on permission<br/>levels of users](admin_area.md#user-permission-export) | {{<iconname="check-circle">}} Yes | {{<iconname="dotted-circle">}} No | {{<iconname="dotted-circle">}} No | Generate a report listing all users' access permissions for groups and projects in the instance. |
| [LDAP group sync](auth/ldap/ldap_synchronization.md#group-sync) | {{<iconname="check-circle">}} Yes | {{<iconname="dotted-circle">}} No | {{<iconname="dotted-circle">}} No | Automatically synchronize groups and manage SSH keys, permissions, and authentication, so you can focus on building your product, not configuring your tools. |
| [LDAP group sync filters](auth/ldap/ldap_synchronization.md#group-sync) | {{<iconname="check-circle">}} Yes | {{<iconname="dotted-circle">}} No | {{<iconname="dotted-circle">}} No | Gives more flexibility to synchronize with LDAP based on filters, meaning you can leverage LDAP attributes to map GitLab permissions. |
| [Linux package installations support<br/>log forwarding](https://docs.gitlab.com/omnibus/settings/logs.html#udp-log-forwarding) | {{<iconname="check-circle">}} Yes | {{<iconname="dotted-circle">}} No | {{<iconname="dotted-circle">}} No | Forward your logs to a central system. |
| [Restrict SSH Keys](../security/ssh_keys_restrictions.md) | {{<iconname="check-circle">}} Yes | {{<iconname="dotted-circle">}} No | {{<iconname="dotted-circle">}} No | Control the technology and key length of SSH keys used to access GitLab. |
The compliance tools provided by GitLab help you keep an eye on various aspects of your project, including:
GitLab compliance features ensure your GitLab group meets common compliance standards, and are available at various pricing tiers. For more information about compliance management, see the compliance
| [Compliance frameworks](../group/compliance_frameworks.md) | {{<iconname="dotted-circle">}} No | {{<iconname="check-circle">}} Yes | {{<iconname="dotted-circle">}} No | Describe the type of compliance requirements projects must follow. |
| [Compliance pipelines](../group/compliance_pipelines.md) | {{<iconname="dotted-circle">}} No | {{<iconname="check-circle">}} Yes | {{<iconname="dotted-circle">}} No | Define a pipeline configuration to run for any projects with a given compliance framework. |
| [Merge request approval policy approval settings](../application_security/policies/merge_request_approval_policies.md#approval_settings) | {{<iconname="check-circle">}} Yes | {{<iconname="check-circle">}} Yes | {{<iconname="check-circle">}} Yes | Enforce a merge request approval policy enforcing multiple approvers and override various project settings in all enforced groups or projects across your GitLab instance or group. |
## Audit management
An important part of any compliance program is being able to go back and understand
what happened, when it happened, and who was responsible. You can use this in audit
situations as well as for understanding the root cause of issues when they occur.
It is helpful to have both low-level, raw lists of audit data as well as high-level,
summary lists of audit data. Between these two, compliance teams can quickly
identify if problems exist and then drill down into the specifics of those issues.
These features can help provide visibility into GitLab and audit what is happening:
| [Audit events](audit_events.md) | {{<iconname="check-circle">}} Yes | {{<iconname="check-circle">}} Yes | {{<iconname="check-circle">}} Yes | To maintain the integrity of your code, audit events give administrators the ability to view any modifications made in the GitLab server in an advanced audit events system, so you can control, analyze, and track every change. |
| [Audit reports](audit_events.md) | {{<iconname="check-circle">}} Yes | {{<iconname="check-circle">}} Yes | {{<iconname="check-circle">}} Yes | Create and access reports based on the audit events that have occurred. Use pre-built GitLab reports or the API to build your own. |
| [Audit event streaming](audit_event_streaming.md) | {{<iconname="check-circle">}} Yes | {{<iconname="check-circle">}} Yes | {{<iconname="check-circle">}} Yes | Stream GitLab audit events to a HTTP endpoint or third party service, such as AWS S3 or GCP Logging. |
| [Compliance center](compliance_center/_index.md) | {{<iconname="dotted-circle">}} No | {{<iconname="check-circle">}} Yes | {{<iconname="check-circle">}} Yes | Quickly get visibility into the compliance posture of your organization through compliance standards adherence reporting and violations reports. Manage your groups compliance frameworks centrally. |
## Policy management
Organizations have unique policy requirements, either due to organizational
standards or mandates from regulatory bodies. The following features help you
define rules and policies to adhere to workflow requirements, separation of duties,
| [Granular user roles<br/>and flexible permissions](../permissions.md) | {{<iconname="check-circle">}} Yes | {{<iconname="check-circle">}} Yes | {{<iconname="check-circle">}} Yes | Manage access and permissions with five different user roles and settings for external users. Set permissions according to people's role, rather than either read or write access to a repository. Don't share the source code with people that only need access to the issue tracker. |
| [Push rules](../project/repository/push_rules.md) | {{<iconname="check-circle">}} Yes | {{<iconname="check-circle">}} Yes | {{<iconname="check-circle">}} Yes | Control pushes to your repositories. |
| Separation of duties using<br/>[protected branches](../project/repository/branches/protected.md#require-code-owner-approval-on-a-protected-branch) and<br/>[custom CI/CD configuration paths](../../ci/pipelines/settings.md#specify-a-custom-cicd-configuration-file) | {{<iconname="dotted-circle">}} No | {{<iconname="dotted-circle">}} No | {{<iconname="check-circle">}} Yes | Leverage the GitLab cross-project YAML configurations to define deployers of code and developers of code. See how to use this setup to define these roles in the [Separation of Duties deploy project](https://gitlab.com/guided-explorations/separation-of-duties-deploy/blob/master/README.md) and the [Separation of Duties project](https://gitlab.com/guided-explorations/separation-of-duties/blob/master/README.md). |
| [Security policies](../application_security/policies/_index.md) | {{<iconname="check-circle">}} Yes | {{<iconname="check-circle">}} Yes | {{<iconname="check-circle">}} Yes | Configure customizable policies that require merge request approval based on policy rules, or enforce security scanners to execute in project pipelines for compliance requirements. Policies can be enforced granularly against specific projects, or all projects in a group or subgroup. |
## Other compliance features
These features can also help with compliance requirements:
| [External Status Checks](../project/merge_requests/status_checks.md) | {{<iconname="dotted-circle">}} No | {{<iconname="dotted-circle">}} No | {{<iconname="check-circle">}} Yes | Interface with third-party systems you already use during development to ensure you remain compliant. |
| [License approval policies](license_approval_policies.md) | {{<iconname="dotted-circle">}} No | {{<iconname="dotted-circle">}} No | {{<iconname="check-circle">}} Yes | Search dependencies for their licenses. This lets you determine if the licenses of your project's dependencies are compatible with your project's license. |
| [Lock project membership to group](../group/access_and_permissions.md#prevent-members-from-being-added-to-projects-in-a-group) | {{<iconname="dotted-circle">}} No | {{<iconname="check-circle">}} Yes | {{<iconname="dotted-circle">}} No | Group owners can prevent new members from being added to projects in a group. |
