Package count is missing from nested sboms returned from /api/v1/vulnerability/{id}

[carlosthe19916]

The UI has the page CVE/Vulnerability Page details where we render all the SBOMs that somehow have a relation with a Vulnerability. See the image below:

Current UI process

• Fetch the vulnerability /api/v1/vulnerability/{id} that returns a response similar to:

{
  "advisories": [
    {
      "identifier": "Advisory1",
      "sboms": [
        {
          "id": "Sbom1",
          "status": ["affected"]
          // other fields
        },
        {
          "id": "Sbom2",
          "status": ["not_affected", "fixed"]
          // other fields
        }
      ]
    },
    {
      "identifier": "Advisory2",
      "sboms": [
        {
          "id": "Sbom2",
          "status": ["not_affected"]
          // other fields
        },
        {
          "id": "Sbom3",
          "status": ["not_affected"]
          // other fields
        }
      ]
    }
  ]
}

• The UI flattens the field advisories.sboms:

[
  {
    "id": "Sbom1",
    "status": ["affected"]
  },
  {
    "id": "Sbom2",
    "status": ["not_affected", "fixed"]
  },
  {
    "id": "Sbom2",
    "status": ["not_affected"]
  },
  {
    "id": "Sbom3",
    "status": ["not_affected"]
  }
]

• We can see that the status field is an array so we flatten that array too. The logic is to create an element of the array for each status . In our example since there was an element of the array with "status": ["not_affected", "fixed"] then that is decoupled in 2 elements of the array. The final result is:

[
  {
    "id": "Sbom1",
    "status": "affected"
  },
  {
    "id": "Sbom2",
    "status": "not_affected"
  },
  {
    "id": "Sbom2",
    "status": "fixed"
  },
  {
    "id": "Sbom2",
    "status": "not_affected"
  },
  {
    "id": "Sbom3",
    "status": "not_affected"
  }
]

• Then we remove duplicates:

[
  {
    "id": "Sbom1",
    "status": "affected"
  },
  {
    "id": "Sbom2",
    "status": "not_affected"
  },
  {
    "id": "Sbom2",
    "status": "fixed"
  },
  {
    "id": "Sbom3",
    "status": "not_affected"
  }
]

• For the previous array we need the field number_of_packages for each sbom. Therefore we call /api/v1/sbom/{id} for each element of the previous array. Then enrich the previous array to end up having something like:

[
  {
    "id": "Sbom1",
    "status": "affected",
    "number_of_packages": 123
  },
  {
    "id": "Sbom2",
    "status": "not_affected",
    "number_of_packages": 123
  },
  {
    "id": "Sbom2",
    "status": "fixed",
    "number_of_packages": 123
  },
  {
    "id": "Sbom3",
    "status": "not_affected",
    "number_of_packages": 123
  }
]

Finally the array is ready to be rendered in the UI. This approach suffer the same problems described at #952

• Too many calls to the backend
• The client implementing its own algorithm to deal with multiple advisories and its complexity

What I think we could evaluate changing

• Naming is very important. The response of /api/v1/vulnerability/{id} contains the field advisories.sboms which implies, from the naming, that what that field contains are SBOMS. The problem is that advisories.sboms does not match what /api/v1/sbom/{id} has as only /api/v1/sbom/{id} has the field number_of_packages but advisories.sboms doesn't.
  • Generally speaking it is important to define what an SBOM is and what are their fields so whenever any part of the API mentions sbom then the client is 100% sure what he expects there.
  • If we have the field advisories.sboms then I should get there exactly what I see in /api/v1/sbom/{id}
• The response from /api/v1/vulnerability/{id} contains a field advisories.sboms.status which is an array and not a single field. That technically means that an a Single advisory can say that an SBOM has the status affected and not_affected at the same time. E.g.

{
  "advisories": [
    {
      "identifier": "Advisory1",
      "sboms": [
        {
          "id": "Sbom1",
          "status": ["affected", "not_affected"]
          // other fields
        },
      ]
    }
  ]
}

This structure forces the client to come up with some kind of algorithm to parse the data and solve conflicts between multiple advisory.sboms.status values which might contradict each other.

[jcrossley3]

• The response from /api/v1/vulnerability/{id} contains a field advisories.sboms.status which is an array and not a single field. That technically means that an a Single advisory can say that an SBOM has the status affected and not_affected at the same time. E.g.

@carlosthe19916 this issue is really 2 issues, so I'm gonna break this out into another one. And I changed the title of this one to reflect the problem with the missing number_of_packages field.