Data quality issue with CVE-2024-3094

[katzj]

The CVE ID
https://osv.dev/vulnerability/ALPINE-CVE-2024-3094

Describe the data quality issue observed
introducedAt is 0 which isn't the case for this. It looks like this is true for all alpine ingested CVEs as introducedAt isn't set in the alpine converter

Suggested changes to record
Appropriate introducedAt fields

Additional context
Note that the Alpine security tracker (https://security.alpinelinux.org/vuln/CVE-2024-3094) has correct info here but it is combining info from secdb and NVD in a richer way than is currently done with the OSV importer

[github-actions]

✨ Thank you for your interest in OSV.dev's data quality! ✨

Please review our FAQ entry on how to most efficiently have this addressed.

[katzj]

I think this could be fixed in a pretty straight forward manner by updating the alpine converter to work more similarly to the alpine upstream security tracker.

When looping through, we already have access to the CVE object from NVD and could parse things from CPEs within. There's some CPE matching logic to handle the way alpine packages are named (https://gitlab.alpinelinux.org/alpine/security/secfixes-tracker/-/blob/master/secfixes_tracker/importers.py?ref_type=heads#L28) but that isn't hard to handle and have here as well.

Happy to contribute if there's agreement that this is a good path to help with this class of issue.

[cuixq]

@another-rex @jess-lowe could you help to answer this question?

[cuixq]

Hi @katzj we are aware of the issues we have regarding CVE conversion and currently working on that. We will keep you updated here. Thank you for your patience!

[katzj]

@cuixq I'm happy to help and contribute if yall provide signal of what you're thinking. The current situation makes osv basically unusable for alpine vulnerability mapping.

[another-rex]

Apologies for the delay. I believe we use the APKBUILD files to extract what versions are affected, and they generally only specify the "fix" version, and not the introduced version: e.g. https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/main/xz/APKBUILD

The security tracker has an introduced version (I believe extracted from the CVE's CPEs), but we have no clear way to link it directly, and I don't think there's a guarantee that it matches the wrapping alpine package's versioning scheme. If you look at the "fixed" packages they only really list the fixed version, no introduced version on the security tracker either.

Even the underlying CPE is actually somewhat ambiguous. While nvd states 2 vulnerable CPEs, 5.6.0 and 5.6.1, it's actually hard to differentiate this between "up to 5.6.1" and just "5.6.1 and 5.6.0", as nvd have used both methods to identify vulnerable versions.

If you have any ideas that can improve this please share :D

[katzj]

The introduced version is being extracted from the CPEs and they seem to link up fine from some spot checking and using the logic in their tracker and reading from the NVD data that is already being ingested by OSV. And worst case, doing the same things means that OSV is consistent with alpine's own tracker!

[katzj]

@another-rex something like https://gist.github.com/katzj/f842b2e6a4b51afd83f9888b56bd0af8 seems like it should help and basically replicates the logic from alpine tracker. If you agree, I can rebase it, add tests, etc... this was just my early stab from when I was looking at this two months ago. Without something along these lines, OSV is basically just noise for alpine.

[another-rex]

@katzj Happy to take this as a patch!

I'm still not too sure that's technically correct as I think the CPE is describing the upstream version while we are on the alpine version. But I think practically I agree with you that without this information it might just be too much noise, and something's better than nothing.

[katzj]

👍 Got everything working and realized I don't think Sonar has signed a CLA so kicked off that process internally. I'll open the PR once that's done