Track relationships that span accross SBOMs.

[chirino]

Currently, only relationships within an SBOM are tracked by the package_relates_to_package table:

             Table "public.package_relates_to_package"
    Column     |       Type        | Collation | Nullable | Default 
---------------+-------------------+-----------+----------+---------
 left_node_id  | character varying |           | not null | 
 relationship  | integer           |           | not null | 
 right_node_id | character varying |           | not null | 
 sbom_id       | uuid              |           | not null | 
Indexes:
    "package_relates_to_package_pkey" PRIMARY KEY, btree (sbom_id, left_node_id, relationship, right_node_id)
Foreign-key constraints:
    "package_relates_to_package_relationship_fkey" FOREIGN KEY (relationship) REFERENCES relationship(id)
    "package_relates_to_package_sbom_id_fkey" FOREIGN KEY (sbom_id) REFERENCES sbom(sbom_id) ON DELETE CASCADE
    "package_relates_to_package_sbom_id_left_node_id_fkey" FOREIGN KEY (sbom_id, left_node_id) REFERENCES sbom_node(sbom_id, node_id) ON DELETE CASCADE
    "package_relates_to_package_sbom_id_right_node_id_fkey" FOREIGN KEY (sbom_id, right_node_id) REFERENCES sbom_node(sbom_id, node_id) ON DELETE CASCADE

This should get extended to track a relationship to packages defined in external sboms.

[chirino]

Solving this would also help with the issue #1140

It needs to define relationships to other sboms for the externalDocumentRefs fields.

{
  "SPDXID" : "example-product-sbom",
  "spdxVersion": "SPDX-2.3",
  "dataLicense": "CC0-1.0",
  "created": "2023-10-01T12:00:00Z",
  "externalDocumentRefs": [
    {
      "referenceDocumentIdentifier": "SPDXRef-other-sbom",
      "referenceCategory": "PACKAGE",
      "referenceType": "SPDX",
      "referenceLocator": "https://example.com/path/to/other-spdx-document.spdx"
    }
  ],
  ...
}

[JimFuller-RedHat]

some other issues that mention multi sbom
#509
#847

[ctron]

My proposal would be to add two columns into this table, left and right "sbom reference". Which should (by definition) match the the SPDX namespace and CDX serial. However, not adding actual database constraints.

Then, do the referencing during the actual lookup. Which we could do "in memory" using the analysis graph. Allow the user, during the query process, to specify the mode of operation when encountering a broken link, or multiple link targets.

Possible modes for broken links could be: fail, ignore (and report).

[JimFuller-RedHat]

@ctron that sounds good to me ... how we link 2 graphs in the 'forest' hashmap is something we can chat through

[chirino]

My proposal would be to add two columns into this table, left and right "sbom reference". Which should (by definition) match the the SPDX namespace and CDX serial. However, not adding actual database constraints.

What do we set the node_id fields to? Or do we make the field nullable?

 left_node_id  | character varying |           | not null | 
 right_node_id | character varying |           | not null | 

[jcrossley3]

Adding two columns means we'd have 3 sbom's referenced in each row, correct? The existing sbom_id, and then left_sbom and right_sbom added?

Given the above pedigree>ancestors example, what would you put in those 3 fields? With only purl's mentioned, how do you know which (and how many) SBOM's might be referenced? What if multiple future SBOM's reference that same purl?

[JimFuller-RedHat]

I want to clear up a misconception ... if a component description inside a pedigree.ancestors (or anything else for that matter) has no reference to an external sbom (using reference) there is no concept of matching a purl to a purl in some other sbom ... eg. a purl is germane to the sbom it is defined in - in other scenario of product<>component sbom the relationship is deduced via CPE linkage.

We could probably make examples for upstream (etc) that define an external reference but that is out of scope eg. the upstream relationship we are denoting is all done within the confines of a single sbom.

[chirino]

I want to clear up a misconception ... if a component description inside a pedigree.ancestors (or anything else for that matter) has no reference to an external sbom (using reference) t

@JimFuller-RedHat is that field "bom-ref" is not a sbom reference?

[jcrossley3]

From the spec for bom-ref: "An optional identifier which can be used to reference the component elsewhere in the BOM. Every bom-ref must be unique within the BOM. Value SHOULD not start with the BOM-Link intro 'urn:cdx:' to avoid conflicts with BOM-Links."

So bom-ref's are local to the SBOM. I'm guessing "BOM-Links" are the external references?

[chirino]

We had a good talk today. We are considering storing the external document info in a new node type that uses the doc namespace as part of the node ID. But before going too deep into implementing it, we should find actual SBOMs with external doc refs and see if we can concoct examples highlighting difficult edge cases.

[JimFuller-RedHat]

create adr #1172

[JimFuller-RedHat]

tagging #556