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-06-25 |
| Content Last Updated | 2024-06-25 |
Thanks for visiting this category direction page on Container Scanning in GitLab. This page belongs to the Composition Analysis group of the Application Security Testing stage.
Everyone can contribute:
Container scanning analyzes the packages and libraries used in a container image. 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, container scanning solutions analyze those dependencies to identify known vulnerabilities in those dependencies.
Container Scanning is often considered an element of Software Composition Analysis and Application Security Testing.
Additional details about our current features and capabilities can be viewed in our documentation.
We have three main themes in our container scanning strategy:
In GitLab 18.1 we added support for license scanning of Operating System packages. See more details here.
During 18.2 we are working towards supporting Archive File scanning for Container Scanning. This will permit users to more easily scan multiple .tar files by removing a workaround that caused duplicate findings.
In the short-term, the Composition Analysis team will be focused on allowing users to more easily scan multiple images. We will be focused on optimizing performance and making iterative changes based on feedback from users.
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 container scanning solution. Not all of these capabilities are currently supported by GitLab today.
The latest Composition Analysis priorities can be found in the FY26 Execution Roadmap here (internal).
Primary: Sasha (Software Developer) wants to know when adding a dependency to a container image 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 in their container images 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 Container 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.
Container Scanning is frequently bundled together with Dependency Scanning and License Compliance to provide an overall Software Composition Analysis (SCA) solution within the Application Security Testing (AST) market.