Configure gitlab-runner related docker images to be scanned for vulnerabilities

What

As part of the gitlab-runner project, we produce A LOT of docker images in the gitlab-runner repo itself, and in other related repos (see https://gitlab.com/gitlab-com/Product/-/issues/4963#note_1139652185 for complete inventory). Many (probably not all) of those images should be scanned for vulnerabilities, but only a very few of them are:

• registry.gitlab.com/gitlab-org/gitlab-runner/go-fips
• registry.gitlab.com/gitlab-org/gitlab-runner/helper-entrypoint
• registry.gitlab.com/gitlab-org/gitlab-runner/ci
• registry.gitlab.com/gitlab-org/gitlab-runner/alpine-no-root
• registry.gitlab.com/gitlab-org/gitlab-runner/alpine-entrypoint
• registry.gitlab.com/gitlab-org/gitlab-runner/alpine-entrypoint-stderr
• registry.gitlab.com/gitlab-org/gitlab-runner/apline-id-overflow

In addition to the above, the following images (at least) should also be configured to be scanned for vulnerabilities when new version are pushed to the corresponding repository: repository

• registry.gitlab.com/gitlab-org/gitlab-runner (https://gitlab.com/gitlab-org/gitlab-runner)
  • ubi-fips
  • ubi-fips-bleeding
  • latest == ubuntu
  • alpine == alpine3.15
  • alpine3.14
  • alpine3.13
  • alpine3.12
• registry.gitlab.com/gitlab-org/gitlab-runner/gitlab-runner-helper (https://gitlab.com/gitlab-org/gitlab-runner)
  • alpine3.13-x86_64-@release
  • alpine3.13-arm-@release
  • alpine3.13-arm64-@release
  • alpine3.13-s390x-@release
  • alpine3.13-ppc64le-@release
  • alpine3.15-x86_64-@release
  • alpine3.15-arm-@release
  • alpine3.15-arm64-@release
  • alpine3.15-s390x-@release
  • alpine3.15-ppc64le-@release
  • alpine-latest-x86_64-@release
  • alpine-latest-arm-@release
  • alpine-latest-arm64-@release
  • alpine-latest-s390x-@release
  • alpine-latest-ppc64le-@release
  • ubuntu-x86_64-@release
  • ubuntu-arm-@release
  • ubuntu-arm64-@release
  • ubuntu-s390x-@release
  • ubuntu-ppc64le-@release
  • ubi-fips-latest-x86_64-@release
  • ubi-fips-latest-arm-@release
  • ubi-fips-latest-arm64-@release
  • ubi-fips-latest-s390x-@release
  • ubi-fips-latest-ppc64le-@release
• registry.gitlab.com/gitlab-org/ci-cd/gitlab-runner-ubi-images/gitlab-runner-ocp (https://gitlab.com/gitlab-org/ci-cd/gitlab-runner-ubi-images)
  • ppc64le-@release
  • @release
  • arm64-@release
  • amd64-@release
• registry.gitlab.com/gitlab-org/ci-cd/gitlab-runner-ubi-images/gitlab-runner-helper-ocp (https://gitlab.com/gitlab-org/ci-cd/gitlab-runner-ubi-images)
  • ppc64le-@release
  • @release
  • arm64-@release
  • x86_64-main
• registry.gitlab.com/gitlab-org/gl-openshift/gitlab-runner-operator/gitlab-runner-operator (https://gitlab.com/gitlab-org/gl-openshift/gitlab-runner-operator)
  • ppc64le-@release
  • @release
  • amd64-@release
• registry.gitlab.com/gitlab-org/gl-openshift/gitlab-runner-operator/gitlab-runner-operator-catalog-source (https://gitlab.com/gitlab-org/gl-openshift/gitlab-runner-operator)
  • ppc64le-@release
  • @release
  • amd64-@release
• registry.gitlab.com/gitlab-org/gl-openshift/gitlab-runner-operator/gitlab-runner-operator-bundle (https://gitlab.com/gitlab-org/gl-openshift/gitlab-runner-operator)
  • @release

Why

Proactive FedRAMP compliance, so we have fewer Forced Prioritization issues... forced on us.

Where

The project responsible for performing the scans is https://gitlab.com/gitlab-com/gl-security/appsec/container-scanners. How the scan works and what it consists of isn't really of concern here, but the project has more info.

How

Triggering a scan of a container is straight forward:

curl -X POST --form token="${CONTAINER_SCANNING_PIPELINE_TRIGGER_TOKEN}" \
    --form ref=master  \
    --form "variables[IMAGES]= ${BUILD_IMAGE}" \
    https://gitlab.com/api/v4/projects/16505542/trigger/pipeline

And is done here in gitlab-runner OR as described here. For this issue, we want to add more images to the gitlab-runner project to trigger a scan, and similar machinery in the gitlab-runner-ubi-images and gitlab-runner-operator projects (at least)