SPDX 2.3 JSON output has error for discovereddependency data

[mjherzog]

scancodeio_tomcat-source-11.0.2_results-2025-04-07-23-24-36.spdx.json

Describe the bug
The SPDX 2.3 output from SCIO creates an invalid SPDXID for dependency data because it uses a PURL in the format: SPDXRef-scancode.io-discovereddependency-[PURL}. The SPDX 2.3 spec for Package SPDXID says: "SPDXRef-"[idstring] where [idstring] is a unique string containing letters, numbers, ., and/or -. The SPDXID for a dependency needs to be in the same format as a package - e.g., SPDXRef-scancodeio-discoveredpackage-9b437ee5-d99b-4f01-b177-00cf42f8dcc4

System configuration

• Which version of ScanCode.io are you running? v34.10.0 (SCIO staging)

I have attached an SPDX 2.3 JSON file for tomcat_source_11.02 that clearly shows this pattern starting with SPDXRef-scancodeio-discovereddependency-pkg:maven/com.h2database/h2@2.2.220?uuid=ff375640-3298-475e-b7c8-5d6e44a90325

The SPDXID for discovereddependency data needs to be in the same format as disoveredpackage with the PURL in externalRefs.

This issue is high priority because it causes an SPDX validation error with SPDX Online Tools for an SPDX 2.3 JSON file generated with SCIO if the scan includes any dependencies.

[DennisClark]

Additional details.
The SPDX validate tool at https://tools.spdx.org/app/validate/ generates a warning when you give it an SBOM with one of the SPDX IDs that Michael is describing.
The SPDX convert tool at https://tools.spdx.org/app/convert/ generates an error when you try to convert that SBOM.

[tdruez]

The SPDX ID for the DiscoveredDependency was based on the dependency_uid that may contain PURL data in some cases (data provided by ScanCode-toolkit).

To ensure we generate a compatible SPDX ID, I've added a UUID field on this model and refactored the spdx_id property to use the UUID in place of the dependency_uid.

See the implementation in #1654