Expand on criteria for affected packages

[sophiewigmore]

Context

paketo-buildpacks/full-stack-release#173 is the latest instance of a package in our Stacks containing a CVE but not getting patched when the USN is discovered in the Stacks USNS repository.

In this example USN-5260-2 has a package called samba listed as the affected package on the Ubuntu Security page, with libwbclient0 (a package we do have in our Stacks) is only mentioned in the Related Notices section. However, diving in deeper to associated links, it becomes apparent that libwbclient0 is associated with the samba version and is affected too.

This was picked up by the OP in the linked issue via a Trivy scan.
This dependency was ultimately patched by the "Build and Test Stack" workflow separately from the USN.

Issue

We should look into ways we can possibly improve our actions for determining all of the affected packages beyond the (often) single item listed on the Ubuntu Security page we check now.

Although this dependency bump was caught by our other automation, this would still be beneficial in an effort to be as safe as possible when working with CVEs/USNs, as well as being able to track dependency bumps associated with USNs more closely.

In paketo-buildpacks/full-stack-release#173 @nicholascelestin provided the following suggestions:

One approach could be to auto-patch all packages whenever a USN happens, rather than having the USN tell you which packages to patch. Perhaps using something like this as a reference: https://packages.ubuntu.com/bionic/allpackages?format=txt.gz.

A different angle would be to incorporate vulnerability scanning into the automation process. For every USN / PR / etc you could build an image and scan it with Trivy. Failures could result in the creation of GitHub issues, the rejection of PRs, etc.