### Problem to solve Container Scanning scans Docker images when they are created during the pipeline. Images are then stored in the GitLab Container Registry, and can be reused by other pipelines and deployment processes as stable images that will land in production. Security status can change at any time even if there are no code changes, for example if an unknown vulnerability is disclosed to the public. Developers and security teams need to know the current security status of the images stored in the GitLab Container Registry. When the advisory database is updated, they need to know when new vulnerabilities apply to existing images. Similarly, they also need to know when new vulnerabilities are introduced when a new image is pushed into the registry. This needs to happen without requiring the users to manually run or schedule a CI pipeline. ### Further details :projector: Video walkthrough of this proposal: https://www.youtube.com/watch?v=pv928PCs3iQ Engineering DRIs: - ~backend @atiwari71 - ~frontend @fernando-c ### Proposal 1. Project Maintainers will be able to toggle "Continuous Container Scanning" on or off for each of their GitLab Container Registries (these are available at both the Project and Group levels) 1. For this iteration, a backend rails or feature flag style toggle is acceptable. We can iterate later to make this a better user experience for those who wish to disable continuous container scanning. 2. When "Continuous Container Scanning" is toggled on for a registry, vulnerabilities for all container images in that registry that are marked with the `latest` tag will automatically be identified and updated **any time a user pushes a new container image to the registry or any time our vulnerability database is updated**. 1. The container scanning job will run efficiently in a cost-effective manner 2. The container scanning job will assume default values for all available Container Scanning variables. Customization of these variables will not be added as part of this iteration (but may be added in a future iteration). 3. Users who view a specific container image in the registry will see a banner that provides summarized results from the Container Scanning findings. 1. At the project and group level, summarized vulnerability results will be displayed for the `latest` tag and a link will be provided to the Vulnerability Report page. 2. Note: The mocks show data related to dependencies; however, this part of the banner text is planned to be addressed in a [future iteration](https://gitlab.com/groups/gitlab-org/-/epics/7943 "Dependency List Support for Container Registry Scanning"). 4. At both the project and group levels, users will be able to view the vulnerabilities on the Vulnerability Report page. 1. Vulnerabilities will be displayed in a new `Container registry vulnerabilities` tab. 2. The `Container registry vulnerabilities` tab will support filtering by `Image`, `Severity`, and `Status` **Note:** As this is an MVC, users will only be able to view vulnerabilities for the `latest` tag. Support for all tags is planned in a future iteration. ### What does success look like, and how can we measure that? _This 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._ ### Design | Scan is on | Scan is off | |------------|-------------| |  |  | | Container registry page | Improved banner (use this mock) | |-------------------------|---------------------------------| |  |  | | Vulnerability page | Vulnerability page-filter dropdown open | Vulnerablity detail page | Vulnerablity detail page-2 | |--------------------|-----------------------------------------|--------------------------|----------------------------| |  |  |  |  | _This 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._ <!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION --> *This 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.* <!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION -->