protobom/protobom

Support CycloneDX 1.5

Closed this issue · 7 comments

manifestori commented

As the spec for CycloneDX 1.5 was released, and some OSS generators already use it by default (Trivy, cdxgen)

Also, cyclonedx-go lib is being upgraded to support 1.5 here: https://github.com/CycloneDX/cyclonedx-go/tree/spec-v1.5

I want to support converting from and to cdx 1.5

TODO:

  • Implement unserializer for cdx1.5
  • Implement serializer for cdx1.5
  • Update supporting lib, refactor common functionalities between cdx formats
  • Update tests, docs, and examples
  • Open PR for sbom-convert and update the supported format list
manifestori commented

@puerco When Implementing the changes to 1.5, the spec added support for ModelCard and for Data on Component do you think we should add this to our proto model? They are pretty complex and contain many sub messages.

From parliminary research I've done by look over at SPDX 3.0, DataSet might be the attribute we intend to pull this data from. I believe SPDX 2.3<= won't be able to support this, this is also true for CDX 1.4<=

spdx/spdx-3-model#363

wdyt?

manifestori commented

I've researched cyclonedx-go and realized how they are doing backward/forward compatibility.

This is true for 1.x and might change when/if they break this notion with 2.x.

Decoding:
Marshaling uses go annotations to convert from xml/json to go structs.
The spec itself is backward compatible, so if, for example, a CDX1.3 is read, it won't have the "vulnerabilities" prop allocated.
:
Encoding:
When we encode back to cyclonedx-go does a "copy and convert" which first copy into a new bom (to preserve immutability) and then, fix compatibility issues on the fly, if for example:

if b.Metadata != nil {
		if specVersion < SpecVersion1_3 {
			b.Metadata.Licenses = nil
			b.Metadata.Properties = nil
		}
..

I have been uncertain about how they will implement backward/forward compatibility for changes in the schema that resolves with a type change. The only instance this happens is with Tools (#68)
Note the schema changes: CycloneDX/specification#198

Their option is to override UnmarshalJSON and fix older spec SBOM from a slice to an object, but this is still an open question: Tracking it [here](CycloneDX/cyclonedx-go#115)

manifestori commented

As the spec for CycloneDX 1.5 was released, and some OSS generators already use it by default (Trivy, cdxgen)

Also, cyclonedx-go lib is being upgraded to support 1.5 here: https://github.com/CycloneDX/cyclonedx-go/tree/spec-v1.5

I want to support converting from and to cdx 1.5

TODO:

  • Implement unserializer for cdx1.5
  • Implement serializer for cdx1.5
  • Update supporting lib, refactor common functionalities between cdx formats
  • Update tests, docs, and examples
  • Open PR for sbom-convert and update the supported format list

The latest discovery changes the TODO list, obsoleting first two, in favor of
"update CDX unserialized to support all 1.x SBOMs"
"update CDX serializer to support all 1.x SBOMs"

  • 👍1
github-actions commented

Stale issue message

tannerjones4075 commented

I would like to contribute to this issue. I can help with Update tests, docs, and examples. Any other additional information would be helpful.

jspeed-meyers commented

I would like to contribute to this issue. I can help with Update tests, docs, and examples. Any other additional information would be helpful.

Cool! @puerco, @manifestori, @houdini91 - Any thoughts about how @tannerjones4075 can best help out on this issue?

github-actions commented

Stale issue message