feat: populate package architecture for matching

[willmurphyscode]

Enable matchers to filter on architecture-specific vulnerabilities or fixes.

There are basically three changes here: First, wire up the package collection creator to populate architecture on the packages when an image is scanned or an sbom is loaded in Grype. Second, wire up the architecture package qualifier so that if a vulnerability or fix specifies that it is only applicable to a particular architecture, the matchers will respect this, and third, in the RPM matcher, specify arch=src when synthesizing the upstream package to search by (rather than letting it inherit the binary package's architecture).

The qualifier logic is like this: If either the package or the DB record has a blank architecture, the filtering is a noop. If the package has a specific architecture and the DB record has 'src', the package is qualified, because a disclosure or fix in a src RPM for example is assumed to affect things built from it. If the DB record and the package both have specific binary architectures, but they don't match, e.g. x86_64 != aarch64, the package is not qualified and filters out. Architecture qualifiers are canonicalized at match time so, for example, an RPM that has x86_64 architecture is a qualified package on a vuln that affects "amd64" processors (assuming distro and everything else line up). This canonicalization is probably more important for future expansion since a given distro will probably use the same architecture strings as their own package manager.

Hummingbird also has a special "binary-no-arch-specified" architecture that means, "this is not a src RPM". That is so that in Hummingbird data, if we have a package that says, 'upstream=glibc' in its PURL, and we have a glibc vuln against the binary but not the src RPM, we can fitler out this false positive. If a DB record has 'binary-no-arch-specified' as its architecture, any package that has any non-src architecture (or a blank architecture) is qualified, but src architecture is not.

Note that this could use anchore/syft#4977 but there's no need to couple them.

[willmurphyscode]

From @wagoodman this should be added to types where it matters as well, like

grype/grype/pkg/rpm_metadata.go

Line 3 in f54a905

type RpmMetadata struct {

explicitly instead of https://github.com/anchore/syft/pull/4977/changes which is messy because Syft packages don't have necessarily exactly one architecture (e.g. macho binaries).

[willmurphyscode]

Additionally, we should set this in metadata things: https://github.com/anchore/grype/blob/main/grype/pkg/apk_metadata.go#L12 for example written to here (and analogous changes for the RPM stuff.)

We might not need a PURL enhancer if we do it that way.

[willmurphyscode]

Might be worth setting arch in here: https://github.com/anchore/syft/blob/main/syft/format/internal/backfill.go#L37 - otherwise we do need the enhancer in grype.

[willmurphyscode]

Does "all" : "noarch" belong in here?

[willmurphyscode]

I thought this helper was used only in hummingbird. Why the alma diff?

[willmurphyscode]

Clean up this comment as this is now done in the helper.

[willmurphyscode]

This already shipped as a string, but maybe missed opportunity to do a Set[string] so that we could check "intersection of package arch with vuln arch is not empty" instead of equality.

[willmurphyscode]

What about like arm64/v8? That's a thing that can be passed to --platform on docker CLI for example.

Also "architecture" and "platform" are not exactly this same thing and this conflates them?

[willmurphyscode]

Is this complete? Do we need an "is platform independent" bool column or something? Right now the source code knows that noarch and all mean "this thing applies across all architectures" but the database doesn't?

We think that this case be added later if need be, and that it is probably not necessary.

[wagoodman]

This overrides any architectures that could be explicitly provided. I see that this is intentional, but does this consider that there might be instances where the vuln data is more specific than src? (say with hummingbird) .... there is a good chance this is a non-issue

[wagoodman]

Well actually, doesn't oracle provider per-binary-per-arch NERVA's?

[willmurphyscode]

So the idea here is that the upstream package is always a source RPM. This actually fixes false positives in Hummingbird and is an intentional and necessary part of this PR.

Consider this scan:

syft -q -o json quay.io/hummingbird/postgresql:latest@sha256:6eefb14bced346a8583011f84dd71de8249af74c060369be6ad73891b2a768f0 | jq '.artifacts[] | .purl' | rg glibc

which produces:

"pkg:rpm/redhat/glibc@2.42-10.1.hum1?arch=aarch64&distro=hummingbird-20251124&upstream=glibc-2.42-10.1.hum1.src.rpm"
"pkg:rpm/redhat/glibc-common@2.42-10.1.hum1?arch=aarch64&distro=hummingbird-20251124&upstream=glibc-2.42-10.1.hum1.src.rpm"
"pkg:rpm/redhat/glibc-langpack-en@2.42-10.1.hum1?arch=aarch64&distro=hummingbird-20251124&upstream=glibc-2.42-10.1.hum1.src.rpm"

And this CSAF VEX:

      "product_status": {
        "fixed": [
          "hummingbird-1:glibc-0:2.42-12.hum1", // binary rpm
          "hummingbird-1:glibc-0:2.42-12.hum1.src", // src rpm, removed intentionally in datat processing
         ...

In this case, glibc-langpack-en has the upstream glibc, and the binary glibc is vulnerable. However, before this change, glibc-langpack-en could be reported as vulnerable because its upstream has the same name as a vulnerable binary. However, that would be considered an FP. This is a change to allow us to consider upstream matching still, but only if the upstream package is a src rpm, so that marking a binary rpm that has the same name as a bunch of source rpm's upstream (like glibc) doesn't produce a wave of FPs.

[willmurphyscode]

Well actually, doesn't oracle provider per-binary-per-arch NERVA's?

I don't think anyone has architecture on their src RPMs, and upstream will always be a src rpm? But I confess I don't completely understand the comment.

[willmurphyscode]

@wagoodman I don't think this matters on oracle. the OVAL files seem to list every binary RPM anyway, and I don't think the notion of a non src upstream makes sense. This only sets arch on upstreams.

[wagoodman]

just want to state clearly but this isn't a comment to address, but instead a specific feature designed in: the DB is authoritative over clients, so newer clients that have old DBs might run into issues, but in these cases we expect folks to update their dbs. This is a nice feature of using the DB since DBs ship nightly instead of needing to upgrade the client.

[wagoodman]

nit, this could have omitempty