load_sbom Pipeline does not import CDX 1.4 dependency data

[mjherzog]

I used SCIO to load 3 CDX 1.4 XML SBOMs and the loads did not include any dependency. There was no related processing error from the pipeline. I have not reproduced this for JSON format but I expect the same issue.

This was data for a container image so the dependency data is likely secondary, but for SBOM processing in general we need to capture what is in the input SBOM for general use and for inclusion in an output SBOM.

There is a similar issue for loading SPDX SBOMs where the data is stored as Elements with Relationship Types. Fixing this for CDX where the dependency data structure is simpler and more clear should be the priority.

The SCIO version is 34.2.0

[DennisClark]

just for the record, I have exported SBOMs from SCIO in both CDX and SPDX JSON formats, and both formats include the dependency data in their own ways. So the problem seems to be getting the Import to catch up with the Export functionality.

[pombredanne]

Here is an example: https://sbombenchmark.dev/score/syft-0.105.1_nginx-stable-bullseye-perl.cdx.xml There are likely many in the CycloneDX repos otherwise.

[keshav-space]

I was able to load the 1.4 XML BOM for Laravel listed here https://github.com/CycloneDX/bom-examples/blob/0979663521c4623792dc432d09f88bcb85862a62/SBOM/laravel-7.12.0/bom.1.4.xml, and I got all the associated dependency data in the Packages table.

[keshav-space]

Also, all dependencies with concrete versions are treated as packages (DiscoveredPackage), and only those dependencies for which we don't have a concrete version are stored as Dependencies (DiscoveredDependency). In most cases, when loading the SBOMs, we will have all the dependencies in the package table. This is confusing, we should have a way to properly preserve these package-dependency relationships. We already have an issue for this here https://github.com/nexB/scancode.io/issues/1066.