### Govern Lighthouse Metric | Metric Short Name | Metric Description | Type of Metric (User / Event) | Calculation | |-------------------|--------------------|-------------------------------|-------------| | Compliance Adoption | Percentage of the Subscription's projects which are in-scope for compliance that have compliance controls applied. | Project | For a given subscription the adoption percentage will be the average of the four Compliance sub use cases identified below - [Platform Hardening](#platform-hardening-administrators) - [Vulnerability Management](#vulnerability-management-security-departments) - [License Compliance](#license-compliance-legal-departments) - [Standards Adherence](#standards-adherence-compliance-departments) #### Projects that are in-scope for Compliance For the first iteration, to keep it simple, we plan on identifying any project that meets one or more of the following criteria as a "project that is in-scope for compliance". 1. Project is using CD (if they are deploying to production, then they probably are in-scope for compliance) 1. Project has an active Jenkins integration 1. Project has a Compliance Framework Label assigned to the project This list will be evaluated and iterated on to improve its accuracy in the future. The following sub use-cases are evaluated only for projected that are estimated to be in-scope for compliance. #### Compliance Sub Use Cases ##### Platform Hardening (Administrators) *This account's Administrators are adopting the Platform Hardening compliance sub use case on xx% of the projects that are estimated to be in-scope for Compliance.* A project is estimated to be using the Platform Hardening sub use case if one or more of the following features are in use: | Feature | How "in use" is calculated | |---------|----------------------------| | Credential Inventory | At least one user has visited the [Credential Inventory page](https://docs.gitlab.com/ee/administration/credentials_inventory.html) in the last month | | Token Lifetime Limits | The instance has lifetime limits configured for [SSH keys](https://docs.gitlab.com/ee/administration/settings/account_and_limit_settings.html#limit-the-lifetime-of-ssh-keys) or [Access Token](https://docs.gitlab.com/ee/administration/settings/account_and_limit_settings.html#limit-the-lifetime-of-access-tokens) or both (available for self managed only) | | Secure Credentials | The instance has [additional password complexity requirements](https://docs.gitlab.com/ee/administration/settings/sign_up_restrictions.html#minimum-password-length-limit) configured (available for self managed only) **or** 2FA requirements are enforced (at either the top-level group or the instance level) **or** either 2FA or passwordless authentication is in use for all users of the project. | | Custom Roles | The project has at least one member (either direct or inherited) who is assigned a [custom role](https://docs.gitlab.com/ee/user/custom_roles.html). | | Enterprise Users | The project has at least one member (either direct or inherited) who is identified as an Enterprise User and at least one [Enterprise User control](https://docs.gitlab.com/ee/user/enterprise_user/#manage-enterprise-users-in-a-namespace) is being enforced for the namespace. (available for SaaS only) | ##### Vulnerability Management (Security Departments) *This account's Security Department is adopting the Vulnerability Management compliance sub use case on xx% of the projects that are estimated to be in-scope for Compliance.* A project is estimated to be using the Vulnerability Management sub use case if one or more of the following features are in use: | Feature | How "in use" is calculated | |---------|----------------------------| | Vulnerability Report | At least one user has visited the vulnerability report or called the vulnerability API for either this project or for one of its parent groups. Also the project must have run at least one security scan in the last month and must have at least one vulnerability that is marked as resolved. | | Dependency List | At least one user has visited the dependency list report or called the dependency API for either this project or for one of its parent groups. Also the project must have run at least one security scan in the last month and must have at least one vulnerability that is marked as resolved. | | Security Dashboard | At least one user has visited the security dashboard for either this project or for one of its parent groups. Also the project must have run at least one security scan in the last month and must have at least one vulnerability that is marked as resolved. | | Scan Execution Policy | The project has at least one active scan execution policy requiring a scan to run. | | Security Scan Result Policy | The project has at least one active `Security Scan` type of scan result policy. | ##### License Compliance (Legal Departments) *This account's Legal Department is adopting the License Compliance sub use case on xx% of the projects that are estimated to be in-scope for Compliance.* A project is estimated to be using the License Compliance sub use case if either the License Scan Result Policy feature is in use **or** if **both** the Dependency List and Scan Execution (DS/CS) Policy features are in use. | Feature | How "in use" is calculated | |---------|----------------------------| | Dependency List | At least one user has visited the dependency list report for either this project or for one of its parent groups. Also the project must have run at least one security scan in the last month and must have at least one vulnerability that is marked as resolved. | | Scan Execution (DS/CS) Policy | The project has at least one active scan execution policy requiring either Dependency Scanning or Container Scanning to run. | | License Scan Result Policy | The project has at least one active `License Scan` type of scan result policy. | ##### Standards Adherence (Compliance Departments) *This account's Compliance Department is adopting the Standards Adherence compliance sub use case on xx% of the projects that are estimated to be in-scope for Compliance.* A project is estimated to be using the Standards Adherence sub use case if two or more of the following features are in use: | Feature | How "in use" is calculated | |---------|----------------------------| | MR Approval Rules | The project has at least one active `Any merge request` type of scan result policy. | | Standards Adherence Report | At least one user has visited the Standards Adherence page within the last month for the project's top-level group. | | Custom Scan Execution Policy | The project has at least one Scan Execution policy that enforces a custom yaml job. | | External Status Check | The project has at least one external status check configured. | | Audit Log | Either streaming audit events are setup for the project, a parent group, or the instance **or** at least one user has visited the Audit Log page within the last month for the project, a parent group, or the instance, **or** the Audit Event API has been queried within the last month for the project, a parent group, or the instance. |