feat: build config can specify package CPE

[luhring]

This draft PR is trying out an idea where a package's build config could specify its own CPE values. Today our scanning system maintains its own list of known CPEs for packages with certain names. But perhaps it's better if each package is capable of defining the correct CPE on its own (if it has a CPE), which would remove the need for us to keep a central list up to date.

Improving CPE identification for packages will help us find CVEs for packages better (specifically, by improving recall) because it's not always possible to derive the correct CPE just from the package's other metadata.

Example of how this might look for cosign, for example:

package:
  name: cosign
  version: 2.4.1
  epoch: 5
  description: Container Signing
  cpe:
    vendor: sigstore
    product: cosign
  copyright:
    - license: Apache-2.0
  dependencies:
    runtime:
      - ca-certificates-bundle
# ...

We could add other CPE fields over time as we find the need.

Should we use this CPE information in the package's SBOM as well? Probably. Although there's an argument to be made that finding this data in the built package's .melange.yaml is easier (and perhaps less likely to change shapes in the future) than finding it in the /var/lib/db/sbom/... location.

[imjasonh]

Is there more we might want to be able to fill out? I never remember CPE semantics, but I think it's also got version range info, and we have version info. Can we use it in any way?

[luhring]

Yeah definitely. It can do versions (not ranges), so we can plug in the .Package.Version field from the Configuration struct. Nothing's calling this String() method yet, but if someone does, they'd get the benefit of that.

Same goes for other fields. We could add them all now, if we want. I was curious if it'd be better to wait and see which we end up needing (I'd bet money we don't need them all), but no opinion here.

[xnox]

Arch & os helps.

As in x86_64 & Linux. Do not want windows-only CVEs and similar.

[luhring]

I'm not against adding those two, but I will say:

1. I almost never see those set on CVE records. I'm not sure people know how to use them. And for OS, more often I see the CVE record using boolean groups of multiple CPEs, rather than trying to convey the OS in a single CPE.
2. From the perspective of scanning, which is the big motivation here, by the time we're looking at a package, we already know the architecture and that it's Linux, so we don't really need the package itself to tell us that.

[luhring]

Added to .PKGINFO:

$ tar -xOf ./packages/aarch64/cosign-2.4.1-r5.apk .PKGINFO
# Generated by melange
pkgname = cosign
pkgver = 2.4.1-r5
arch = aarch64
size = 84551068
origin = cosign
pkgdesc = Container Signing
url = 
commit = 54fac0d402f48b3e3ae8ed08fa0be0bea9d5923a
builddate = 1737155808
license = Apache-2.0
depend = ca-certificates-bundle
provides = cmd:cosign=2.4.1-r5
# cpe = cpe:2.3:*:sigstore:cosign:2.4.1:*:*:*:*:*:*:*
datahash = 5fe105545021b762f52f908592194cbf9dea87f4e724010282738b24f6100630

[luhring]

Some "devil's advocate" thoughts are occurring to me about this whole approach:

1. Is it really better to divide up the mechanism for scanning accuracy across a bunch of files across multiple repos, rather than one central spot (e.g. in wolfictl)?
2. Doesn't having one central spot allow us to apply broader transformations, using things like strings.HasPrefix to codify entire patterns of CPEs?
3. Could it be more error-prone to push this repsonsibility onto individual package files? For example, what if a new version stream of something (e.g. corretto) forgets to add the proper CPE data?
4. What if we want to change a CPE across multiple files or even repos? Isn't that harder to do if it's not in one spot like in wolfictl?

Sanity checking welcome! 😅