|Content Last Reviewed||
|Content Last Updated||
We welcome feedback, bug reports, feature requests, and community contributions.
Not sure how to get started?
/label ~"devops::protect" ~"Category:Container Scanning" ~"group::container security".
Sharing your feedback directly on GitLab.com is the best way to contribute to our direction.
Our best practices are to package applications into containers, so they can be deployed to Kubernetes.
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.
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: Cameron (Compliance Manager), Delaney (Development Team Lead), Devon (DevOps Engineer), Sidney (Systems Administrator)
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 critical, high or unknown findings. 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.
To be determined when focus returns to this category. Currently Container Scanning is being maintained but not actively pushed forward while the group concentrates on Dependency Scanning.
To be determined when focus returns to this category.
Anything other than bug fixes and improvements for internal customers.
This category is currently at the Viable maturity level, and our next maturity target is not set (see our definitions of maturity levels
Currently we have very limited product analytics data, as a result we will be tracking number of times that our scans run.
In the future we hope that users will allow us to enhance our telemetry to be able to record information such as the number of findings that are dismissed vs. accepted. See our current metrics here, and other items being discussed in this issue.
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.
We continue to engage analysts so they remain aware that we offer Container Scanning, which is sometimes considered stand-alone and other times it is considered part of Application Security Testing (AST) or Software Composition Analysis (SCA) bundles as defined in our Solutions, since vulnerabilities for base images can be considered very similar to vulnerabilities for software dependencies.
We can get valuable feedback from analysts, and use it to drive our vision.
I base this on
popularity, so please remember to comment AND upvote issues you would like to see.
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.