A few days ago, I posted about Mirroring Container Images from Public Registries Using GitHub Actions, which is one of the first thing you need to think about when securing the supply chain for containers and cloud-native artifacts. The next step is to validate those artifacts before promoting them for internal use. As explained in that post, this is normally done in a quarantine registry or repository. Typical validation enterprises do is a vulnerability scan before promotion to a designated “golden” images registry.

Over the weekend, I went ahead and implemented a simple validation action using Trivy. What the action does is quite simple:

• It runs on schedule once a day.
• It scans the image in the quarantine repository using the Trivy scanner.
• If the vulnerabilities found in the image are below the pre-defined threshold, the action copies the image from the quarantine repository to the “golden” repository and deletes it from the quarantine repository.

The action is configurable. You can configure the vulnerabilities severity threshold – HIGH is set as default; pipe-separated list of CVE exceptions; and an option to do a dry-run. Note that the action only promotes the image if it meets the criteria for vulnerability severity or if the CVE is in the exception list.

The full workflow looks like this right now:

As you can see from the diagram, some of the steps can be reusable, i.e. the Copy Step is reusable between the acquisition flow and the validation/promotion flow. Unfortunately the GitHub action is a bit more monolithic than that – it has separate steps for enumerating the quarantine tags, scanning each tag, deciding whether it should be promoted, doing the actual promotion, attaching the vulnerability report, and finally deleting the promoted images from the quarantine repository.

Here are the permalinks to the current implementations of both:

• the acquire/mirror container image GitHub action (and its Python instance)
• and the validate/scan and promote container image GitHub action (and its Python instance)

My next step would be to refactor this GitHub workflow to break it into reusable components that can be plugged in different workflows.