output in version 1.5 still uses deprecated features of the CycloneDX schema and should (TMHO) upgrade to use the latest/non-deprecated attributes/schema

[tchinchow]

I recently ran into an issue while trying to merge multiple CycloneDX SBOMs in version 1.5 into one single unified SBOM and though that the error was due to #469.
I waited until #469 was release in 2.8.0 but realized that there may be another problem with the output file format.

Indeed, even when configured to produce CycloneDX v1.5 files, the output still uses deprecated structures for the "tools" section.
(Please see https://cyclonedx.org/docs/1.5/json/#tab-pane_metadata_tools_oneOf_i0 for reference)

Here is what I get:

{
  ...
  "metadata" : {
    "tools" : [
      {
        "vendor" : "OWASP Foundation",
         ...
      }
    ],
...

Here is what the other tools produce (and what the standard suggests):

{
  ...
  "metadata" : {
    "tools" : {
      "components": [
        {
           ...
        }
      ],
      "services": [
      ]
    },
...

Do you think you could consider upgrading the v1.5 output file format to use the [recommended schema](https://cyclonedx.org/docs/1.5/json/#tab-pane_metadata_tools_oneOf_i0) instead of the [deprecated structure](https://cyclonedx.org/docs/1.5/json/#tab-pane_metadata_tools_oneOf_i1) ? 

Many thanks in advance for your time.

EDIT: Looking at the code, I realize this may actually come from cyclonedx-core-java and I submitted an issue there as well CycloneDX/cyclonedx-core-java#395

[jkowalleck]

[...] should (TMHO) upgrade to use the latest/non-deprecated attributes/schema

There is no need to change. The deprecated structures will not go away for a while, unless CycloneDX v2 is being released.

The new structures might enable new features. The only reason to switch from "old" to "new" structures should be, if you are going to actually use the features the new structures introduced.

CC @CycloneDX/core-team

[tchinchow]

Thanx for your answer.

I'm "kind of" going to use the new structure because I'm merging a Maven SBOM (back end) with another SBOM (for the front end) generated with a tool called Syft which uses the new format.

So Yes because merging the files into one is using the files... But I reckon that's far fetched and somehow opinionated ;) .

Currently the two files are incompatible while being in the same format and same version: Only generated by two different tools. Thinking about how this is even possible casts a pretty dark shadow on CycloneDx itself and the promise of interoperability but I'll be constructive here : where do we go from here ?

I can work around the problem and replace the generated deprecated part because it is pretty thin.
The question then would be "what am I going to hardcode in that (metadata/tools) section ?" ...
I'm asking because the part in question describes is the cyclonedx-maven-plugin itself !

If this isn't going to be patched, maybe people would be interested in knowing how you would describe cyclonedx-maven-plugin with the new syntax:

• component or service ?
• if "component", then what type of component ?

Can someone draw a simple sketch of how cyclonedx-maven-plugin would look like in the new format or at least provide directions for the two above questions ?

[jkowalleck]

re: #487 (comment)

So you decided to consume and merge(transform) multiple CycloneDX documents?
Well, I guess it is the task of the merge tool, to assure a valid outcome, right? This means , the merge tool must take care of possible conversions - for example, streamlining $.metadata.tools.tool and $.metadata.tools.component.

---

example conversion (json with comemnts)

from:

{ // this is metadata
  "tools: [
    { // this is a tool
     "vendor": "my-vendor",
     "name": "my-name",
     "version": "1.33.7",
     "hashes": [ /* my-hashes */ ]
     "externalReferences": [ /* my-extRefs*/ ]
    }
] }

to:

{ // this is metadata
  "tools: {
    "components": [
      { // this is the "tool" from above, as a compoennt representation
        "type": "application"
        "group": "my-vendor",
        "name": "my-name",
        "version": "1.33.7",
        "hashes": [ /* my-hashes */ ]
        "externalReferences": [ /* my-extRefs*/ ]
      }
    ]
  }
}

[tchinchow]

Thanx for your inputs.

I was not sure that the translation would be this simple but it seems like all mandatory fields are there so I'll give it a try.
Besides I think you answers my two questions above:

• is cyclonedx-maven-plugin a component or a service ?
  component
• if "component", then what type of component ?
  application

I feel a bit more confident with the transformation that my merge tool will apply now.

Thanx again

[hboutemy]

I'm reopening the issue: the discussion on merge tools being able to manage and transform is a good one, but cyclonedx-maven-plugin should generate non-obsolete fields, which is not really a problem given there are transformation rules

I want to implement this soon, and do a 2.8.1 release for CycloneDX 1.5 before going to 2.9 for CycloneDX 1.6

[hboutemy]

@jkowalleck @tchinchow please review #517

[tchinchow]

@jkowalleck @tchinchow please review #517

Sorry for the late answer.
I saw that #517 has been merged in version 2.8.1 ... So I have tried version 2.8.1 instead and can confirm it works like a charm... I no longer have to patch the produced output manually.

Thanks a lot for this !