The following 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.
| Stage | Secure |
| Maturity | Minimal |
| Content Last Reviewed | 2022-07-08 |
| Content Last Updated | 2022-07-08 |
Thanks for visiting this category direction page on License Compliance at GitLab. This page belongs to the Composition Analysis group of the Secure stage and is hiring a new Product Manager. The interim Product Manager is Sam White.
The Composition Analysis Group's primary focus is GitLab-hosted First putting reliability, scalability, and security first.
We welcome feedback, bug reports, feature requests, and community contributions.
Not sure how to get started?
/label ~"devops::secure" ~"Category:License Compliance" ~"group::composition analysis" ~"type::feature".
Sharing your feedback directly on GitLab.com is the best way to contribute to our direction.
We believe everyone can contribute and so if you wish to contribute here is how to get started.
License Compliance analyzes your application to track which licenses are used by third-party components, like libraries and external dependencies, and check that they are compatible with your policies.
License Compliance is often considered an element of Software Composition Analysis, Software Bill of Materials (SBOM), and compliance activities.
GitLab was named as a Challenger in the 2021 Magic Quadrant for Application Security Testing.
Licenses can be incompatible with the chosen license model for the application, for example because of their redistribution rights.
Our goal is to provide License Compliance as part of the standard development process. This means that License Compliance is executed every time a new commit is pushed to a branch, identifying newly introduced licenses in the merge request. We also include License Compliance as part of Auto DevOps.
Primary: Sasha (Software Developer) wants to know when adding a dependency if it has permitted licenses.
Other: Cameron (Compliance Manager), Delaney (Development Team Lead)
We will be researching current user challenges in this issue. Please feel free to comment!
Our vision for license compliance is to allow users to detect and enforce license controls on their projects with a high degree of accuracy and with as little user friction as possible.
When License Compliance is resourced, we will be focusing on progressing the maturity of the category from minimal to viable. Currently, based on discussions with users, the focus for each progression is detailed below in "What's Next & Why".
We expect users to be able to clearly specify what licenses are permissible for which internal projects, and for developers to be promptly aware when they add a license that is against policy and who they can talk to about it.
Users tasked with verification of compliance will be easily able to review what licenses are utilized through the projects, which deviate from policy, and who approved the exception.
Our vision for license compliance is to provide users with a flexible way to define and enforce license compliance policies for their projects. Ultimately we view License Approval Policies becoming a feature within the GitLab security policy editor and replacing the current License-Check functionality that exists today.
Additionally we plan on consolidating the tools that are required to run in the CI pipeline by rearchitecting the product to identify licenses that are discovered by the Container Scanning and Dependency Scanning analyzers. This will pave the way for GitLab to be better able to control the quality of license data that is used to match against the packages that are found in a project. In the long run we would like to allow users to identify licenses even for projects that have complex scenarios such as multiple licenses that may be joined by either and or or clauses.
On the management side, we plan to improve the way that license information is presented in the GitLab UI by allowing users to search, filter, and rollup license information across all of their projects at the group level.
Currently License Compliance relies on an upstream license-finder project which has not been well maintained. We are working to replace the need to have a dedicated license scanner by instead moving to a new architecture. In the new architecture, dependencies will be detected and reported up by the Container Scanning and Dependency Scanning analyzers. These dependencies will then be stored in the GitLab database where they will be matched against licenses. This new approach will eliminate the maintenance burden that the GitLab engineering team currently faces in trying to update the license-finder analyzer. It will also allow us to standardize our language support by focusing all of our language-specific package detection in the single Dependency Scanning analyzer code base.
TBD
This category is currently at Minimal maturity. A plan has been created for the category to progress to Viable maturity.
We track the unique number of users who run at least one license compliance job each month to measure our usage and success.
Users have indicated they wish to enforce license compliance policies as early as possible. This contributes to the need that users have for producing a software bill of materials (SBoM).
License Compliance is frequently bundled together with Container Scanning and Dependency Scanning to provide an overall Software Composition Analysis (SCA) solution within the Application Security Testing (AST) market. GitLab was recently named as a Challenger in the 2021 Magic Quadrant for Application Security Testing.