cyclonedx / cyclonedx-dotnet-library

.NET library to consume and produce CycloneDX Software Bill of Materials (SBOM)

CycloneDX libraries for .NET

The CycloneDX libraries for .NET support programmatically consuming and producing CycloneDX bill-of-materials. CycloneDX is a lightweight BOM specification that is easily created, human readable, and simple to parse.

The libraries support .NET Standard 2.0.

Getting Started

For help getting started using the CycloneDX .NET Library refer to the documentation.

SPDX Interop

The CycloneDX.Spdx.Interop library includes methods for converting between CycloneDX and SPDX formats. (Currently only SPDX v2.2 JSON format is supported.)

High level overview of information lost during conversion:

This is a high level overview of information that will be lost during conversion. This is current state only, some features are yet to be implemented as indicated below.

If you are familiar with both formats, and would like to contribute to minimising data loss during conversion, pull requests are welcome :)

SPDX -> CycloneDX

Feature	Notes
Relationship Information	Implementation pending, related to CycloneDX component assemblies, dependency graph, and composition.
License information in files	Needs review, the way SPDX and CycloneDX handle license information evidence is slightly different.
Snippet Information	Snippets are not currently supported by CycloneDX
Non-SPDX licenses	Implementation pending

CycloneDX -> SPDX

Feature	Notes
Component assemblies	Implementation pending - related to SPDX Relationship Information
Hashes	SPDX documents are unable to represent the following hash algorithms: SHA3-256, SHA3-384, SHA3-512, BLAKE2b-256, BLAKE2b-384, BLAKE2b-512, BLAKE3.
SWID Tags	SPDX doesn't support SWID tags.
Component Type Information	SPDX doesn't support designating a component as a particular type (i.e. library, framework, container).
CPE and Package URL for Component Identity	SPDX supports multiple CPEs and PURLs for a package. But doesn't support specifying if any are a component identifier.
Device & Hardware Components	SPDX does not support devices or hardware as components.
Composition	Implementation pending - related to SPDX Relationship Information
Dependency Graph	Implementation pending - related to SPDX Relationship Information
External References	External references are handled differently between the two formats.
Non-SPDX licenses	Implementation pending

License

Permission to modify and redistribute is granted under the terms of the Apache 2.0 license. See the LICENSE file for the full license.

Contributing

Pull requests are welcome. But please read the CycloneDX contributing guidelines first.

To build and test the solution locally standard commands like dotnet build and dotnet test work.

The protocol buffer tests require the protocol buffer compiler executable protoc to be available in your path.

Documentation is generated using DocFX.

It is generally expected that pull requests will include relevant tests. Tests are automatically run on Windows, MacOS and Linux for every pull request. And build warnings will break the build.

If you are having trouble debugging a test that is failing for a platform you don't have access to please us know.

cyclonedx-dotnet-library's Issues

Flat merging can result in duplicate BOM refs

Not sure how to handle this. For hierarchical merging the top level component information can be used to "namespace" BOM refs.

Maybe requires supporting passing in namespace values for each BOM or optionally generating a random namespace.

I personally don't like the latter as it will drastically change BOM refs between runs. But maybe that's not really an issue given they are just used to identify elements within a single instance of a BOM.

SBOM validation is failing when uploading files generated using the global tool

I am using the dotnet cyclonedx tool (https://www.nuget.org/packages/CycloneDX) to generate SBOM's using the below command

dotnet CycloneDX .\Dashboard-Web\Dashboard-Web.csproj -t -ipr

Which produces the attached SBOM however when i attempt to upload it using the Dependency Track UI it is failing with the below error

This process was working prior to my company enabling sbom validation and they are hesitant to turn it back off hence wanting to get the tool fixed.

Note I have reproduced the issue with both 3.0.5 & 3.0.6 with 3.0.6 being the latest version.

My latest SBOM using 3.0.6 can be downloaded from https://fxs.skidata.com/message/CRdyZd5fSVfGzXr7MJanII with link valid until 3rd June 2024 @mtsfoni

Flat merging does not merge 1.5 metadata

I have the following two sbom files:

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.5",
  "serialNumber": "urn:uuid:18b33571-a6fe-4367-a039-086cd7d30086",
  "metadata": {
    "authors": [
      {
        "bom-Ref": "author",
        "name": "Author",
        "email": "[email protected]",
        "phone": "123456789"
      }
    ],
    "tools": {
      "components": [
        {
          "type": "application",
          "author": "anchore",
          "name": "syft",
          "version": "0.103.1"
        }
      ]
    },
    "component": {
      "bom-ref": "component",
      "type": "application",
      "name": "Test Application",
      "version": "1.2.3.4"
    }
  }
}

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.5",
  "serialNumber": "urn:uuid:3e2edd70-9f09-4a8f-8395-1e8410f21aa5",
  "version": 1,
  "metadata": {
    "timestamp": "2024-02-07T07:59:12Z",
    "tools": {
      "components": [
        {
          "type": "application",
          "author": "anchore",
          "name": "syft",
          "version": "0.103.1"
        }
      ]
    },
    "component": {
      "bom-ref": "component",
      "type": "application",
      "name": "Test Application",
      "version": "1.2.3.4"
    }
  },
  "components": [
    {
      "bom-ref": "pkg:npm/%40acuminous/[email protected]?package-id=7415bc36e2fc91c8",
      "type": "library",
      "author": "Michael Bridgen <[email protected]>",
      "name": "@acuminous/bitsyntax",
      "version": "0.1.2",
      "description": "Pattern-matching on byte buffers"
    }
  ]
}

If I merge these two files with cyclonedx-cli, the resulting file looks like this:

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.5",
  "serialNumber": "urn:uuid:60ee79ff-9dbd-421d-a1c9-4fd8f3ad7739",
  "version": 1,
  "metadata": {
    "component": {
      "type": "application",
      "bom-ref": "component",
      "name": "Test Application",
      "version": "1.2.3.4"
    }
  },
  "components": [
    {
      "type": "library",
      "bom-ref": "pkg:npm/%40acuminous/[email protected]?package-id=7415bc36e2fc91c8",
      "author": "Michael Bridgen \[email protected]\u003E",
      "name": "@acuminous/bitsyntax",
      "version": "0.1.2",
      "description": "Pattern-matching on byte buffers"
    },
    {
      "type": "application",
      "bom-ref": "component",
      "name": "Test Application",
      "version": "1.2.3.4"
    }
  ]
}

The tools only get merged if my input file uses the v1.4 schema and authors is anyway completely ignored (I am not sure if the authors should be handled by the library or the CLI).

Add support for serializing previous spec versions

TODO: Refactor CLI JSON and XML validation

FlatMerge performance issue

As of 6.0.0 it looks like JSON serialization is used to establish equality for components. This seems to greatly hurt merging performance. In my case about 70% of time is spent on the serializer.

cyclonedx-dotnet-library/src/CycloneDX.Core/Models/Component.cs

Lines 218 to 221 in 1e3886b

	public bool Equals(Component obj)
	{
	return Json.Serializer.Serialize(this) == Json.Serializer.Serialize(obj);
	}

v1.3 support for properties

Support cdx 1.6

Aren't `WorkflowTaskType` and `WorkflowTask.TaskType` definitions redundant?

Cross-posting from Slack discussion:

Cheers, looking at the new release 6.0.0 sources, I wondered: why is there a separate WorkflowTaskType.cs defining an enum WorkflowTaskType with same entries as a WorkflowTask.cs / enum TaskType?

Is there some big idea to keep them separate, or just some oversight?

• WorkflowTaskType is used from Workflow.cs (TaskTypes property) and Utils.cs (for HyphenEnumConverter registration)
• WorkflowTask.TaskType is used from WorkflowTask.cs (TaskTypes property) and Utils.cs (for HyphenEnumConverter registration)

Wouldn't it be cleaner (less code, easier comparisons) to use some one enum type in both cases?

CC @coderpatros : they landed together in one commit 50e9e33 - yours truly :)

Support CycloneDX 1.5

The CycloneDX specification was updated to version 1.5: https://cyclonedx.org/news/cyclonedx-v1.5-released/

And tools are already updating to support it, such as Trivy with its 0.43.0 release: https://github.com/aquasecurity/trivy/releases/tag/v0.43.0

Can this tool please also support the latest version of the CycloneDX specification?

Looking at https://github.com/CycloneDX/cyclonedx-dotnet-library/blob/v5.4.0/src/CycloneDX.Core/Models/Bom.cs#L71 this tool currently only supports up to 1.4.

Todo: Split testcases

Some PRs added new testcases under tests/Resources/
However, tests/Resources mostly maps the test cases from the spec.
There should be a separate folder for the testcases that are custom to this repository.

ExternalRefCategory 'PACKAGE_MANAGER' is not compliant with SPDX 2.2 specification

According to the SPDX 2.2 specification the referenceCategory of an ExternalReference can be SECURITY, PACKAGE-MANAGER , PERSISTENT-ID or OTHER.

However, in the ExternalRefCategory enum it is PACKAGE_MANAGER which uses an underscore instead of a dash.

cyclonedx-dotnet-library/src/CycloneDX.Spdx/Models/v2_2/ExternalRefCategory.cs

Lines 22 to 27 in 1e3886b

	public enum ExternalRefCategory
	{
	OTHER,
	SECURITY,
	PACKAGE_MANAGER,
	}

When trying to convert a valid SPDX SBOM it will result in this exception:

Unhandled exception: System.Text.Json.JsonException: The JSON value could not be converted to CycloneDX.Spdx.Models.v2_2.ExternalRefCategory. Path: $.packages[0].externalRefs[0].referenceCategory | LineNumber: 14 | BytePositionInLine: 48.
   at System.Text.Json.ThrowHelper.ThrowJsonException(String message)
   at System.Text.Json.Serialization.Converters.EnumConverter`1.ReadEnumUsingNamingPolicy(String enumString)
   at System.Text.Json.Serialization.Converters.EnumConverter`1.Read(Utf8JsonReader& reader, Type typeToConvert, JsonSerializerOptions options)
   at System.Text.Json.Serialization.Metadata.JsonPropertyInfo`1.ReadJsonAndSetMember(Object obj, ReadStack& state, Utf8JsonReader& reader)
   at System.Text.Json.Serialization.Converters.ObjectDefaultConverter`1.OnTryRead(Utf8JsonReader& reader, Type typeToConvert, JsonSerializerOptions options, ReadStack& state, T& value)
   at System.Text.Json.Serialization.JsonConverter`1.TryRead(Utf8JsonReader& reader, Type typeToConvert, JsonSerializerOptions options, ReadStack& state, T& value)
   at System.Text.Json.Serialization.JsonCollectionConverter`2.OnTryRead(Utf8JsonReader& reader, Type typeToConvert, JsonSerializerOptions options, ReadStack& state, TCollection& value)
   at System.Text.Json.Serialization.JsonConverter`1.TryRead(Utf8JsonReader& reader, Type typeToConvert, JsonSerializerOptions options, ReadStack& state, T& value)
   at System.Text.Json.Serialization.Metadata.JsonPropertyInfo`1.ReadJsonAndSetMember(Object obj, ReadStack& state, Utf8JsonReader& reader)
   at System.Text.Json.Serialization.Converters.ObjectDefaultConverter`1.OnTryRead(Utf8JsonReader& reader, Type typeToConvert, JsonSerializerOptions options, ReadStack& state, T& value)
   at System.Text.Json.Serialization.JsonConverter`1.TryRead(Utf8JsonReader& reader, Type typeToConvert, JsonSerializerOptions options, ReadStack& state, T& value)
   at System.Text.Json.Serialization.JsonCollectionConverter`2.OnTryRead(Utf8JsonReader& reader, Type typeToConvert, JsonSerializerOptions options, ReadStack& state, TCollection& value)
   at System.Text.Json.Serialization.JsonConverter`1.TryRead(Utf8JsonReader& reader, Type typeToConvert, JsonSerializerOptions options, ReadStack& state, T& value)
   at System.Text.Json.Serialization.Metadata.JsonPropertyInfo`1.ReadJsonAndSetMember(Object obj, ReadStack& state, Utf8JsonReader& reader)
   at System.Text.Json.Serialization.Converters.ObjectDefaultConverter`1.OnTryRead(Utf8JsonReader& reader, Type typeToConvert, JsonSerializerOptions options, ReadStack& state, T& value)
   at System.Text.Json.Serialization.JsonConverter`1.TryRead(Utf8JsonReader& reader, Type typeToConvert, JsonSerializerOptions options, ReadStack& state, T& value)
   at System.Text.Json.Serialization.JsonConverter`1.ReadCore(Utf8JsonReader& reader, JsonSerializerOptions options, ReadStack& state)
   at System.Text.Json.JsonSerializer.ReadCore[TValue](Utf8JsonReader& reader, JsonTypeInfo jsonTypeInfo, ReadStack& state)
   at System.Text.Json.JsonSerializer.ContinueDeserialize[TValue](ReadBufferState& bufferState, JsonReaderState& jsonReaderState, ReadStack& readStack, JsonTypeInfo jsonTypeInfo)
   at System.Text.Json.JsonSerializer.ReadFromStreamAsync[TValue](Stream utf8Json, JsonTypeInfo jsonTypeInfo, CancellationToken cancellationToken)
   at CycloneDX.Spdx.Serialization.JsonSerializer.DeserializeAsync(Stream jsonStream)
   at CycloneDX.Cli.CliUtils.InputBomHelper(String filename, ConvertFormat format)
   at CycloneDX.Cli.Commands.ConvertCommand.Convert(ConvertCommandOptions options)
   at System.CommandLine.Invocation.CommandHandler.GetExitCodeAsync(Object value, InvocationContext context)
   at System.CommandLine.Invocation.ModelBindingCommandHandler.InvokeAsync(InvocationContext context)
   at System.CommandLine.Invocation.InvocationPipeline.<>c__DisplayClass4_0.<<BuildInvocationChain>b__0>d.MoveNext()
--- End of stack trace from previous location ---
   at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c__DisplayClass23_0.<<UseParseErrorReporting>b__0>d.MoveNext()
--- End of stack trace from previous location ---
   at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c__DisplayClass16_0.<<UseHelp>b__0>d.MoveNext()
--- End of stack trace from previous location ---
   at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c__DisplayClass27_0.<<UseVersionOption>b__1>d.MoveNext()
--- End of stack trace from previous location ---
   at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c__DisplayClass25_0.<<UseTypoCorrections>b__0>d.MoveNext()
--- End of stack trace from previous location ---
   at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c.<<UseSuggestDirective>b__24_0>d.MoveNext()
--- End of stack trace from previous location ---
   at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c__DisplayClass22_0.<<UseParseDirective>b__0>d.MoveNext()
--- End of stack trace from previous location ---
   at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c__DisplayClass11_0.<<UseDebugDirective>b__0>d.MoveNext()
--- End of stack trace from previous location ---
   at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c.<<RegisterWithDotnetSuggest>b__10_0>d.MoveNext()
--- End of stack trace from previous location ---
   at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c__DisplayClass14_0.<<UseExceptionHandler>b__0>d.MoveNext()

My current workaround is just string replacing PACKAGE-MANAGER to PACKAGE_MANAGER before passing it to the cyclonedx-cli:
cat manifest.spdx.json | sed 's/PACKAGE-MANAGER/PACKAGE_MANAGER/g' | ./cyclonedx-linux-x64 convert --input-format spdxjson --output-format json > cyclonedx.json

I'm happy to contribute a solution for this, but changing an enum field or its (de)serialization is breaking to the current behavior. Should the old behavior still be supported? What should be the default?

Update spdx.schema files to v1.0-3.21

We are attempting to validate boms generated by Syft and Trivy using cyclonedx-cli. But, the validation is failing due to the TTWL license being in the list of licenses. According to the latest version of the CycloneDX spec, TTWL is a valid license. But, it is failing validation because this library is still using v1.0-3.17 of the spdx schema.

JSON validation fails for valid timestamps

Over in Rust land @jadamcrain opened an issue that our JSON files are invalid.

cyclonedx-cli fails on timestamps like 2022-12-21T23:54:20.218381200Z but it works if we chop off two digits at the end 2022-12-21T23:54:20.2183812Z

According to the JSON Schema timestamps are date-time fields which are RFC 3339 timestamps. The RFC doesn't specify a maximum number of fractional digits so both timestamps should be correct.

I'm not a .NET expert so take everything past this with a huge grain of salt:

• cyclonedx-cli uses this library
• This library uses JsonSchema.Net in version 3.3.2 as the dependency to do the actual validation
• In version 4.0.1 of the library (current is 5.3.0) it added support for higher-precision timestamps

As such I suggest to update the dependency to a newer version.
I can submit a trivial PR to update the version number but as I have zero knowledge about .NET tools that might not be enough and it might not build.

TODO: Refactor CLI analyze functionality

Does this project work with dotnet core based applications only?

We are looking for creating a SBOM for .Net framework based applications, does this code provide us the support with .net framework based applications or it only supports .net core based applications?

The other question is when creating SBOM is the source completely relayed on nuget packges or does the code create SBOM based on the components part of the solution?

v1.3 support for BOM license information

Vulnerability class does not contain "Properties" Property

As per CycloneDXv1.4 specification "vulnerabilities" contains "properties" field. I am using CycloneDX DotNet Library v5.3.0. But, I don't find "Properties" property inside Vulnerability class.
I need to use "Properties" field for my custom code. Is it planned to add "Properties" property in the vulnerability class? If yes, by when it will be available?

Snapshooter tests fail under MacOs

There is currently no known work-around.

See here: SwissLife-OSS/snapshooter#196

It may be an option to just build this Snapshot functionality by ourselves to reduce dependencies on libraries and have more control about what's happening.

VEX support

Current Behavior:

Merging two VEX files result in the error below in cyclonedx-cli

cyclonedx-cli merge --input-files 1b34e9fa-3a3f-4199-9ada-4b691f61869b-vex.cdx.json ec048047-1a44-4738-86d2-fe63faad61b5-vex.cdx.json --input-format json --output-file merged-vex.json --output-format json --name test --version test
Processing input file 1b34e9fa-3a3f-4199-9ada-4b691f61869b-vex.cdx.json
Processing input file ec048047-1a44-4738-86d2-fe63faad61b5-vex.cdx.json
Writing output file...
Unhandled exception: System.NullReferenceException: Object reference not set to an instance of an object.
   at CycloneDX.Cli.Commands.MergeCommand.Merge(MergeCommandOptions options)
   at System.CommandLine.Invocation.CommandHandler.GetExitCodeAsync(Object value, InvocationContext context)
   at System.CommandLine.Invocation.ModelBindingCommandHandler.InvokeAsync(InvocationContext context)
   at System.CommandLine.Invocation.InvocationPipeline.<>c__DisplayClass4_0.<<BuildInvocationChain>b__0>d.MoveNext()
--- End of stack trace from previous location ---
   at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c__DisplayClass23_0.<<UseParseErrorReporting>b__0>d.MoveNext()
--- End of stack trace from previous location ---
   at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c__DisplayClass16_0.<<UseHelp>b__0>d.MoveNext()
--- End of stack trace from previous location ---
   at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c__DisplayClass27_0.<<UseVersionOption>b__1>d.MoveNext()
--- End of stack trace from previous location ---
   at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c__DisplayClass25_0.<<UseTypoCorrections>b__0>d.MoveNext()
--- End of stack trace from previous location ---
   at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c.<<UseSuggestDirective>b__24_0>d.MoveNext()
--- End of stack trace from previous location ---
   at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c__DisplayClass22_0.<<UseParseDirective>b__0>d.MoveNext()
--- End of stack trace from previous location ---
   at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c__DisplayClass11_0.<<UseDebugDirective>b__0>d.MoveNext()
--- End of stack trace from previous location ---
   at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c.<<RegisterWithDotnetSuggest>b__10_0>d.MoveNext()
--- End of stack trace from previous location ---
   at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c__DisplayClass14_0.<<UseExceptionHandler>b__0>d.MoveNext()

Two issues :

• CycloneDX.Utils/Merge.cs does not handle vulnerabilities in BOM files causing a Null reference in CycloneDX-CLI/MergeCommand > Fixed by PR 209
• Vulnerabilities are ignored during merge processing

Expected Behavior:

Manage vulnerabilities part of the BOM at least for merge command

CycloneDX Unhandled exception: System.Text.Json.JsonException

See CycloneDX/cyclonedx-cli#139

CycloneDX version 1.4 - Missing license "Name" or "Id" fails validation

NOTE: I see there was a release last week, but the tools I have still use Cyclonedx-dotnet-library version is 5.4

Hello,

We have a dotnet product that uses the cyclonedx-dotnet tool to produce SBOM documents. Some of the external components only specify a URL for the license. The cyclonedx-dotnet tool adds the license without a "name" or "id" field, which is not valid for CycloneDX 1.4. When I run my SBOM through the CycloneDX validate website, the components fail.

https://cyclonedx.github.io/cyclonedx-web-tool/validate

Here is an example of the component output:

    {
      "type": "library",
      "bom-ref": "pkg:nuget/[email protected]",
      "author": "Mehdi Khalili, Oren Novotny",
      "name": "Humanizer.Core",
      "version": "2.2.0",
      "description": "Humanizer core package that contains the library and the neutral language (English) resources",
      "scope": "required",
      "hashes": [
        {
          "alg": "SHA-512",
          "content": "E232459F914C8E7FC3F8DEE69A85E66BEB8C44515D4C83A976EE24084A91F32AAE61C6F845FF38EDCAE02D0BCAB44F9EC253277DCCF2F4AE7E82235047BC6ADE"
        }
      ],
      "licenses": [
        {
          "license": {
            "url": "https://github.com/Humanizr/Humanizer/blob/main/LICENSE"
          }
        }
      ],
      "copyright": "Copyright 2012-2016",
      "purl": "pkg:nuget/[email protected]",
      "externalReferences": [
        {
          "url": "https://github.com/Humanizr/Humanizer",
          "type": "website",
          "hashes": []
        }
      ]
    }

And here is an example of the validation message:

Validation failed: #/properties/components/items #/components/6/licenses/0/license: Expected 1 matching subschema but found 0

Cybeats give slightly better validation error messages:

#/components/6/licenses/0/license: must have required property 'id' | must have required property 'name' | must match exactly one schema in oneOf

Adding a name property with the value of "NOASSERTION" satisfies the spec and the SBOM is considered valid.

    {
      "type": "library",
      "bom-ref": "pkg:nuget/[email protected]",
      "author": "Mehdi Khalili, Oren Novotny",
      "name": "Humanizer.Core",
      "version": "2.2.0",
      "description": "Humanizer core package that contains the library and the neutral language (English) resources",
      "scope": "required",
      "hashes": [
        {
          "alg": "SHA-512",
          "content": "E232459F914C8E7FC3F8DEE69A85E66BEB8C44515D4C83A976EE24084A91F32AAE61C6F845FF38EDCAE02D0BCAB44F9EC253277DCCF2F4AE7E82235047BC6ADE"
        }
      ],
      "licenses": [
        {
          "license": {
			"name": "NOASSERTION",
            "url": "https://github.com/Humanizr/Humanizer/blob/main/LICENSE"
          }
        }
      ],
      "copyright": "Copyright 2012-2016",
      "purl": "pkg:nuget/[email protected]",
      "externalReferences": [
        {
          "url": "https://github.com/Humanizr/Humanizer",
          "type": "website",
          "hashes": []
        }
      ]
    }

Solution: I suggest adding a name property with "NOASSERTION" to the output is ID or Name are not provided.

Add support for deserializing previous spec versions

RelationshipType AMENDS is missing

Hi,

I'm having trouble converting files from the spdx format due to the conversion not supporting the relationshipType AMENDS.

Example spdx json:

{
  "SPDXID": "SPDXRef-DOCUMENT",
  "name": "most of the data has been deleted for brevity",
  "relationships": [
    {
      "relatedSpdxElement": "DocumentRef-package-something:SPDXRef-DOCUMENT",
      "relationshipType": "AMENDS",
      "spdxElementId": "SPDXRef-DOCUMENT"
    }
  ],
  "spdxVersion": "SPDX-2.2"
}

To reproduce, put the above json in a file, "test.spdx.json" and run the cyclonedx-cli built against this library:

cyclonedx convert --input-format spdxjson --output-format json --input-file test.spdx.json --output-file test.cydx.json
Unhandled exception: System.Text.Json.JsonException: The JSON value could not be converted to CycloneDX.Spdx.Models.v2_2.RelationshipType. Path: $.relationships[0].relationshipType | LineNumber: 6 | BytePositionInLine: 34.
   at System.Text.Json.ThrowHelper.ThrowJsonException(String )
...

References:
https://spdx.github.io/spdx-spec/relationships-between-SPDX-elements/#1113-examples
https://github.com/CycloneDX/cyclonedx-dotnet-library/blob/main/src/CycloneDX.Spdx/Models/v2_2/RelationshipType.cs

Extra information(In accordance with contributing guidelines):
the version you are using: 5.1.1 used through https://github.com/CycloneDX/cyclonedx-cli which was built from master
your operating system and version: Ubuntu 20.04.4 LTS
reproducible steps (1 2 3...) that cause the issue including any required files: See above
what you expected, versus what happened: Expected to the file to successfully convert, possibly ignoring the unrecognized relationship type. Instead it failed.
any relevant screenshots and other outputs: See above

Note: This is my first reported issue of this type so I hope I've done it correctly :-)

Inconsistent Timestamp Representation in XML and JSON BOM Files

I have reported an Issue in the cyclonedx-dotnet repository regarding an inconsistent timestamp representation in the generated BOM files. The team has suggested that the issue may be related to the serialization process in the library. Here is the description of the issue:

I have noticed that the timestamp representation in the XML and JSON BOM files is inconsistent. While both formats are ISO 8601 conform, the XML BOM file contains a timestamp with a precision of up to 7 decimal places for the seconds fraction:

XML: 2024-05-17T15:50:31.6823708+00:00
JSON: 2024-05-17T15:50:31Z

In my opinion, this level of precision is not necessary. Furthermore, the second fractions more than 3 digits are not supported by the Python API datetime.fromisoformat(date_string) method.

While these differences are not incorrect, they can be confusing and may cause issues when processing the data. I would like to propose that we adopt a consistent timestamp representation across both file formats, ideally using the JSON timestamp format.

Thank you for considering this issue!

BOM version is required but should perhaps be optional

Related to CycloneDX/specification#78

Version is optional in XML and protobuf but required in JSON. If version remains optional, it should be changed to a nullable int.

v1.3 support for license and copyright evidence

TODO: Refactor CLI SBOM merging

This should also add support for merging:

• metadata
• services
• external references
• dependencies

Flat merging doesn't include compositions

hierarchical merging with an SBOM that contains no root level components causes exception

While attempting to merge multiple BOMs with cyclonedx merge --hierarchical I received:

Unhandled exception: System.ArgumentNullException: Value cannot be null. (Parameter 'collection')
   at System.Collections.Generic.List`1.InsertRange(Int32 , IEnumerable`1 )
   at CycloneDX.Utils.CycloneDXUtils.HierarchicalMerge(IEnumerable`1 boms, Component bomSubject)
   at CycloneDX.Cli.Commands.MergeCommand.Merge(MergeCommandOptions options)
   at System.CommandLine.Invocation.CommandHandler.GetExitCodeAsync(Object value, InvocationContext context)
   at System.CommandLine.Invocation.ModelBindingCommandHandler.InvokeAsync(InvocationContext context)
   at System.CommandLine.Invocation.InvocationPipeline.<>c__DisplayClass4_0.<<BuildInvocationChain>b__0>d.MoveNext()

I believe this is caused by the absence of the root level components property in one of the BOMs.

However, the cyclonedx validate command reports:

BOM validated successfully. 

Also, the spec doesn't indicate that the root level components property is required.

Flatmerge clobbers metadata.component

Flatmerge clobbers metadata.component when the new metadata is initiated and the only sub-element that persists is metadata.tool.

cyclonedx-dotnet-library/src/CycloneDX.Utils/Merge.cs

Line 62 in b5fbaf6

result.Metadata = new Metadata

If you can advise on how this should be handled, I'm happy to create a pull request with the change. Possibly, convert metadata.component to a List and then merge like metadata.tool?

This bug is linked to the following issues

#CycloneDX/cyclonedx-cli#218
#CycloneDX/cyclonedx-cli#219

Add additional TFM do STJ can be eliminated

Is your feature request related to a problem? Please describe.
I want to minimise dependencies in my project by utilising framework dependencies wherever possible

Describe the solution you'd like
System.Text.Json can become conditional and as such only added for the older frameworks.

Describe alternatives you've considered
Accept the additional dependency

Additional context
n/a

Incorrect hash support in v1.0 and v1.1 implementation

Originally reported against the CLI tool here CycloneDX/cyclonedx-cli#36

v1.3 support for compositions (known unknowns)

TODO: Refactor CLI diff functionality

CLI Convert command ignores documentDescribes and purl properties

A) We are trying to consume spdx files generated by https://github.com/microsoft/sbom-tool.
It generates files with following snippets:

  "documentDescribes": [
    "SPDXRef-RootPackage"
  ]

and

  "relationships": [
    {
      "relationshipType": "DESCRIBES",
      "relatedSpdxElement": "SPDXRef-RootPackage",
      "spdxElementId": "SPDXRef-DOCUMENT"
    }
  ],

both seems like equivalents for specifying what spdx file describes. According to https://github.com/spdx/spdx-spec/blob/development/v2.3/schemas/spdx-schema.json and spdx/spdx-spec#395, it seems that package-ref described in relatedSpdxElement ("SPDXRef-RootPackage") should be used as root package of resulting cyclonedx document, metadata.component. Currently it's ignored right now.
As I understand the only caveat here is a multiple components in documentDescribes/DESCRIBES relationships. Could this relationship propagated to metadata.component in case of single value?

B) Another thing that we have interest in is "externalRefs" property that are also completely ignored in case spdx->cyclonedx conversion, but filled in backward conversion.

I can provide PRs for both cases.
For A case I'd like to start discussion, maybe I don't see some things?
For B case I think it should be extended to support all "externalRefs".

CycloneDX -> SPDX conversion needs updating

In the CycloneDX -> SPDX conversion the table states "SPDX doesn't support designating a component as a particular type (i.e. library, framework, container)". This is false in SPDX 2.3. There is now "Primary Package Purpose" field which can denote the type of component as: APPLICATION | FRAMEWORK | LIBRARY | CONTAINER | OPERATING-SYSTEM | DEVICE | FIRMWARE | SOURCE | ARCHIVE | FILE | INSTALL | OTHER |

Validation failed: Expected value to match one of the values specified by the enum CVSSv3.1

We've incorporated they CycloneDX.Core library into our .net core application and are using it to serialize and de-serialize cyclondx JSON files. During our testing, we attempted to import an example JSON that has vulnerabilities on it and the cyclondx library is not recognizing it as a valid cyclonedx file (the web tool validates it as a valid file).

Upon digging into the logs, and doing further testing we've identified the following:

• The error message is "Validation failed: Expected value to match one of the values specified by the enum CVSSv3.1"
• It seems all of the scoring methods work, except for "CVSSv31" (e.g if you change the method to "CVSSv3" it works as expected")