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 | 2024-11-20 |
Content Last Updated | 2024-11-20 |
Thanks for visiting this category direction page on Software Composition Analysis (Dependency Scanning and License Compliance) in GitLab. This page belongs to the Composition Analysis group of the Secure stage. The Product Manager is John Crowley 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.
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, 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 2023 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 17.5 we added Static Reachability for Java and Python as an experimental feature. This was a product of our Oxeye acquisition.
In GitLab 17.6 we added support for the Exploit Prediction Scoring System. This data is available through our GraphQL API and will be available in the GitLab UI in a future milestone.
During 17.7 we are working toward adding better vulnerability data to help prioritize remediation efforts. This will be accomplished by adding support for the Known Exploitable Vulnerability catalog, also known as KEV. Users will be able to better prioritize results by understanding which vulnerabilities have been exploited. Using KEV, EPSS, and CVSS Severity will provide a more accurate picture of the threat profile of projects.
Over the next few months, we will be focused on rolling out our new dependency scanning analyzer, which will replace Gemnasium. Our new analyzer will use the SBOM as the core scanning target. This change will better serve users by allowing us to more rapidly deliver features, support more languages, accept third party SBOMs for analysis, and reduce the overall maintenance burden for our team. Users will enable the new analyzer via a CI/CD component.
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: Amy (Application Security Engineer) and Isaac (Infrastructure Security Engineer) want 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.