<!-- The first section "Release notes" is required if you want to have your release post blog MR auto generated. Currently in BETA, details on the **release post item generator** can be found in the handbook: https://about.gitlab.com/handbook/marketing/blog/release-posts/#release-post-item-generator and this video: https://www.youtube.com/watch?v=rfn9ebgTwKg. The next four sections: "Problem to solve", "Intended users", "User experience goal", and "Proposal", are strongly recommended in your first draft, while the rest of the sections can be filled out during the problem validation or breakdown phase. However, keep in mind that providing complete and relevant information early helps our product team validate the problem and start working on a solution. --> ### Release notes <!-- What is the problem and solution you're proposing? This content sets the overall vision for the feature and serves as the release notes that will populate in various places, including the [release post blog](https://about.gitlab.com/releases/categories/releases/) and [Gitlab project releases](https://gitlab.com/gitlab-org/gitlab/-/releases). " --> ### Problem to solve <!-- What problem do we solve? Try to define the who/what/why of the opportunity as a user story. For example, "As a (who), I want (what), so I can (why/value)." --> Compliance teams need to be able to quickly evaluate whether or not their projects and groups adhere to common compliance standards so that they can drill in and remediate any areas that are out of compliance. There are multiple standards that exists and teams struggle to understand which requirements they already meet and do not meet across multiple standards. ### Intended users * [Cameron (Compliance Manager)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#cameron-compliance-manager) ### Proposal In the long-run, the vision is that the dashboard can display checks for multiple standards and be customized for any unique requirements that a customer may have. We will start by picking one standard (which is [SLSA](https://slsa.dev/spec/v0.1/requirements)) and allow for extension in the future. This is a point to keep in mind during design and implementation to allow for future extensibility, rather than hardcoding everything directly to SLSA. Provide an interface to define and select which compliance rules requirements should be checked for - _First iteration would likely be sufficient to have several pre-defined rules that can be turned on/off_ - _This could eventually be a CRUD interface for custom rule definition_ <details><summary>Click to expand</summary> 1. A new Group-level tab or page will be created for this report. **TODO: Decide where this report will live.** A non-exhaustive list of some ideas and potential options for consideration are as follows: 1. We could create a new page in the `Security & Compliance` menu. Perhaps something called "Security report". Any name we choose has the potential for confusion or conflict with the current "Compliance report" page. 1. We could adjust the current Compliance report page to have multiple tabs. This report could be the primary tab called "Overview" and the current content of that page could be moved to a secondary tab called "Merge Request Compliance" or perhaps just "MR Compliance". 1. The current Compliance report page is specific to merge request violations, but perhaps we could make it more generic to report on all kinds of compliance checks beyond just MR violations only. 1. This page could somehow be merged into the Security dashboard page. Perhaps there is a widget that appears on the security dashboard page that then links out to the full report elsewhere. 1. Something else.... </details> Create a dashboard that displays compliance rule requirements and whether or not they have been met. - _UX Question: Where does this screen live?_ <details><summary>Click to expand</summary> 1. Regardless of where this report is located, at a minimum, the report will contain a table with the following content: 1. A column for listing the compliance check that was performed. 1. A column for displaying the status of the compliance check (Passed, Failed, or Partially Met). Passed will equate to all projects in the group passing the check. Failed will equate to none of the projects in the group passing the check. Partially Met will come with an indicator (text, tooltip, or otherwise) that shows how many of the projects in the group passed/failed the check. 1. A column for displaying a list of requirements in common standards (SLSA, HIPPA, PCI, etc.) that relate to this compliance check. </details> ### SLSA Requirements <details><summary>Requirement list</summary> | Requirements | Minimum Level | |------------------------------------| ------------- | | Source - Version controlled | 2 | | Source - Verified history | 3 | | Source - Retained indefinitely | 3 | | Source - Two-person reviewed | 4 | | Build - Scripted build | 1 | | Build - Build service | 2 | | Build - Build as code | 3 | | Build - Ephemeral environment | 3 | | Build - Isolated | 3 | | Build - Parameterless | 4 | | Build - Hermetic | 4 | | Build - Reproducible | 4 | | Provenance - Available | 1 | | Provenance - Authenticated | 2 | | Provenance - Service generated | 2 | | Provenance - Non-falsifiable | 3 | | Provenance - Dependencies complete | 4 | | Common - Security | 4 | | Common - Access | 4 | | Common - Superusers | 4 | </details> **Initial checks for the first iteration** The following checks will be added for the first iteration. Additional checks may be added in future iterations. Also note that this is a proposal and the checks and criteria may change in the course of problem validation for this epic. | Check name | Relevant Compliance Standard(s) | Success Criteria | Failure Criteria | | ------ | ------ | ------ | ------ | | Two person review | GitLab Standard | At least one MR approval rule exists requiring 2+ people to approve a merge request | The project does not have at least one MR approval rule requiring 2+ people to approve a merge request | | Non-author merge | GitLab Standard | The MR approval setting to prevent authors from approving the MR is checked | The MR approval setting to prevent committers from approving the MR is not checked | | Non-committer merge | GitLab Standard | The MR approval setting to prevent committers from approving the MR is checked | The MR approval setting to prevent committers from approving the MR is not checked | Possible future checks | Check name | Relevant Compliance Standard(s) | Success Criteria | Failure Criteria | | ------ | ------ | ------ | ------ | | Two-factor Authentication (2FA) required | GitLab Standard | Setting to require 2FA for all users enabled | Setting to require 2FA for all users disabled | | Secret Detection enabled | GitLab Standard | At least one scan execution policy exists at the project or group level requiring secret detection jobs | No scan execution policies exists at the project or group level requiring secret detection jobs | | SAST enabled | GitLab Standard | At least one scan execution policy exists at the project or group level requiring SAST jobs | No scan execution policies exists at the project or group level requiring SAST jobs | | Dependency Scanning enabled | GitLab Standard | At least one scan execution policy exists at the project or group level requiring dependency scanning jobs | No scan execution policies exists at the project or group level requiring dependency scanning jobs | ### Designs ### Further details <!-- Include use cases, benefits, goals, or any other details that will help us understand the problem better. --> The following is **out of scope** for the MVC. In the future, these are some ways that we could potentially expand on this to make it better: 1. We could allow users to action on these items, with a navigational pathway to correcting the compliance check (enabling 2-person MR approvals or requiring code commits to be signed, etc.). 1. We could provide more details on compliance regulations by linking out to the specific compliance requirement or by making the text of the requirement available in a details view. 1. We could add in sorting, searching, and filtering. 1. We could add in a better way of visualizing which projects in the group have failed their checks. The current requirements suggest grouping things up to show a cross-project view; however, users may want to "ungroup" by project and view a separate line item per-project and per-check. This would allow them to better filter and triage these on a per-project basis. 1. We will ideally have this available at the Project, Sub-Group, Group, and Workspace levels. 1. We will add additional checks: 1. Coverage for all of the SLSA requirements 1. Coverage for requirements in other compliance standards besides SLSA 1. Checks regarding the status of our security scanners 1. Check if the scanner is enabled 1. Check if the scanner actually did in fact run for the most recent pipeline 1. Check that the scanner last ran no more than x hours ago (this is a common requirement) 1. Inspiration for other checks might come from https://github.com/ossf/scorecard#scorecard-checks ### Permissions and Security <!-- What permissions are required to perform the described actions? Are they consistent with the existing permissions as documented for users, groups, and projects as appropriate? Is the proposed behavior consistent between the UI, API, and other access methods (e.g. email replies)? Consider adding checkboxes and expectations of users with certain levels of membership https://docs.gitlab.com/ee/user/permissions.html * [ ] Add expected impact to members with no access (0) * [ ] Add expected impact to Guest (10) members * [ ] Add expected impact to Reporter (20) members * [ ] Add expected impact to Developer (30) members * [ ] Add expected impact to Maintainer (40) members * [ ] Add expected impact to Owner (50) members --> All users who have Auditor, Developer, Maintainer, or Owner permissions on the project will have access to this report. - @stkerr's note: This is a departure from the current Compliance report, which is Owner's only. Likely want to reconsider this point. ### Documentation <!-- See the Feature Change Documentation Workflow https://docs.gitlab.com/ee/development/documentation/workflow.html#for-a-product-change * Add all known Documentation Requirements in this section. See https://docs.gitlab.com/ee/development/documentation/feature-change-workflow.html#documentation-requirements * If this feature requires changing permissions, update the permissions document. See https://docs.gitlab.com/ee/user/permissions.html --> Documentation will be added and updated for this feature. ### Availability & Testing <!-- This section needs to be retained and filled in during the workflow planning breakdown phase of this feature proposal, if not earlier. What risks does this change pose to our availability? How might it affect the quality of the product? What additional test coverage or changes to tests will be needed? Will it require cross-browser testing? Please list the test areas (unit, integration and end-to-end) that needs to be added or updated to ensure that this feature will work as intended. Please use the list below as guidance. * Unit test changes * Integration test changes * End-to-end test change See the test engineering planning process and reach out to your counterpart Software Engineer in Test for assistance: https://about.gitlab.com/handbook/engineering/quality/test-engineering/#test-planning --> ### What does success look like, and how can we measure that? <!-- Define both the success metrics and acceptance criteria. Note that success metrics indicate the desired business outcomes, while acceptance criteria indicate when the solution is working correctly. If there is no way to measure success, link to an issue that will implement a way to measure this. --> ### What is the type of buyer? <!-- What is the buyer persona for this feature? See https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/buyer-persona/ In which enterprise tier should this feature go? See https://about.gitlab.com/handbook/product/pricing/#four-tiers --> ~"GitLab Ultimate" ### Is this a cross-stage feature? <!-- Communicate if this change will affect multiple Stage Groups or product areas. We recommend always start with the assumption that a feature request will have an impact into another Group. Loop in the most relevant PM and Product Designer from that Group to provide strategic support to help align the Group's broader plan and vision, as well as to avoid UX and technical debt. https://about.gitlab.com/handbook/product/#cross-stage-features --> ### Links / references One open source project that generates a "scorecard" on GitHub is https://github.com/ossf/scorecard#scorecard-checks <!-- Label reminders - you should have one of each of the following labels if you can figure out the correct ones --> <!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION --> *This page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.* <!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION -->