Denote relationship between Product SBOM and other SBOM from CYCLONEDX

[JimFuller-RedHat]

This is a linked to https://issues.redhat.com/browse/TC-2048.

As devsecops, I want to be able to ingest Component cdx SBOM that relates back to their Product cdx SBOM (when defined in a separate cdx SBOM). This relationship should be traverseable via the REST-API/UX.

When cdx v1.6 Component SBOM is encoded with an evidence.identity, defined with a cpe - ingesting into trustify should establish a PACKAGE_OF trustify relationship.

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.6",
  "serialNumber": "6f12b04b-44f9-4be7-b0dd-1c66a9c121f6",
  "version": 1,
  "metadata": {
    "timestamp": "2024-12-08T13:21:12Z",
    "component": {
      "type": "framework",
      "bom-ref": "OSE-4.15-RHEL-9",
      "supplier": {
        "name": "Red Hat",
        "url": [
          "https://www.redhat.com"
        ]
      },
      "name": "Red Hat OpenShift Container Platform 4.15",
      "version": "OSE-4.15-RHEL-9",
      "evidence": {
        "identity": [
          {
            "field": "cpe",
            "concludedValue": "cpe:/a:redhat:openshift:4.15::el9"
          }
        ]
      }
    },
    "dependencies": [
      {
        "ref": "OSE-4.15-RHEL-9",
        "provides": [
          {
            "ref": "pkg:oci/ose-clusterresourceoverride-operator-bundle@sha256%3Ad37ea60be41f378e0d3b9c0936d8c3fb0e218e00b8cdc3c073a3e35d494f3e8d"
          },
          {
            "ref": "pkg:oci/ose-vertical-pod-autoscaler-operator-bundle@sha256%3A0c1507509cd03b183011726b11dc0f7834af8a097c9ffd5a4b389b8f2eae3bad"
          },
          {
            "ref": "pkg:oci/openshift-ose-cluster-nfd-operator-bundle@sha256%3A3b8a3f00c2eb483d25ad43a44e0140f699cd4d7a9a5c4f43e2eecc21ea8a6771"
          },
          {
            "ref": "pkg:oci/openshift-ose-ingress-node-firewall-operator-bundle@sha256%3A13f5bc757b25b359680938a06bbc83609b87f6797ede99f97953e5464ed380ef"
          },
          {
            "ref": "pkg:oci/openshift-ose-local-storage-operator-bundle@sha256%3A20f5923ea4ba9fdef4779efb1423274b479efbb1278dd13010518a159cf32e37"
          },
          {
            "ref": "pkg:oci/openshift-ose-metallb-operator-bundle@sha256%3A28b9c5ae08d95f9ae01bbf9fabab2d0bb7c93104243652e2b934dace47e3426d"
          },
          {
            "ref": "pkg:oci/openshift-ose-openshift-kubernetes-nmstate-operator-bundle@sha256%3A20c3af0b0c80da26b4ea948b705e073d9df7181e58852a89ec6ee783933f4275"
          },
          {
            "ref": "pkg:oci/openshift-ose-ptp-operator-bundle@sha256%3Af0bcb875bc379e1c6a2508796d69febe3891c5717956bcade2e1df6708f376b9"
          }
        ]
      }
    ]
  }
}

Alternatively, when cdx v1.6 product SBOM is encoded with an externalReferences in component metadata, ingesting into trustify should establish a PACKAGE_OF trustify relationship.

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.6",
  "version": 1,
  "serialNumber": "urn:uuid:337d9115-4e7c-4e76-b389-51f7aed6eba8",
"metadata": {
  "component": {
    "type": "operating-system",
    "name": "Red Hat Enterprise Linux",
    "version": "9.4 MAIN+EUS",
    "supplier":
{        "name": "Red Hat",        "url": ["https://www.redhat.com"]     }
, "externalReferences": [   
{      "type": "package",      "bom": "",     }

,...]

}

Acceptance Criteria:

• View this information on api/v2/sbom, api/v2/analysis/root-component and api/v2/analysis/dep endpoints
• List components for specific product (by CPE)
• Existing support for sorting and querying extended
• Expected Trustify internal relationship: pkg:oci/ose-cluster PACKAGE_OF cpe:/a:redhat:openshift
• At query time we should indicate if the full set of interrelated SBOMs are quiescent in the system
• Multiple and/or nested evidence/identity relationships parsed from cdx MUST result in equivalent number of internal relationships
• Given an array of rbofrmvr/identity components, the last component is the one true upstream - in the case that last item has nested ancestor we continue to apply the rules until we find the last item (of the last array) - every other component would be considered midstream.

Search/Query:

HTTP GET /api/v2/sbom
HTTP GET /api/v2/sbom?q={...}

{
  "id":"urn:uuid:01939af7-697e-7242-99d5-cbf11729fa79",
  "document_id": "https://www.redhat.com/comp.json",
  "published": "2006-08-14T02:34:56Z",
  "name":  "kernel-module-management-operator-container-1.1.2-25",...
  "relationship":{
     "package_of":[
      {
       "id": "SPDXRef-image-index",
       "name": "kernel-module-management-product",
       "version": "1.1.2-25",
       "purl": [
        { "uuid": "2771e255-2ba5-5577-ab2c-3c43073f8841",          
          "purl":  "pkg:oci/kernel-module-management-product",
        }],
       "cpe": [ {}, ... ],
       ...
      },...]
  },
}

Expose PACKAGE_OF relationship information via other analysis graph endpoints.

HTTP GET /api/v2/analysis/root-component?q={...}
HTTP GET /api/v2/analysis/root-component/{purl|name}
(ex. /api/v2/analysis/root-component/pkg%3Aoci%2Fopenshift-ose-ptp-operator-bundle%40sha256%253Af0bcb875bc379e1c6a2508796d69febe3891c5717956bcade2e1df6708f376b9)

{
   "sbom_id": "01947003-905b-70d1-bf49-76707fe75401",
   "node_id": "SPDXRef-013c6f62-83b1-43da-8f86-ad40a7397033",
   "purl": "pkg:oci/openshift-ose-ptp-operator-bundle@sha256%3Af0bcb875bc379e1c6a2508796d69febe3891c5717956bcade2e1df6708f376b9",
   "name": "openshift-ose-ptp-operator-bundle",
   ...
   "ancestors": [
        {
          "sbom_id": "01947003-905b-70d1-bf49-76707fe75401",
          "node_id": "SPDXRef-30c6c70c-0ea3-4494-ba26-11c7aa40c91d",
          "relationship": "PackageOf",
          "cpe": "OSE-4.15-RHEL-9",
          ...
        }
    ]
},...

HTTP GET /api/v2/analysis/dep?q={...}
HTTP GET /api/v2/analysis/dep/{purl|name}
(ex. /api/v2/analysis/dep/pkg%3Aoci%2Fopenshift-ose-ptp-operator-bundle%40sha256%253Af0bcb875bc379e1c6a2508796d69febe3891c5717956bcade2e1df6708f376b9)

{
   "sbom_id": "0193d5a4-a15c-76a0-8263-dc7334891dc8",
   "node_id": "SPDXRef-e32409d9-5f5f-416c-96e5-e8d7b53957f3",
   "purl": "pkg:oci/openshift-ose-ptp-operator-bundle@sha256%3Af0bcb875bc379e1c6a2508796d69febe3891c5717956bcade2e1df6708f376b9",
   "deps": [
        {
          "sbom_id": "01947003-905b-70d1-bf49-76707fe75401",
          "node_id": "SPDXRef-ef180a7d-b966-47a5-841b-2aa2ec76c592",
          "relationship": "PackageOf",
          "cpe": "OSE-4.15-RHEL-9",
          "deps": [
              {},...
          ]
        },{}...]
   ...
},...

Example cdx SBOM

https://github.com/RedHatProductSecurity/security-data-guidelines/blob/main/sbom/examples/product/rhel-9.2-eus.cdx.json

Future / Other Considerations

• It is out of scope to relate between different SBOM formats.
• We assume both sbom(s) have been ingested and it is out of scope to try and figure out what it means if only a Product SBOM has been ingested ... async upload of either product or component sbom is allowed but on view we should clearly indicate if full set is present or not so analyst will know if complete 'picture' is being provided for a product.
• For completeness we provide api/v2/analysis/deps ... but in practice we will probably filter our deps= to be only children.
• Note about cdx v1.6 support (which applies to all cdx user stories in this document): In the short term, we are mostly interested in the software composition use case of CDX, not any other use case currently (e.g. CBOM, AI-BOM/ML-BOM, HBOM, VEX, etc.). The specific parts of the spec that allow us to represent the relationships described at https://redhatproductsecurity.github.io/security-data-guidelines/sbom/.

[JimFuller-RedHat]

ADR for external references accepted - https://github.com/trustification/trustify/blob/main/docs/adrs/00003-external-references.md