Provide min_score and max_score values in the Package API endpoint

[tdruez]

A "range string" is not an actional data point, it's not conveniant to be used for sorting, filtering, etc...
A better data in the API would be the min_score and max_score, as the range string can easily be computed from those 2.
We want to make sure this is available in the bulk_search as well.

[tdruez]

@TG1999 @keshav-space could you provide some feedback in the implementation of this one?

[pombredanne]

Here are a few thoughts on this issue:

• For now, scores are not at the package level but at the "Package Vulnerability" level with some evolving relationship to Reference
• But even this model is not entirely correct and it will evolve because a score is really something at the Package -> Advisory level, but have not these changes done yet,
• We are working on a new API that is centered package, and separating vulnerabilities in a separate list

You can see more details in these:

• Incorrect severity score due to identical Reference URLs #1597
• Segregate PackageRelatedVulnerability model to new models #1612
• Add V2 API endpoints #1631

With all this said, this issue is not easy to handle.
See for instance https://public.vulnerablecode.io/api/packages?purl=pkg:openssl/[email protected]

{
    "count": 1,
    "next": null,
    "previous": null,
    "results": [
        {
            "url": "http://public.vulnerablecode.io/api/packages/106428",
            "purl": "pkg:openssl/[email protected]",
            "type": "openssl",
            "namespace": "",
            "name": "openssl",
            "version": "1.1.1m",
            "qualifiers": {},
            "subpath": "",
            "is_vulnerable": true,
            "next_non_vulnerable_version": "1.1.1q",
            "latest_non_vulnerable_version": "3.0.7",
            "affected_by_vulnerabilities": [
                {
                    "url": "http://public.vulnerablecode.io/api/vulnerabilities/198463",
                    "vulnerability_id": "VCID-5khv-27u8-aaaa",
                    "summary": "",
                    "references": [
                        {
                            "reference_url": "https://access.redhat.com/hydra/rest/securitydata/cve/CVE-2022-2097.json",
                            "reference_id": "",
                            "reference_type": "",
                            "scores": [
                                {
                                    "value": "5.3",
                                    "scoring_system": "cvssv3",
                                    "scoring_elements": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N"
                                }
                            ],
                            "url": "https://access.redhat.com/hydra/rest/securitydata/cve/CVE-2022-2097.json"
                        },
                        {
                            "reference_url": "https://api.first.org/data/v1/epss?cve=CVE-2022-2097",
                            "reference_id": "",
                            "reference_type": "",
                            "scores": [
                                {
                                    "value": "0.00598",
                                    "scoring_system": "epss",
                                    "scoring_elements": "0.78810",
                                    "published_at": "2024-10-28T00:00:00Z"
                                }
                            ],
                            "url": "https://api.first.org/data/v1/epss?cve=CVE-2022-2097"
                        },
                        {
                            "reference_url": "https://cert-portal.siemens.com/productcert/pdf/ssa-332410.pdf",
                            "reference_id": "",
                            "reference_type": "",
                            "scores": [
                                {
                                    "value": "9.1",
                                    "scoring_system": "cvssv3.1",
                                    "scoring_elements": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N"
                                },
                                {
                                    "value": "CRITICAL",
                                    "scoring_system": "generic_textual",
                                    "scoring_elements": ""
                                }
                            ],
                            "url": "https://cert-portal.siemens.com/productcert/pdf/ssa-332410.pdf"
                        },
                        {
                            "reference_url": "https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-2097",
                            "reference_id": "",
                            "reference_type": "",
                            "scores": [],
                            "url": "https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-2097"
                        },
                        {
...

There you can see how the structures is driven from references. Furthermore, with the scores like EPSS, we cannot/do not have anymore a normalized value range: EPSS is a float "0.00598" and I cannot find a way to compare that in a range with a CVSS of 9.1

I do not think going forward that a scores range make sense anymore. Instead we should discuss how to handle each scoring system separately, and eventually in the future we will likely have very scores of the same system for a given PURL, since we will bring this down at the Advisory-Package level

We should in all case also wait for the updated API endpoint merge that is in #1631

An important question: is this in the context of CRAVEX? Let's try to find a way to integrate the score data the best for this, and expose the correct API, but in earnest min/max scores feels like a dead end.

[tdruez]

I do not think going forward that a scores range make sense anymore.

I agree, this does not make much sense: