Define license approval policies based on license categories

Problem statement

User story:

As a policy creator, I would like to configure license approval policy by license categories, so that I can enforce license compliance without worrying about specific license details.

More details:

  • Creating license approval policies is too laborious today. You have to deal with each license and license version one by one.
  • I want to be able to categorically define license approval policies, such as by using categories like "copyleft" or by using license risk classifications (e.g. Critical/High).
  • Policies should account for existing and future license versions, such that if I'm enforcing a rule on AGPL-1.0 and a new version of AGPL is released, I don't have to update my policy to account for it.

Proposal 1

Customers are asking me about default license policies. They would like to generally allow certain types of licenses, without worrying about specific license details. For example allow all libraries with a copyleft license model.

Proposal is the following, based on this thread (internal link):

  1. Compile lists of licenses, where each list is of a different type/class.
  2. Create a scan result policy that defines the enforcement per type/class of license?

I expect both the license lists and scan result policy could be stored in the same security policy project. To allow granularity of configuration, you could have multiple security policy projects, but keep the license lists (YAML files) in a separate project again, to which read/write access is limited. Also allow customers to add their own licenses to these lists and create their own lists as well.

Proposal 2

Create a new filter in license approval policies to enforce based on license risk (e.g. Critical/High/Med/Low). If a policy is configured to deny licenses with a risk rating of Critical, any licenses detected containing that attribute, based on the results from the GitLab Dependency Scanning analyzer, would be blocked.

Newly Detected: Policies can be configured to block on newly detected findings, meaning if an MR is raised targeting the default branch (for example), and the MR contains a package licensed with a Critical rating on the license, the MR would be blocked. Eligible approvers can then approve the MR as an exception for that project if desired.

Previously Existing: Alternatively, policies could be configured to block MRs if any existing findings are detected on the default branch. This would mean if a package is detected in the default branch of a project, new MRs would be blocked due to the finding, requiring action before those MRs can be unblocked.

Current state:

image

Proposed state:

image

Considerations:
  • Would users want to be able to define specific licenses in addition to or outside of the severity based classification? For example, block all criticals except for AGPL-1.0?
  • If there are multiple rules/policies what conflicts might occur and how should they be addressed?
  • Are there other UI elements desired to view where violations are occurring?

This request is an extension to the license approval feature based on a customer request.

Edited by Grant Hickman