search

trustification / trustify

Apache License 2.0
10 stars 19 forks source link

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

Open carlosthe19916 opened 3 months ago

carlosthe19916 commented 3 months ago

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

Context:

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:

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 commented 3 months ago

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.

bobmcwhirter commented 2 months ago

Recent changes to the CVE ingestioning may help determine affected SBOMs, even with RHT CSAF files.

jcrossley3 commented 2 months ago

It may be useful to error on the side of returning potential false positives, to at least alert the user to the possibility of the packages being affected. This would be a signal to enable the importers relevant to their SBOM's rather than just the CVE's.

But when you consider in this particular example that the affected package name is vague, it prompts the question of which "netty" packages we should return as "possibly affected"? There are lots of packages with "netty" in their name, and relatively few named "netty", e.g.

Should we return all of them with "netty" in the name or some subset? By what rule[s]?