Add data-driven approach to v6 distro search

[wagoodman]

Today we have a few hard coded elements that affect which namespace is selected for given distro information:

• debian unstable: look for indications of sid in the pretty-name then explicitly set the version to unstable which is acted upon downstream to map to sid vulnerability data
• rolling versions: manually list which distros via code that should match against a single vulnerability stream, regardless of the version.
• special versions: in alpine processing, we map alpha versions to a specially named edge vulnerability stream manually
• major vs major.minor versions: we search multiple combinations of version segment combinations to find the most accurate vulnerability stream

The upside of this logic is that it makes matching more accurate, the downside is that this kind of code requires a grype release to update (thus users need to update grype itself to get these updates). This is not ideal since a distro-related version change or vulnerability data change can happen at any time.

Ideally this should be fundamentally data driven and flow in from the grype database, which is updated nightly -- this PR nudges us heavily in that direction by migrating this kind of logic to a DB lookup table, which is populated with grype-db, and paired with more agnostic processing of distro data (for example, we still have version specificity searching, but it is unaware of specific ).

Open questions:

• debian@sid: today we look for "sid" in the PRETTY_NAME for os-release, which is something that is fixed to the artifact, but as I understand it sid is a moving target... so wouldn't it be invalid to match non-trixie sid vuln data (foxy is the next codename) with trixie artifacts? Doesn't that mean we should exclusively look at the codename and ignore sid status altogether? We're going to need to appropriate pkg source lists into syft / grype / grype-db / vunnel. That is outside of the scope of this PR
• alpine@edge: it looks like this would be a single version with multiple pre-releases, but the vunnel data is specifically hard coding this to "edge", is this fictitious? (should we just use versions as we find them in the vuln data) this is correct, we should be using the alpha versions to correlate with edge, no matter the major/minor version
• should this logic be lifted from the DB into memory for faster continual access of OS specific questions? That is, much of this is querying the OS table for each distro search, but that table is relatively small and could be replaced with a single datastructure that is read into memory upon the first query. deferred; I don't want to optimize too much in advance though, so elected to not do this first since it could always be done at a later date since that could be implemented in a non-breaking way.

[kzantow]

To offer opinions:

debian@sid: today we look for "sid" in the PRETTY_NAME for os-release, which is something that is fixed to the artifact, but as I understand it sid is a moving target... so wouldn't it be invalid to match non-trixie sid vuln data (foxy is the next codename) with trixie artifacts? Doesn't that mean we should exclusively look at the codename and ignore sid status altogether?

I was under the impression that there is no vuln data for old unstable versions -- that the unstable feed is only for the current unstable branch, is this correct? Do we know which codename (probably mixing up terms here) is currently in unstable at any given point? If so, I think considering something with an old codename + sid status as a prerelease for that codename would be the right thing to do, if we have enough info to do so.

alpine@edge: it looks like this would be a single version with multiple pre-releases, but the vunnel data is specifically hard coding this to "edge", is this fictitious? (should we just use versions as we find them in the vuln data)

IIRC there was a difficulty mapping the unstable alpine feed without this behavior. Maybe just that the data for the distro isn't published in the normal feed until the release becomes stable? But if the versions align without doing some mapping to "edge", I would agree it sounds better to just use the version name directly.

should this logic be lifted from the DB into memory for faster continual access of OS specific questions? That is, much of this is querying the OS table for each distro search, but that table is relatively small and could be replaced with a single datastructure that is read into memory upon the first query. I don't want to optimize too much in advance though, so elected to not do this first since it could always be done at a later date since that could be implemented in a non-breaking way.

Probably, yes. Agree it doesn't have to be done here -- only optimize things that need it. I worked on a configuration-heavy app that did something like this: always keep configuration loaded in memory and it worked great. If nothing else, it kept a lot of the programming model easier.

[wagoodman]

It looks like there are a couple of answers here:

• debian sid will be dealt with later as we'll need to add another enhancement: searching by source list. This is out of scope for this PR and will be added at a later time
• I've confirmed that alpine edge processing is simply looking for alpha in the version

[westonsteimel]

So what happens here when we do add affected entries for a distro that was previous an alias (like when we bring in data for almalinux)? I think what would happen is that the alias would no longer exist in the grype db that is published that now contains the almalinux data, but just want to validate that assumption.

[westonsteimel]

And all prior clients would adjust correctly to it becoming a comprehensive vulnerability dataset rather than an alias to rhel data