Generate SBOM in CycloneDX 1.5 format

[DennisClark]

CycloneDX 1.5 has been released. SCIO should have an option to generate an SBOM in that format. The following link should be useful:

https://cyclonedx.org/guides/sbom/use_cases/#license-compliance

In particular, there is a property (new, I think) in licensing called evidence that could be an appropriate place to list "other" licenses that are found in a package. See attached image.

There is also a discussion about the 1.5 format here
aboutcode-org/scancode-toolkit#2987

[DennisClark]

The "Evidence" chapter presents some interesting details that might be helpful.

https://cyclonedx.org/guides/sbom/evidence/#confidence

In particular, we might be able to use the license_clarity score generated by SCTK in the confidence field.

[DennisClark]

the new schema is here:
https://cyclonedx.org/schema/bom-1.5.schema.json

[DennisClark]

Labels updated. We need to work on this whenever possible.

[tdruez]

@DennisClark The CycloneDX 1.5 is being implemented in #1057

In particular, there is a property (new, I think) in licensing called evidence that could be an appropriate place to list "other" licenses that are found in a package. See attached image.

In particular, we might be able to use the license_clarity score generated by SCTK in the confidence field.

To help with the implementation of new fields, could you provide concrete examples of scancode data and how it will be included in the SBOM?

[DennisClark]

@tdruez I'll look into your question shortly.

[DennisClark]

On closer examination, the "confidence" field is not exactly what I thought it was, and refers to the confidence level of the component (package) identification, rather than the license clarity. I think we can look at that some other time.

But I think we could make use of the "evidence" field as described at
https://cyclonedx.org/guides/sbom/evidence/#license-and-copyright

scancode summary results include an "other_license_expressions" field that contains multiple expressions, each of which provides scancode license keys in the "value" field. Perhaps we can transform each scancode license key to an SPDX license identifier (in the CDX "id" fiedl) and the corresponding URL to the scancode LicenseDB (in the CDX "url" field).

scancode summary results also include an "other_holders" field that contains multiple holders, each of which might be useful, if prefixed by "Copyright ", in the CDX copyright "text" field.

I have attached scan results from one of our favorite projects, pypi_django_5.0_scan, to illustrate the scancode results found in the summary.

@tdruez let me know what you think about this. If my suggestions simply overlap or duplicate what we are doing already, then we can drop the idea, but I think that the new "evidence" field might be a good place to provide more complete licensing data for each package (component).

pypi_django_5.0_scan.zip

[tdruez]

scancode summary results include an "other_license_expressions" field that contains multiple expressions, each of which provides scancode license keys in the "value" field. Perhaps we can transform each scancode license key to an SPDX license identifier (in the CDX "id" fiedl) and the corresponding URL to the scancode LicenseDB (in the CDX "url" field).

https://cyclonedx.org/docs/1.5/json/#components_items_evidence_licenses

"EITHER (list of SPDX licenses and/or named licenses) OR (tuple of one SPDX License Expression)"

Since it supports license expression, and since we already use expression in other places of the SBOM, I think we should set the value from the other_license_expression_spdx field as-is.

scancode summary results also include an "other_holders" field that contains multiple holders, each of which might be useful, if prefixed by "Copyright ", in the CDX copyright "text" field.

I don't think it's a good idea to put made up values in the context of CycloneDX SBOM, I would prefer to only use data as-is from the model DB.

Keep in mind that we also support "loading" existing CDX SBOM into ScanCode.io.
Let not make the "import" process more complex than it needs to be, and I would prefer that the data "exported" is consistent with the "imported" data.

[DennisClark]

@tdruez thanks for the feedback; your comments make sense.

[DennisClark]

@tdruez I reviewed a few 1.5 SBOMs exported from staging, and they all look quite good. I'm impressed by the way we are handling both vulnerabilities and dependencies. No problems found.

[tdruez]

The CycloneDX SBOM outputs are now generated in 1.5 spec format, migrated from 1.4 previously.
Also, the Package vulnerabilities are now included in the CycloneDX SBOM when available.

#1057