Yesterday I posted about Promoting Container Images from Quarantine Using GitHub Actions describing a simple way to do a Trivy vulnerability scan and promote the image if it passes the vulnerability threshold. However, the problem with that workflow was that it was too monolithic. While the monolithic workflow does the work, I wanted to have a “library” of smaller actions that I can reuse in various container supply chain workflows. Therefore, I decided to redesign both the “acquire/mirror” and the “promote from quarantine” workflows.
Looking deeper and deconstructing both workflows shows the following steps for each:
- “acquire/mirror” workflow
- Step 1: Login to source registry
- Step 2: Login to the destination registry
- Step 3: Mirror (or copy) the image
- “promote from quarantine” workflow
- Step 1: Login to the registry (in this case is the same registry but it can be two separate registries)
- Step 2: Enumerate the quarantine tags
- Step 3: For each enumerated tag
- Step 3.1: Scan the image
- Step 3.2: Evaluate the results AND IF passing the threshold
- Step 3.3: Promote the image – which is exactly the same as mirror (or copy) the image
- Step 3.4: Attach vulnerability report (or any other attestation)
- Step 3.5: Delete the image from the quarantine repository
Steps 1 and 2 from the first workflow and step 1 from the second workflow are exactly the same – login to a registry. They can be parameterized and reused. The same is true for step 3 in the first workflow and step 3.3 in the second.
With all this in mind, I worked with Copilot to create the following reusable actions that I can use in my workflows:
- Registry login action
- Mirror image action
- Enumerate tags action
- Scan image action (I also created a Scan SBOM action)
- Attach scan report action
- Evaluate findings action (this is very specific to the CVE findings)
- Delete image action
Now, I can reuse the above actions in any workflow that I want. For my current two workflows, “acquire/mirror” and “promote from quarantine” the re-usability is only for the “registry login” and the “mirror image” actions but you will see how in the future those will come handy.
Also, there is a lot of resemblance with my work on the Custos supply chain security workflow platform. For example, the “registry login” action in GitHub is modeled as a connector in Custos while the “mirror image” action is modeled as an action in Custos.
Next time I will write about something that almost every enterprise customer I talked with experiences – acquiring brand new images with vulnerabilities and I will show how they handle the issue currently. I will also talk about the challenges with images from public sources like Docker Hub. In the future, I will show a better approach to source images and how to handle them.