Add 1.6 to supported cyclonedx spec versions.

[ragaskar]

• Resolves #2974

I had quite the time figuring out what folks were doing for the test-fixtures involved with expanding the supported spec range. In the end I determined it's a copy/paste w/ an updated spec version and a new unique serial number (I was doing some really silly things like compiling a syft snapshot with the default set to 1.6 in order to emit a fixture file).

There doesn't appear to be any documentation re: supported versions (outside out what is probably generated via the encoder/decoder interface itself). There are a few string mentions of spec versions, but these are input data for tests and not related to the actual supported versions (e.g.)

unit/integration tests pass (adding a new version to the list of supported versions in versions.go causes additional checks to be run) ... Not sure if there's anything else to check here?

EDIT: Please note, I did not bump the default cyclonedx spec version (so I believe by default syft will still emit v1.5 spec cdx, although it will decode 1.6 and can be configured to emit 1.6). I believe that is a change with the potential for wide user impact (👋 ) and should probably be made by core maintainers.

[ragaskar]

I see it barfing on the xml schema check ... 🤔 GoLand was also not happy. Let me see if I can replicate + fix.

[ragaskar]

breadcrumb for others: there's instructions here

modified to reference local copies of dependent schemas.

oof hope this is pretty straightforward.

[ragaskar]

I was surprised the schema validation tests generated 1.6 boms by default, even with DefaultVersion set to "1.5"

I am seeing that by default syft is generating cdx 1.6 spec boms regardless of this DefaultVersion setting. I am going to change it to match for now and will take another peek at why this is occurring. As mentioned above, I think the impact of bumping the default spec version emitted is fairly broad. I suppose users can lock back to 1.5 if desired by setting a version in their syft format config (maybe there's already good documentation for this, but I'm just now realizing that was an option for me as well 🤦 ).

Perhaps if someone could comment on expected behavior here?

[ragaskar]

Ok, ultimately, when an output format is passed (for a format that supports "all versions") like -o cyclonedx-json=some-file.json (WHICH! by the way, can also take a format/version pair e.g. -o cyclonedx-json@1.5=some-file.json), there's some logic that just takes the most recent version (see here). At this point I'm not sure I'm going to dig into the reasons behind also having the DefaultVersion constant; I'm just going to change it to match, since effectively 1.6 is now the default (since it's the most recent). Users who do not want to generate 1.6 can either pin back to 1.5 in their config file or directly via the flag as described above.

[ragaskar]

well, it does appear the DefaultVersion value is used by test, and I'm having a heck of a time figuring out the right incantation to regenerate the correct fixtures. If someone could advise that would be wonderful.

EDIT: I just brute-forced it by hardcoding the regen flag to true and then flipped it back after the fixtures were generated. Coarse but effective. 🤷

[spiffcs]

Thanks a million @ragaskar this looks great. Pulled it down locally and was able to generate 1.6 as the default.

I agree with the change that syft should generate 1.6 by default - I think it was just missed when we did the latest cyclone-dx library upgrades.

Thank you so much for the contribution!

If you ever want to talk about cyclone-dx or have other PR/Questions come check out our community meetings =)