Container Scanning parsing doesn't have image name in location when image is missing :

Summary

When ingesting a Container Scanning report, we try to parse the image name assuming the format is image:version:

            def docker_image_name_without_tag(image_name = prepare_image_name)
              base_name, _, version = image_name.rpartition(':')

              return image_name if version_semver_like?(version)

              base_name
            end

This is not necessarily the case, e.g. when scanning a latest version of an image without specifying :latest, as Docker assumes a plain image name refers to image:latest. In that case, we set CS_IMAGE to image_name and the scanned image is image_name:latest but the name we receive is just image_name, without :latest.

In docker_image_name_without_tag, when image_name does not contain a :, the rpartition returns an the array ["", "", "image_name"], meaning base_name is empty. Since version_semver_like? always returns false for strings starting with a letter, then any image_name without a : that starts with a letter will lead docker_image_name_without_tag to return base_name, which is "", empty.

The outcome of this is a vulnerability location without an image name in the vulnerability report. See the format vulnerability in :<package>:

The expected format should be image_name:package.

This also affects archive scanning where we're not able to extract the image name from the archive and use the archive path instead.

Workaround

To work around this, add a tag to the scanned image, e.g. image:latest instead of just image.

For archive scanning, ensure the image is tagged when building the archive.

Steps to reproduce

1. Create a pipeline with a Container Scanning job.
2. Set the CS_IMAGE to some image without a version, e.g. vulnerables/web-dvwa.
3. Run the pipeline and check the Vulnerability Report to see badly named locations.

Example Project

What is the current bug behavior?

Scanning an image without : in its name (whether image name or tarball path, when we can't extract the image name from the tarball) yields locations without the image name.

What is the expected correct behavior?

Scanning an image without : in its name yields a location containing the image name.

Relevant logs and/or screenshots

Output of checks

Results of GitLab environment info

Expand for output related to GitLab environment info

(For installations with omnibus-gitlab package run and paste the output of:
`sudo gitlab-rake gitlab:env:info`)

(For installations from source run and paste the output of:
`sudo -u git -H bundle exec rake gitlab:env:info RAILS_ENV=production`)

Results of GitLab application Check

Expand for output related to the GitLab application check

(For installations with omnibus-gitlab package run and paste the output of:
sudo gitlab-rake gitlab:check SANITIZE=true)
(For installations from source run and paste the output of:
sudo -u git -H bundle exec rake gitlab:check RAILS_ENV=production SANITIZE=true)
(we will only investigate if the tests are passing)

Possible fixes

Patch release information for backports

If the bug fix needs to be backported in a patch release to a version under the maintenance policy, please follow the steps on the patch release runbook for GitLab engineers.

Refer to the internal "Release Information" dashboard for information about the next patch release, including the targeted versions, expected release date, and current status.

High-severity bug remediation

To remediate high-severity issues requiring an internal release for single-tenant SaaS instances, refer to the internal release process for engineers.