Use the `CS_DEFAULT_BRANCH_IMAGE` value as the location of container-scanning found CycloneDX components

Summary

The container image referenced in the CycloneDX SBOMS produced by container-scanning does not follow the configured CS_DEFAULT_BRANCH_IMAGE setting. This means that the findings created by CVS do not reflect the true location specified by the user.

Steps to reproduce

1. Create a project that produces a container image
2. Include the container-scanning template and set the CS_DEFAULT_BRANCH_IMAGE setting.
3. Run a scan and verify that the image property does not reflect the configured setting.

Example Project

n/a

What is the current bug behavior?

The actual image scanned is used.

What is the expected correct behavior?

The value of CS_DEFAULT_BRANCH_IMAGE is used instead.

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

Pick up the environment variable and overwrite the image attributes when converting the trivy sbom.

Implementation plan

• Update sbom converter to use image name if CS_DEFAULT_BRANCH_IMAGE is set.

Workaround

In an after script, you can replace the value of the SBOM's CycloneDX property - gitlab:container_scanning:image - with the value of CS_DEFAULT_BRANCH_IMAGE.