Leverage merge request approvals to prevent merging prohibited licenses - License Compliance Approvals in Merge Request MVC
was: disallow merging with blacklisted licenses
Problem to solve
Currently, the license compliance section in the merge request widget only displays newly detected licenses (blacklist, approved, unclassified). Blacklisted licenses are able to be merged without any permission or notification. Need to disallow blacklisted licenses that are newly committed/detected in a merge request.
Intended users
Smaller to mid size orgs
Larger orgs
- Software Asset Manager (wiki) or user responsible for license compliance
Further details
License compliance user job to be done
- User who may be adding licenses via commit: "When my organization has license compliance rules to follow I want to be able to whitelist or blacklist licenses so that I can ensure any new code merged in a project is in compliance". gitlab-design#402 (closed)
- User that is accountable for compliance: "When new licenses are added to a project I want to be aware so I can commit work that is compliant with my organization's rules". gitlab-design#402 (closed)
Proposal
We are leveraging the approver's group feature to disallow an MR that detects a newly introduced blacklisted license (similar as https://gitlab.com/gitlab-org/gitlab-ee/issues/9928). This is for users that are accountable for license compliance (currently: project Maintainer only can change License Management settings).
1. User blacklists a specific license in the license compliance area, which is currently in Project Settings > CI/CD > License Management (example: https://gitlab.com/gitlab-examples/security/security-reports/-/settings/ci_cd). Note: this assumes that the feature has been configured correctly, there is a UX issue here: https://gitlab.com/gitlab-org/gitlab-ee/issues/12685
| 2. Blacklisted license is selected | 3a. The MR approver's settings section | 3b. License-Check edit |
|---|---|---|
 |
 |
 |
| If it’s detected in an MR it will only display that it is blacklisted. For the MR to be disallowed the feature would need to be activated in the MR approvers section OR in the below UI displaying the approvers' rule directly in the license settings area. The table row would be in both the MR approvers area (Settings > General > Merge request approvals) and in this section (Settings > CI/CD > License Management) for visibility. | Displays the License-Check rule. This in addition to the Vulnerability-Check rule. |
Modal appears when user selects edit for License-Check seen in 3a |
Permissions and Security
Maintainer
Documentation
- Security approvals backend implementation video walkthrough
- https://gitlab.com/gitlab-org/security-products/brown-bag-sessions/issues/2
- https://gitlab.com/gitlab-org/gitlab-ce/blob/3d9a3a3de195fea68e2906a67839f5052f9839cc/doc/user/application_security/index.md#security-approvals-in-merge-requests
Testing
TODO
What does success look like, and how can we measure that?
TODO
What is the type of buyer?
Ultimate
Links / references
- https://gitlab.com/gitlab-org/gitlab-ee/issues/9928
- https://gitlab.com/gitlab-org/gitlab-ee/issues/13139
- https://gitlab.com/gitlab-org/gitlab-ee/issues/9928#note_190385002
- To see what our current baseline license compliance UX looks like, see the following issues:
- For users that are accountable for license compliance, reactive and proactive use cases: gitlab-design#402 (closed)
- For users that are responsible for license compliance: gitlab-design#478 (closed)
Implementation Plan
-
Add "License-Check" approval rule to backend code to enforce policy -
Add License-Check approval rule to the list of approvers in the MR. -
Add the proper documentation/user guides to use this new feature.
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.