Need to refine and report CycloneDX SBOM metadata

[mjherzog]

For a CycloneDX SBOM (v1.4 to v1.6) you can report a component in the "metadata" section (header) in addition to the "components" section (details). This component represents "The component that the BOM describes". It has the same attributes (including PURL) as a component in the body of the SBOM. This top-level component might be a container (pkd:oci) or other software package.

We need to:

1. Capture this metadata/component (header) data separately from the components (details) data and
2. Capture and report other CycloneDX header information such as:

• bomFormat
• specVersion
• metadata/authors
• metadata/properties
• metadata/timestamp
• metadata/tools

Unfortunately the data elements of an SPDX v2.3 Document are very different and I cannot figure out the analogy for SPDX 3.0. We probably need some CDX-specific data structure or possibly we just capture this as some blob of data with key-value pairs.

[DennisClark]

Clarification: this issue is about what SCIO does with all the data that it imports from a CycloneDX SBOM, using the load_sbom pipeline, not what SCIO creates when it generates and exports a CycloneDX SBOM from a new scan.

[mjherzog]

Yes - this is about capturing important information when load an SBOM into SCIO. It also has implications for the visibility of SBOM information imported into DejaCode.

[mjherzog]

Dennis reminded me that we already capture the SBOM header data in SCIO Project data. So there are two immediate tasks:

1. The current display of Project data in SCIO is not in any logical order. It does not match the input file. SCIO should either (a) display the data in the same order as the input or (b) display in the order of the CDX spec - e.g. https://cyclonedx.org/docs/1.4/json/#metadata .
2. We need to include this data in the XLSX output for an uploaded SBOM. This is not tabular data so it probably makes sense to output as lines, perhaps with notation like "metadata/component/bom-ref", "metadata/component/type" etc. to flatten the nesting.
   We need to support CDX 1.4, 1.5 and 1.6 - this is CDX only. The SPDX analogue is the SPDX Document data but it is not very interesting.