Support rebuild when package upgrades are available

[mthalman]

Often times a Dockerfile will install additional packages. When new versions of those packages are made available from the distro repository, it's necessary to rebuild the Dockerfile to get the packages upgraded. This action should support such a scenario so that it can automatically trigger a rebuild.

[mthalman]

Implementation Notes

• Provide an option to only trigger action when vulnerabilities of a given severity are reported
• How to detect whether package is being installed by my Dockerfile versus from the base image:
  1. Run package detection on the base image.
  2. Run package detection on the target image.
  3. Subtract the packages of step 1 from the packages of step 2. These are the packages installed by my Dockerfile.

[mthalman]

The big issue to solve here is how do you actually know whether an updated package is available given the configuration of how the Dockerfile is installing the package? Let's say a Dockerfile is configured to install a package from some repository and a vulnerability is detected for that package version. Nothing guarantees that the repository has the non-vulnerable version of that package. Let's say it doesn't. When the vulnerable package is detected, it will trigger the workflow to run to rebuild the image. The image gets rebuilt with the same package version because it has the latest available from the repository but is the vulnerable version. So this loop will keep repeating.

To avoid this, there needs to be logic run on the container itself to determine if an updated version of the package is available and not trigger the workflow if an updated version is not available. But this presumes a few things:

• the final stage of the image is in a state where all the necessary repositories are configured
• a shell is available in the container (not necessarily true for distroless containers)

In the majority of cases, these two assertions will be true so the default logic could rely on that. For other cases, perhaps there needs to be an extension point such as providing a container image name that could invoked to provide custom logic. That could also be useful in cases where a package manager is being used that isn't explicitly supported by the action.