Giters

trustification / trustify

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

How to Interpret the Affected SBOMs under the vulnerability endpoint?

carlosthe19916 opened this issue · comments

commented

Not sure this is a bug but surely I'd like to understand how to read it.

The response is:

{
  "normative": true,
  "identifier": "CVE-2024-29025",
  "average_severity": "medium",
  "average_score": 6.5,
  "advisories": [
    {
      "uuid": "urn:uuid:5e478942-39bf-4e86-ad27-c822f439d18b",
      "identifier": "RHSA-2024:2705",
      "hashes": [
        "sha256:7e4ecd24523735ae9c16f59610f024332102e520b02e0fccbd0c799233adaaab",
        "sha384:5b0c196fb94fbaa3fbad5d414d0499dd00dca592956867e104085095812cc56be97ff250d9391d7e8505403a864050dc",
        "sha512:8714a6c1fc1b98f28178e15be61dfb5bcf2ce138de2b7bf118d500b2bd633f5b99b11fda7264ba348934dc87bc1eeb8d7c7c28de6f9b9b67f3227dc4bb7bbed8"
      ],
      "issuer": {
        "id": "3f1fc0de-1351-4c72-86e8-cfedd9c6cf4f",
        "name": "Red Hat Product Security"
      },
      "published": "2024-05-09T11:56:56Z",
      "modified": "2024-05-09T15:30:02Z",
      "title": "Red Hat Security Advisory: Red Hat build of Quarkus 3.2.12 release and security update",
      "labels": {
        "type": "csaf"
      },
      "severity": "medium",
      "score": 6.5,
      "cvss3_scores": [
        "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:L"
      ],
      "purls": {},
      "sboms": [
        {
          "id": "urn:uuid:0191134f-d46c-74a3-8ea8-1e4c0a1712c3",
          "hashes": [
            "sha256:1262c202011b788ac9620a3c67ec6bdfbf0178f8f4f3d858f2edd7c8cb574a28",
            "sha384:84043eaf33ac650ebc5d93f8e2c1f7a2ac30b1d1dfdd4b0ea9e7c4df5bf9fc350132778e16facc8587bbdc8ecc22ba5d",
            "sha512:781cb6fc28509f18044c5cee28fc4284685aba890bab5af4d53d5844dca8700d7dec0149a0c6eebfbe7e04abbaccdee608d9e976ca7f747fc30c6c613ce4f676"
          ],
          "document_id": "https://access.redhat.com/security/data/sbom/spdx/quarkus-bom-3.2.11.Final-redhat-00001",
          "labels": {
            "type": "spdx"
          },
          "name": "quarkus-bom",
          "version": "3.2.11.Final-redhat-00001",
          "status": [
            "not_affected"
          ]
        },
        {
          "id": "urn:uuid:0191134f-d498-72e1-bddf-a50e0efeb88c",
          "hashes": [
            "sha256:89a04684872c82ed56ef46574957fd7881a19f1833fff50231b34b968f81bf10",
            "sha384:93bd23012b0438d55fe6a0f28c000606f444b9b38309e2ad38acfc51b97f6b7590c6e49890bed04ebc97485dff890c3a",
            "sha512:77c5df04dd6cab6bbcf6ebc609062b8223bd42e98761a9e86c02e66702dc6da572ed196610c9bc4d1df5b656573898ccc98a523143191bdbd5273c74294ee399"
          ],
          "document_id": "https://access.redhat.com/security/data/sbom/spdx/quarkus-bom-3.2.12.Final-redhat-00002",
          "labels": {
            "type": "spdx"
          },
          "name": "quarkus-bom",
          "version": "3.2.12.Final-redhat-00002",
          "status": [
            "not_affected",
            "fixed"
          ]
        }
      ]
    }
  ]
}

Here is the question: How to read the field advisories.sboms.status?

  • Notice that advisories.sboms.status is an array and in the example I shared above it has a value of advisories.sboms.status=[not_affected, fixed]
  • Under the premise of: "I fetched the cve CVE-2024-29025", then "the second sbom mentions an id=urn:uuid:0191134f-d498-72e1-bddf-a50e0efeb88c", then finally there are 2 statuses "not_affected, fixed". HOW DO I READ THAT? does it mean that a single CVE could affect an SBOM and that SBOM can have multiple statuses? I am not even sure how to formulate the question. It seems that it should not be possible for an SBOM to have more than 1 status under the context of a single vulnerability. We can not say this SBOM is "not_affected" by CVE-2024-29025, and at the same time say this SBOm is "fixed" for the CVE-2024-29025, both contradict each other.

Is this a bug? or should I read the data in a different way?

commented

A single SBOM can certainly have multiple statuses.

From the related RHT csaf:

      "product_status": {
        "fixed": [
          "Red Hat build of Quarkus 3.2.12.Final:io.quarkus.quarkus-core-3.2.12.Final-redhat-00001"
        ],
        "known_not_affected": [
          "Red Hat build of Quarkus 3.2.12.Final:aopalliance.aopalliance-1.0",
          "Red Hat build of Quarkus 3.2.12.Final:biz.aQute.bnd.biz.aQute.bnd.transform-6.3.1",
          "Red Hat build of Quarkus 3.2.12.Final:com.aayushatharva.brotli4j.brotli4j-1.12.0.redhat-00005",

All of those components come from the same quarkus 3.2.12 SBOM, ergo, that SBOM is considered both "fixed" and "not_affected" when viewed from the granularity of the SBOM.

We'll certainly get to the point where once you drill-down, you can see that quarkus-core is "fixed" and all the other packages are "not_affected", but that's entirely too much detail from the vulnerability entrypoint.

commented

the advisory is etc/test-data/csaf/rhsa-2024-2705.json

commented

A single SBOM can certainly have multiple statuses.

@bobmcwhirter I must say that doesn't make sense to me.
The question is not whether or not an SBOM can have multiple statuses, but the question is whether or not "an SBOM can have multiple statuses under the context of a single vulnerability". Let me put it this way, this is what currently I see in the data:

  • USER: Hey Trustify, tell me if my SBOM "quarkus-bom - 3.2.12.Final-redhat-00002" is affected by the "CVE-2024-29025"
  • TRUSTIFY: Sure! your SBOM "quarkus-bom - 3.2.12.Final-redhat-00002" is "AFFECTED" but also "FIXED"
  • USER: WTF! Make your own mind, Am I affected or not by CVE-2024-29025?

It might be that the advisory itself give that kind of information, but the server should bring a proper level of abstraction to avoid this kind of situations. I'll invest some time to look at the advisories myself later today, I am surprised the advisory file is giving this kind of information.

commented

Yah, I understand, but the data is confusing and multiply-status'd.

from an API consumer POV, I'd prefer to get all all data. Maybe the UI should sort the statuses and only display the "most important" such as "fixed"?

commented

Really, "This SBOM contains components that are a combination of FIXED and NOT_AFFECTED"

commented

If we can abstract one more level towards Products, then we could probably limit the status to "Quarkus 3.2.12 is FIXED", but since we're talking SBOMs, that's an aggregation of many bits'n'bobs, each possibly having its own status.

commented

Thanks for your reply @bobmcwhirter . I think we need to take a step back. I mean, I would suggest to evaluate "what we want/need", and not "what we have with the current models and files". I do think any client/customer/person would ask the same question, why do we have multiple statuses for a single sbom under the context of a single vulnerability?

Currently (Problem)

 "product_status": {
  "fixed": [
     "Red Hat build of Quarkus 3.2.12.Final:io.quarkus.quarkus-core-3.2.12.Final-redhat-00001"
   ],
   "known_not_affected": [
     "Red Hat build of Quarkus 3.2.12.Final:aopalliance.aopalliance-1.0",
     "Red Hat build of Quarkus 3.2.12.Final:biz.aQute.bnd.biz.aQute.bnd.transform-6.3.1",
     "Red Hat build of Quarkus 3.2.12.Final:com.aayushatharva.brotli4j.brotli4j-1.12.0.redhat-00005",
  • What currently Trustify is saying: The vulnerability XYZ is affecting your SBOM and the status of your SBOM is "fixed" and "know_not_affected"
  • as a human, how I read the json extracted above: The vulnerability XYZ is affecting multiple packages. The package "aopalliance.aopalliance-1.0", "biz.aQute.bnd.biz.aQute.bnd.transform-6.3.1" and "com.aayushatharva.brotli4j.brotli4j-1.12.0.redhat-00005" are "know_not_affected"; and the package: "io.quarkus.quarkus-core-3.2.12.Final-redhat-00001" is fixed. In conclusion YOUR SBOM IS NOT AFFECTED (single status, not multiple)

What I propose

  • SBOMs: only can have a single status "affected" or "not affected". There is no other status for an sbom. This status is an abstraction of the backend.
  • Package: packages can have the common statuses like: "affected", "fixed", "know_not_affected", "under_investigation", etc. These statuses come from the advisory files.

Rules FOR An sbom is "AFFECTED" IF:

  • There is at least one package affected by the vulnerability (probably explained by the CVE importer) - WE ASSUME THE SBOM IS VULNERABLE BECAUSE IT CONTAINS THE VULNERABLE PACKAGE
  • If the previous condition is met, then let's check the advisory that explain products (CSAF importer). If the package WE ASSUME IS VULNERABLE does not have the status "FIXED" or "know Not affected" in the CSAF file, then we can conclude the SBOM is AFFECTED (THIS IS A CONCLUSION THAT PATCHES THE PREVIOUS ASSUMPTION)

If both conditions above are not met, then we can say the SBOM is NOT AFFECTED.

My point is we need to have a proper abstraction of data and this has to do with design and not with UI neither backend implementation/code.

commented
  • SBOMs: only can have a single status "affected" or "not affected". There is no other status for an sbom. This status is an abstraction of the backend.

While we'd prefer that, sure, that simply does not represent the data contained within an SBOM.

As noted, we should be able to roll up data-from-an-SBOM to something more cohesive about a product. But the SBOMs say what the SBOMs say, no matter how much it annoys us.

commented

"Under investigation" is also another valid status. Before knowing "not_affected" for the product, we may know that some components are "not_affected" but things are still "under_investigation".

commented

An SBOM is just a list of components/packages ... determining if an SBOM is affected or not is aggregate of status of all contained components ... people want to figure out if their software or product (modulo version, platform, el8... etc) is affected or not - SBOM is just a mechanism of interchange and less a 'view' humans will directly use. In addition - coming up with a heuristic for determining overall status, based on each component/packages status (at the SBOM boundary) will always fail for someone. I think the only route available is to enumerate statuses.

commented

That is why I was suggesting to have an abstraction about SBOM statuses and Package statuses. Those are 2 different things.

  • Talking about an SBOM. if the Vulnerability XYZ is "Under investigation" => I can assume my SBOM is "AFFECTED" (this is how a human would see things).
  • Talking about an SBOM. The only way I can be sure my sbom is not affected is if the status of the package involved in the discussion is marked as "fixed" or "know not affected". Everything else will make me assume I am AFFECTED.

Note: what I said is just a suggestion, not saying I am right. What I am suggesting mainly is to have data abstractions that involves data (advisory files) + logic that we as humans would use when it comes to determine whether or not an SBOM is affected.

As noted, we should be able to roll up data-from-an-SBOM to something more cohesive about a product. But the SBOMs say what the SBOMs say, no matter how much it annoys us.

Taking as an example this one

"product_status": {
"fixed": [
"Red Hat build of Quarkus 3.2.12.Final:io.quarkus.quarkus-core-3.2.12.Final-redhat-00001"
],
"known_not_affected": [
"Red Hat build of Quarkus 3.2.12.Final:aopalliance.aopalliance-1.0",
"Red Hat build of Quarkus 3.2.12.Final:biz.aQute.bnd.biz.aQute.bnd.transform-6.3.1",
"Red Hat build of Quarkus 3.2.12.Final:com.aayushatharva.brotli4j.brotli4j-1.12.0.redhat-00005",

I, AS A HUMAN WILL CONCLUDE MY SBOM IS "NOT AFFECTED" because the statuses I see are "fixed" and "known_not_affected". Where do we generate this kind of conclusions is the question i am asking. Do we show the current data to the user and ask him to make his own conclusion, or do we take that data and make a conclusion.

My apologies @bobmcwhirter , sometimes I am a pain in the a... I was just expressing an idea (and I am often wrong xD)

commented

Or something like: "We, Trustify, think/assume/conclude your sbom is affected by this vulnerability". But here are all the data you need to make your own conclusion" would work?

I think I am overstepping my role as this is the kind of requirements PM should decide :)