Dependency List Leaves Old Dependencies When Image Registry Changes
Summary
When the registry of a container image being scanned in a GitLab project is changed, the Dependency List of the project still contains the dependencies of the previously scanned image. These dependencies don't fall off the report and there doesn't appear to be any way to manually delete them from the project's Dependency List.
Steps to reproduce
- On a branch configure a
.gitlab-ci.yml
in a GitLab project to scan a docker image from dockerhub like this:
include:
- template: Jobs/Dependency-Scanning.gitlab-ci.yml
- template: Jobs/Container-Scanning.gitlab-ci.yml
container_scanning:
variables:
CS_IMAGE: docker.io/library/debian:buster-slim
- Merge the change into the main branch and see the Dependency List populate with
docker.io/library/debian:buster-slim
dependencies - On a branch update the
.gitlab-ci.yml
to reference a different image in another private repository like this:
include:
- template: Jobs/Dependency-Scanning.gitlab-ci.yml
- template: Jobs/Container-Scanning.gitlab-ci.yml
container_scanning:
variables:
CS_REGISTRY_USER: "$PRIVATE_REGISTRY_USER"
CS_REGISTRY_PASSWORD: "$PRIVATE_REGISTRY_PASSWORD"
CS_IMAGE: your.private-registry.com/some-image:some-tag
- Merge the change and see the Dependency List populate
- Observe that dependencies from
docker.io/library/debian:buster-slim
are still listed in the Dependency List even though the pipeline no longer includesdocker.io/library/debian:buster-slim
references in the pipeline artifacts
What is the current bug behavior?
A GitLab project's Dependency List doesn't update to reflect a different image from a different registry being scanned; leaving dependencies that are no longer applicable to the project.
What is the expected correct behavior?
GitLab's Dependency List should reflect what was found in the last pipeline run on the project's default branch and should not include dependencies of images no longer scanned in the project.