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 | 2022-07-08 |
Thanks for visiting this category direction page on Container Scanning in GitLab. This page belongs to the Composition Analysis group of the Govern stage and is maintained by Sam White (swhite@gitlab.com).
This direction page is a work in progress, and everyone can contribute. We welcome feedback, bug reports, feature requests, and community contributions.
/label ~"devops::secure" ~"Category:Container Scanning" ~"group::composition analysis".
We believe everyone can contribute and so if you wish to contribute here is how to get started.
Container Scanning checks your Docker images against known vulnerabilities that may affect software that is contained in the image. Users often use existing images as the base for their containers. It means that they rely on the security of those images and their preinstalled software. Unfortunately, as this software is subject to vulnerabilities, this may affect the security of the entire project.
GitLab was recently named as a Challenger in the 2021 Magic Quadrant for Application Security Testing.
Our goal is to provide Container Scanning as part of the standard development process. This means that Container Scanning is executed every time a new commit is pushed to a branch, and only vulnerabilities introduced within the merge request are shown. We also include Container Scanning as part of Auto DevOps.
In the future, another place where Container Scanning results would be useful is in the GitLab Container Registry. Images built during pipelines are stored in the registry, and then used for deployments. Integrating Container Scanning into GitLab Container Registry will help to monitor if it is safe to deploy a specific version of the app.
Primary: Sasha (Software Developer wants to know when adding a container if it has known vulnerabilities so alternate versions or containers can be considered.
Secondary: Sam (Security Analyst) wants to know what containers have known vulnerabilities (to reduce the OWASP A9 risk - Using Components with Known Vulnerabilities), to be alerted if a new vulnerability is published for an existing component, and how behind current version the components are.
Other:
Our vision for container security is to provide the ability to scan container images regardless of where they may reside and to shift those results as far left as possible.
To reach the Complete Maturity level, we will need to accomplish the following. Epics and issues for most of these items can be found nested in the Container Scanning Viable to Complete Epic. These items are grouped thematically and are not in priority order. Priorities for these items can be found on our always-open priorities issue.
In addition to this work, we also need to allow users to scan images that are used in running Kubernetes clusters. This is available now in an Alpha state and we are working to get this ready for general availability.
In the GitLab 14.1 release, we introduced a feature in an Alpha state to allow users to scan container images that are actively running in a Kubernetes cluster for vulnerabilities. Those vulnerabilities then get reported back to the Security Center. In the next few milestones, we plan to finish developing this feature and move it from an Alpha state into a production-ready GA state.
In the GitLab 15.0 release, we moved the basic ability to run a container scan down to the free tier.
For next steps, we plan to allow GitLab to continuously scan dependencies for known vulnerabilities by synchronously triggering a re-scan anytime either the container image changes or when the advisory database is updated. These plans can be tracked in more detail in this epic.
A full list of our near-term priorities is kept up-to-date on our open priorities issue.
TBD
This category is currently at Viable maturity. A plan has been created for the category to progress to Complete maturity.
We will be researching current user challenges in this issue. Please feel free to comment!
Currently we notify developers when they add containers with known vulnerabilities in a merge request, if security approvals are configured, we will require an approval for vulnerabilities that exceed a specified severity level. A summary of all findings for a project can be found in the Security Dashboard where Security Teams can quickly check the security status of projects. In some cases we are able to offer automatic remediation for the findings.
Our primary success metric is the number of unique users who run a container security scan each month.
In addition to being A9 Using Components with Known Vulnerabilities in the OWASP top 10, keeping components up to date is code quality issue, and finally as the need for software bill of materials (SBoM) grows being able to list your dependencies will become a needed feature for all application developers.
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. GitLab was recently named as a Challenger in the 2021 Magic Quadrant for Application Security Testing.
Top Epics and Issues can be viewed in this list
If you don't see the customer success label on an issue yet, and you are a customer success team-member, feel free to add it!
If you don't see the customer label on an issue yet, feel free to add it if you are the first customer!
If you don't see the internal customer label on an issue yet, and you are a team-member, feel free to add it!
To be determined.