Do we need to improve support for different CycloneDX versions?

[mmarseu]

Hi everyone. Working on #137 has finally brought to light an issue that was always going to bite us at some point. I don't think we can skirt around it much longer. Once CycloneDX starts removing deprecated features (I assume with a version 2.0 at some point in the future) we'll run into real trouble.

When we initially designed this tool, I believe CycloneDX 1.3 was the current version. Then over time, 1.4 and more recently 1.5 have rolled out and we introduced support here and there, where it became necessary. We did so in a very naive fashion, though, sort of hoping that any change to the standard wouldn't break the existing algorithms.

Actually, the tool always applies the same algorithms to any SBOM, regardless of the CycloneDX version is use — except for validation which applies the correct version-dependent schema to the SBOM. Then it simply outputs the result using the same .specVersion which went in, whatever it may be. It is easy to see how that may produce invalid output whenever feeding the tool a version of CycloneDX older than what we had in mind when we designed a particular feature.

As I see it, there are three strategies to correctly deal with this:

1. Simply never change the versions of CycloneDX we support, outputting errors or warnings whenever it is used with a non-supported version. This isn't really a solution and more sticking our heads in the sand until this tool becomes irrelevant 😉
2. Keep a set of interpreters and transformers for each version of CycloneDX so we can both read and output valid CycloneDX in any supported version.
   I think CycloneDX CLI can serve as an example. It supports many versions of CycloneDX in its convert command.
3. Support reading different versions of CycloneDX but always upgrade the result to the latest supported version.
   This could lead to problems with other downstream tools which might not upgrade to newer CycloneDX versions at the same speed as this tool.

Personally, I believe (disregarding non-option 1) option 3 is the easiest to implement but option 2 is clearly the best one when it comes to playing nice with others.

What are your thoughts?

[italvi]

@mmarseu, nice catch with the metadata.tools! I think we will face this issue more and more, e.g. with 1.6 there will also be changes to the author in general. So thanks for bring this topic up.

Honestly, I think we have to prefer option 2 here - even though it means more work from our side. Option 3 could decrease the acceptance for our tool due to missing interoperability with other tools.

[CBeck-96]

I also agree with option 2, it means more work, since theres the need to make differentiations internally but the alternative would be a loss of usability.
Also there is a big refactoring planned, it should be possible to adapt the code to be make such adaptations easier.

Since we plan to use the "official" cycloneDX python model in the future, it should be considered how they handle it and if it might reduce the work we have to do.

[mmarseu]

Since we plan to use the "official" cycloneDX python model in the future,...

Is this something you've started working on? I might look into it, otherwise. Though it is a big undertaking and I'm not sure how much time I could put in. If you have a deadline, better do it yourselves 😉

[italvi]

No, we have not started working on it, yet. We planned it for Q3, i.e. summer as most people will be on vacation there, so we will have time to work on it. The introduction to the "official" python lib will be considered as the start of "1.x.y", so we want to do it with sufficient time available. If you want to start with it, feel free 😉.

[italvi]

Can be closed as we agreed on 2.