Open riteshnoronha opened 2 months ago
Hey @riteshnoronha , I have few doubts: New version of CycloneDX is released, in which some of the field is deprecated and some are newly added to it. So, what to do with them ? I mean if fields are deprecated then we need to specify that for CycloneDX version 1.6 this field is deprecated, similarly if some fields are new, then specify that these field as optional(or required, if in case) for version 1.6.
Additional resources for this issue: CycloneDX:1.5 - https://cyclonedx.org/docs/1.5/json/#services CycloneDX:1.6- https://cyclonedx.org/docs/1.6/json/#services Blog: https://cyclonedx.org/news/cyclonedx-v1.6-released/
CycloneDX:1.6 has added 2 new fields OmniBOR Artifact Identifier (gitoid)(omniborId) and Software Heritage persistent IDs(swhid) under it's components section. For more see here.
About OmniBOR:
"omniborId": {
"type": "array",
"title": "OmniBOR Artifact Identifier (gitoid)",
"description": "Specifies the OmniBOR Artifact ID. The OmniBOR, if specified, MUST be valid and conform to the specification defined at: [https://www.iana.org/assignments/uri-schemes/prov/gitoid](https://www.iana.org/assignments/uri-schemes/prov/gitoid)",
"items": { "type": "string" },
"examples": [
"gitoid:blob:sha1:a94a8fe5ccb19ba61c4c0873d391e987982fbbd3",
"gitoid:blob:sha256:9f86d081884c7d659a2feaa0c55ad015a3bf4f1b2b0b822cd15d6c15b0f00a08"
]
},
About swhid:
"swhid": {
"type": "array",
"title": "SoftWare Heritage Identifier",
"description": "Specifies the Software Heritage persistent identifier (SWHID). The SWHID, if specified, MUST be valid and conform to the specification defined at: [https://docs.softwareheritage.org/devel/swh-model/persistent-identifiers.html](https://docs.softwareheritage.org/devel/swh-model/persistent-identifiers.html)",
"items": { "type": "string" },
"examples": ["swh:1:cnt:94a9ed024d3859793618152ea559a168bbcbb5e2"]
},
An schema example for CycloneDX:1.6: https://github.com/CycloneDX/cyclonedx-go/blob/master/schema/bom-1.6.schema.json
Comparison table between CycloneDX 1.5 and CycloneDX 1.6.
Here's an updated and detailed comparison of the fields and sub-fields between CycloneDX 1.5 and CycloneDX 1.6.
Field | CycloneDX 1.5 | CycloneDX 1.6 | Changes |
---|---|---|---|
definitions |
No | Yes | New in 1.6 |
declarations |
No | Yes | New in 1.6 |
Field | CycloneDX 1.5 | CycloneDX 1.6 | Changes |
---|---|---|---|
provides |
No | Yes | New in 1.6 |
Field | CycloneDX 1.5 | CycloneDX 1.6 | Changes |
---|---|---|---|
tags |
No | Yes | New in 1.6 |
Field | CycloneDX 1.5 | CycloneDX 1.6 | Changes |
---|---|---|---|
manufactures |
No | Yes | New in 1.6 |
author |
Yes | Deprecated | Deprecated in 1.6 |
authors |
No | Yes | New in 1.6 |
omniBORId |
No | Yes | New in 1.6 |
swhid |
No | Yes | New in 1.6 |
cryptoproperties |
No | Yes | New in 1.6 |
tags |
No | Yes | New in 1.6 |
Field | CycloneDX 1.5 | CycloneDX 1.6 | Changes |
---|---|---|---|
manufacturer |
No | Yes | New in 1.6 |
Hey @riteshnoronha so basically here we need to add support for version 1.6
for CycloneDX in cdx_spec_versions. I have a doubt that: do we also need to add new fields which are in 1.6(as shown above) for checks in CRA compliance as a optional fields?
Let me spend some time this week reviewing all the criteria for cyclonedx 1.6. Will update soon.
Just tested sbomqs 0.1.6 with a cdx 1.6 sbom created from cdxgen, but it fails with:
failed to parse sbom.formatted.json : json: cannot unmarshal array into Go struct field Evidence.components.evidence.identity of type cyclonedx.EvidenceIdentity
Actually 1.6 is not supported as yet. We are still working on it.
Cyclonedx 1.6 has been out for a couple of months, i believe the cyclonedx-go package now supports it, lets integrate and test it out, and make the necessary changes.