VEX Autodiscovery!

[puerco]

This PR adds autodiscovery capabilities to the VEX processor when scanning container images.

The discovery feature is disabled by default, this PR proposes a new --vex-autodiscover flag that starts the autodiscover flow when set.

The whole autodiscover logic is performed by the openvex/discovery module. It looks for OpenVEX attestations attached using the sigstore attestation spec to the container image being scanned. If any are found, they are retrieved from the image registry and any applicable OpenVEX statements are added to the VEX history computation. In other words, any documents found attached to the image are mixed with those specified via the command line with --vex.

This implements most of 3 & 4 of our plan outlined in #1365

At this time we are not performing any signature verification or lookups in other registries.

Signed-off-by: Adolfo Garcia Veytia (puerco) [email protected]

[puerco]

@wagoodman : please let me know what you think about the approach I'm taking. Let's also discuss adding the audit trail to the raw json scan results.

[kzantow]

Hi @puerco, I had a look through this and I think it looks pretty good. Is there a possibility of adding some sort of test for this, though?

[wagoodman]

Existing results:

$ grype ghcr.io/anchore/test-images/vex-oci-attach@sha256:8b95adbdf01ad43043ea9b63d6ac56abbe0e81b67fe40a27c39b6b83488f70ce
b83488f70ce

NAME         INSTALLED            FIXED-IN  TYPE  VULNERABILITY   SEVERITY   
coreutils    9.4-3ubuntu6                   deb   CVE-2016-2781   Low         
gpgv         2.4.4-2ubuntu17                deb   CVE-2022-3219   Low         
libc-bin     2.39-0ubuntu8.2                deb   CVE-2016-20013  Negligible  
libc6        2.39-0ubuntu8.2                deb   CVE-2016-20013  Negligible  
libgcrypt20  1.10.3-2build1                 deb   CVE-2024-2236   Medium      
liblzma5     5.6.1+really5.4.5-1            deb   CVE-2020-22916  Medium      
libssl3t64   3.0.13-0ubuntu3.1              deb   CVE-2024-4741   Low         
libssl3t64   3.0.13-0ubuntu3.1              deb   CVE-2024-4603   Low         
libssl3t64   3.0.13-0ubuntu3.1              deb   CVE-2024-2511   Low         
libsystemd0  255.4-1ubuntu8                 deb   CVE-2023-7008   Low         
libudev1     255.4-1ubuntu8                 deb   CVE-2023-7008   Low

Results with vex applied:

$ grype ghcr.io/anchore/test-images/vex-oci-attach@sha256:8b95adbdf01ad43043ea9b63d6ac56abbe0e81b67fe40a27c39b6b83488f70ce
b83488f70ce  --vex ./vex.json

NAME         INSTALLED            FIXED-IN  TYPE  VULNERABILITY   SEVERITY 
libgcrypt20  1.10.3-2build1                 deb   CVE-2024-2236   Medium    
liblzma5     5.6.1+really5.4.5-1            deb   CVE-2020-22916  Medium    
libssl3t64   3.0.13-0ubuntu3.1              deb   CVE-2024-4741   Low       
libssl3t64   3.0.13-0ubuntu3.1              deb   CVE-2024-4603   Low       
libssl3t64   3.0.13-0ubuntu3.1              deb   CVE-2024-2511   Low

Results with vex autodiscover:

$ grype ghcr.io/anchore/test-images/vex-oci-attach@sha256:8b95adbdf01ad43043ea9b63d6ac56abbe0e81b67fe40a27c39b6b83488f70ce
b83488f70ce  --vex-autodiscover

NAME         INSTALLED            FIXED-IN  TYPE  VULNERABILITY   SEVERITY 
libgcrypt20  1.10.3-2build1                 deb   CVE-2024-2236   Medium    
liblzma5     5.6.1+really5.4.5-1            deb   CVE-2020-22916  Medium    
libssl3t64   3.0.13-0ubuntu3.1              deb   CVE-2024-4741   Low       
libssl3t64   3.0.13-0ubuntu3.1              deb   CVE-2024-4603   Low       
libssl3t64   3.0.13-0ubuntu3.1              deb   CVE-2024-2511   Low

... it appears to be working 🌮 🎉 I'll get an integration test going that uses this image and asserts that the results are non zero and specific CVEs are also not present.

[wagoodman]

I've made a few changes:

• updated the vex processor interface to not require any types in signatures. I see the reason for it: so we can support more than one vex implementation in the future. But one side effect is that there are type assertions being done to get the vex document out that won't scale well. Since the implementation object is responsible for loading the vex documents and using them, I made these documents a side effect on the object and the interface really captured the flow of matches/ignored matches only.
• since we're IO bound on the auto discover, I bumped it to start before vulnerability matching and also allowed for concurrent resolution of each identity independently.
• added a CLI test to show that local vex processing and auto discover work the same way
• added TUI interactions with the vex auto discover, since it may result in real time waiting on responses from registries

What's left: we need a way to persist which vex documents were used somehow into the grype results. From what I can tell, the openvex utilities being used here are a bit of a facade: they are returning results without letting me know where the results came from (a URL). Is there a way to get this information? or a compromise to figure the information without explicitly getting it from the openvex lib?

[puerco]

@wagoodman do you want to keep the source location of the document or just the document ID? I think the results should keep both.

[wagoodman]

Agreed -- if possible both a url and a doc ID would be ideal to keep.

[wagoodman]

@puerco I'd love to get this in, and pushed several changes to the PR, I think there is still only the outstanding question about how to get some information about where the vex docs are pulled from in the final grype document.

[wagoodman]

@puerco friendly nudge

[puerco]

Wuooa sorry @wagoodman I totally forgot about this and just happened to see your ping on my phone.

I'm at KubeCon rn but let me get back to it after this mad week!