feat: Adding alternative vulnerability data sources

[anthonyharrison]

Description

There are now multiple data sources of vulnerabilities which can be used to assess components. Supporting more may provide more accurate reporting of vulnerabilities.

Why?

With the issues which the NVD is experiencing alternative sources of vulnerability information are now being used across industry.

Suggest supporting the data from CVE.org which contains CVE records in JSON format and includes additional information such as CVSS V4 scores and PURL records (will be supported from schema version 5.1).

Anything else?

Other potential sources to consider are:

• Alpine (https://secdb.alpinelinux.org/)
• Amazon (https://alas.aws.amazon.com/AL2/alas.rss & https://alas.aws.amazon.com/AL2022/alas.rss)
• Debian (https://security-tracker.debian.org/tracker/data/json)
• GitHub Security Advisories (https://api.github.com/graphql)
• Oracle (https://linux.oracle.com/security/oval)
• SLES (https://ftp.suse.com/pub/projects/security/oval)
• Ubuntu (https://launchpad.net/ubuntu-cve-tracker)
• Wolfi (https://packages.wolfi.dev/)

[jloehel]

I like the idea enhancing the db with the information from cve.org. Some CVEs from 2024 in the NVD have no CPEs but the affected infos are available through cve.org.

[jloehel]

@terriko I would like to hear your opinion about something like this (CVE-2025-0108):

{'changes': [{'at': '11.1.6-h1', 'status': 'unaffected'},
             {'at': '11.1.2-h18', 'status': 'unaffected'}],
 'lessThan': '11.1.6-h1',
 'status': 'affected',
 'version': '11.1.0',
 'versionType': 'custom'}

I guess it would be necessary to split this into to ranges, right?

• vers:generic/>=11.1.0|<11.1.2-h18
• vers:generic/>11.1.2-h18|<11.1.6-h1

The "!=" constraint would be not possible here because the database scheme does not support it right now. Maybe otherwise I would write it like this:

• vers:generic/>=11.1.0|<11.1.6-h1|!=11.1.2-h18|!=11.1.6-h1

To identify these edge cases it would be necessary to check if an unaffected version is in a specified range. This depends heavily on version comparison. I guess the version comparison issue needs to get tackled before, right? The parsing with the not constraint is much easier and straight forward. It is not very clear for me why changes includes 11.1.6-h1 because lessThan means already that 11.1.6-h1 is not included but I have seen that a lot in the dataset of cve.org.

[terriko]

There's no particular reason we couldn't have a != option in the database, the only reason we don't is that it wasn't an option in the jsonschema used by NVD when we started this project.