Are SBOM affected statuses determined only based on the CSAF files?

[carlosthe19916]

Hi guys, this is not to report a bug but more a way of asking a question.

Context:

• I upload the sbom quarkus-bom-3.2.11.Final-redhat-00001.json
• Then I Upload the Red Hat Advisory rhsa-2024-2705.json

As a result if I hit GET /api/v1/vulnerability/CVE-2024-29025 then I get a response that indicates that my sbom quarkus-bom-3.2.11.Final-redhat-00001.json has a status not_affected and also a set of purls that indicate which are the packages fixed | not_affected. Everything good here.

Question:

• I upload the sbom [quarkus-bom-3.2.11.Final-redhat-00001.json](https://github.com/user-
• Then, rather than uploading the red hat CSAF file, i upload the CVE advisory file from https://github.com/CVEProject/cvelistV5/blob/main/cves/2024/29xxx/CVE-2024-29025.json

Finally I hit GET /api/v1/vulnerability/CVE-2024-29025 then I get the following response:

{
    "normative": true,
    "identifier": "CVE-2024-29025",
    "title": "Netty HttpPostRequestDecoder can OOM",
    "description": "Netty is an asynchronous event-driven network application framework for rapid development of maintainable high performance protocol servers & clients. The `HttpPostRequestDecoder` can be tricked to accumulate data. While the decoder can store items on the disk if configured so, there are no limits to the number of fields the form can have, an attacher can send a chunked post consisting of many small fields that will be accumulated in the `bodyListHttpData` list. The decoder cumulates bytes in the `undecodedChunk` buffer until it can decode a field, this field can cumulate data without limits. This vulnerability is fixed in 4.1.108.Final.",
    "published": "2024-03-25T20:09:35.156Z",
    "modified": "2024-08-02T01:03:51.668Z",
    "cwe": "CWE-770",
    "advisories": [
        {
            "uuid": "urn:uuid:380d8884-34dd-49fd-ab72-6d542c311811",
            "identifier": "CVE-2024-29025",
            "hashes": [
                "sha256:0eeff878f4aac32eda2433723aaf2a5e4be8b40e5b2fd0424f48713838e1425e",
                "sha384:89d8687316504fa41638cbb2546a583005bd8ea6a34b336a8fceab655d3c59c51eeee17746786a9c7fe5cdae0c9357ac",
                "sha512:f825b1f3560043924ca06ded08025b65adee01db4691fe3214c1308e94a214b1b8fa5e2f7ab1fac9c4c8e358d61791adbc7b46ebd97934f13013e855fe66c867"
            ],
            "issuer": {
                "id": "b2e53d5f-8371-47a1-b320-a5e0b0054f72",
                "name": "GitHub_M"
            },
            "published": "2024-03-25T20:09:35.156Z",
            "modified": "2024-08-02T01:03:51.668Z",
            "title": "Netty HttpPostRequestDecoder can OOM",
            "labels": {
                "type": "cve"
            },
            "cvss3_scores": [],
            "purls": {},
            "sboms": []
        }
    ]
}

The previous response indicates that there are zero sboms affected by the vulnerability.

Here is the question, is the importing of red hat csaf files the only way of determining sbom statuses and package statuses? If I import my company sboms and then only import all the advisories from the CVE project, is it expected to have some sboms with statuses (affected, not affected, etc)?

I am asking because in my mind, an external company would not decide to import the red hat csaf files and for me, personally, it should be enough (even if not perfect) to import advisories from the CVE project or other open sources not strongly related to red hat advisories. WDYT guys?

[bobmcwhirter]

The CVE will generally be very low value, and perhaps no include actual pURLs or CPEs, so difficult to link to thinks.

One step better would be the Netty project producing GHSAs or OSVs that give more/better details.

The RHT CSAF files purely give statuses within the context of the Red Hat product catalog.

So, ingesting a CSAF from Red Hat will tell you nothing of import about netty if you're using it in a vanilla Spring app or such.

The user will need to ingest advisories relevant to their usage. If they use Quarkus, then our CSAFs. If they use something else, then they need some other advisories.

And generally, CVEs aren't the final answer, just a starting point that other people build advisories from.