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 | Viable |
| Content Last Reviewed | 2023-05-12 |
| Content Last Updated | 2023-05-12 |
Thanks for visiting this category direction page on Dependency Scanning in GitLab. This page belongs to the Composition Analysis group of the Secure stage. The Product Manager is Sara Meadzinger.
This direction page is a work in progress, and everyone can contribute:
Dependency scanning analyzes the dependencies used in a project. It identifies dependencies that have been directly included and it also analyzes those dependencies to get a list of their dependencies (also known as indirect or transitive dependencies). Once a full listing of all direct and transitive dependencies has been obtained, dependency scanning solutions analyze those dependencies to identify known vulnerabilities in those dependencies.
Dependency Scanning leverages the GitLab Advisory Database to check if any of these dependencies have known vulnerabilities, and it indicates if a package upgrade is needed.
Dependency Scanning and License Compliance are often considered two elements of Software Composition Analysis and Application Security Testing.
License compliance analyzes the dependencies used in a project. It identifies dependencies that have been directly included and it also analyzes those dependencies to get a list of their dependencies (also known as indirect or transitive dependencies). Once a full listing of all direct and transitive dependencies has been obtained, license compliance solutions analyze those dependencies to identify how those dependencies are licensed. Typically this information is stored in the metadata for the package; however, it may also be present in a file in the dependency's code repository. This type of analysis allows users to get a full list of all the licenses they are using in the project so they can ensure they are willing to adhere to the associated terms and conditions.
GitLab was named as a Challenger in the 2022 Magic Quadrant for Application Security Testing.
Additional details about our current features and capabilities can be viewed in our documentation.
We have five main themes in our software composition analysis strategy:
In GitLab 15.9 (for SaaS) and 15.10 (for self managed) we released support for a new method of license compliance scanning that no longer requires use of the Jobs/License-Scanning.gitlab-ci.yml template. Instead we now rely on the Dependency Scanning job to gather a list of dependencies and then we compare that list to licenses that are stored in our proprietary license database. This change helps users reduce the number of units of compute that they consume by gathering the list of dependencies just once in the Dependency Scanning job. It also gives GitLab greater control over the accuracy and completeness of the licenses that are reported as we now use our own license database. This new method of license scanning is intended to replace the previous License Scanning job. The License Scanning CI template is now deprecated and is planned to be removed in the GitLab 16.0 release.
In GitLab 15.10 we added a new configuration variable, DS_MAX_DEPTH, to allow users to configure the depth of directories that are scanned by the dependency scanning job. Previously this was limited to only 2 directories; however, as the value is now configurable, users can set it to a much larger number or to -1 to ensure that all directories in their project are analyzed.
In Gitlab 15.11 we added dependency scanning support for yarn v2 and v3 and pnpm thanks to a community contribution from Weyert de Boer. We also added a CycloneDX output for Container Scanning. This CycloneDX SBOM is named gl-sbom-report.cdx.json and is saved in the same directory as the JSON report file. You can download CycloneDX SBOMs the same way as other job artifacts.
During 16.0 we are working to address a number of high value improvements, most of which are focused on making our Operational Container Scanning solution more up-to-date and functional to meet the needs of our users.
Also, during 16.0 we are working toward introducing continuous vulnerability scans. This new method of scanning will have significantly better performance and will allow users to have their vulnerability results updated continuously as new advisories are added to our advisory database. This work is a prerequisite for a large number of other features on our roadmap. Once this work is completed, users will no longer need to run regular scheduled scans to have their vulnerability results updated for container images that have been scanned as part of the CI pipeline for their default branch.
Over the next few months, we plan on finishing the work for continuous vulnerability scans so we can release the feature to users.
Over the next few months, we plan to continue to improve and mature our new method of license scanning to make it a more reliable source of license information.
We currently do not have plans to add the following functionality during the next 12 months:
BIC (Best In Class) is an indicator of forecasted near-term market performance based on a combination of factors, including analyst views, market news, and feedback from the sales and product teams. It is critical that we understand where GitLab appears in the BIC landscape.
For this product area, these are the capabilities a best-in-class solution should provide:
This list represents some key capabilities of a comprehensive software composition analysis solution. Not all of these capabilities are currently supported by GitLab today.
Our prioritized roadmap can be viewed on our group direction page. Plans to move the category from Viable to Complete are tracked in GitLab.
Primary: Sasha (Software Developer) wants to know when adding a dependency if it has known vulnerabilities so alternate versions or dependencies can be considered.
Secondary: Sam (Security Analyst) wants to know what dependencies have known vulnerabilities, to be alerted if a new vulnerability is published for an existing component, and to know how behind current version the components are.
Other:
The GitLab Dependency Scanning features are all packaged as part of the GitLab Ultimate tier. This aligns with our pricing strategy as these features are relevant for executives who are concerned about keeping their organization secured from known vulnerabilities.
Dependency Scanning and License Compliance are frequently bundled together with Container 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 2022 Magic Quadrant for Application Security Testing.