amazon: improve version constraint construction for ALASKERNEL-x.x-* advisories to reduce false positive matches

[westonsteimel]

What happened:

Amazon linux advisories like ALASKERNEL-5.10-2022-005 should only apply to that specific kernel series (5.10.x), because they create an advisory per kernel line in these cases:

So ALASKERNEL-5.10-2022-005 patches CVE-2021-3753 which shows:

Right now since we construct the affected version constraint as < 5.10.62-55.141.amzn2 for ALASKERNEL-5.10-2022-005, it means that even a 4.x series kernel with the patch from ALAS-2021-1704 or a 5.4 series kernel with the patch from ALASKERNEL-5.4-2022-007. In fact, it's even worse for a 4.x kernel since it'll potentially report all 3. After looking at the data I think it should be correct to build a version constraint something like >= 5.10, < 5.10.62-55.141.amzn2 for these cases. This should lead to correctly interpreted results for these cases.

There are some other instances where AWS issues multiple advisories across several lines of a product; however, in all of the other cases the package has a distinct name so shouldn't require this workaround, but the kernel packages do not have this property.

What you expected to happen:

Only ALAS-2021-1704 should be reported for a vulnerable 4.x kernel line, and only ALASKERNEL-5.4-2022-007 should be reported for a vulnerable 5.4.x kernel line.

How to reproduce it (as minimally and precisely as possible):

dcoker run --rm anchore/grype:v0.65.2 docker.io/anchore/test_images:vulnerabilities-amazonlinux-2-5c26ce9@sha256:cf742eca189b02902a0a7926ac3fbb423e799937bf4358b0d2acc6cc36ab82aa

Anything else we need to know?:

Environment:

• Output of vunnel version:
• OS (e.g: cat /etc/os-release or similar):

[westonsteimel]

Hmm, actually since the vunnel schema only outputs when a fix happened, I don't think this can be handled here but might need to be deferred to grype-db

[westonsteimel]

Or should it be an enhancement to the OS vulnerability schema to add in an optional LowerBound property to the FixedIn entry or something like that? Of course that then would still then require changes to grype-db to construct the correct constraint given the new schema

[westonsteimel]

After discussion on this, we've decided to just make a workaround in grype-db to handle building the expected constraint for these specific cases. In the future we'd like to overhaul the vunnel schemas so that vunnel emits the actual constraints rather than fixed-in entries

[westonsteimel]

I created #266 to start tracking what we might want to consider when designing future vunnel major version schemas