馃摚 Feedback for Container Scanning for Registry
Please provide feedback regarding your experience with the Container Scanning for Container Registry feature.
How to enable the feature
- Enable the
container_scanning_for_registry
Feature Flag for your project- e.g.:
/chatops run feature set container_scanning_for_registry true --project=gitlab-org/some-project
- e.g.:
- Switch the feature on
- GraphQL: use graphql-explorer to call the
setContainerScanningForRegistry
mutation (example below). - UI: Open
Secure/Security Configuration
, findContainer Scanning for Registry
and switch the toggle on.
- GraphQL: use graphql-explorer to call the
- Ensure Continuous Vulnerability Scanning is enabled
GraphQL example for setContainerScanningForRegistry
mutation SetContainerScanningForRegistry {
setContainerScanningForRegistry(
input: {
namespacePath: "gitlab-org/some-project",
enable: true}) {
containerScanningForRegistryEnabled
errors
}
}
What happens when the feature is enabled
Any time a container image is pushed to the container registry in your project, GitLab will check its tag and the scan limit.
If the tag is latest
, and the number if scans is under the limit (50 scans/day), then GitLab creates a new pipeline that runs a container_scanning
job on the image.
The pipeline is associated with the user who pushed the image to the registry.
The scan job generates a CycloneDX SBOM that is then uploaded to GitLab.
At this point, the Continuous Vulnerability Scanning feature takes-over to scan the packages detected in the SBOM.
Note that a vulnerability scan is only performed when a new advisory is published, which typically happens when the package metadata is synchronized
Coming-up next
- In CVS Trigger vulnerability scans on SBOM changes (&8026) we are working to trigger vulnerability scans when packages are updated.
- Container Registry CVS Iteration 2 (&13049) brings UI and performance improvements
- Dependency List Support for Container Registry ... (&7943)