Validation fails for valid JSON BOMs

[nscuro]

I'm using the CLI to ensure that cyclonedx-go and cyclonedx-gomod produce valid BOMs.

While implementing support for spec v1.4 in cyclonedx-go, I noticed that some JSON BOMs fail to validate without apparent reason.
The validation fails not only for the BOMs produced by the Go tooling, but also for the input test files from the specification repo.

When testing the offending files using other tools like https://www.jsonschemavalidator.net/ with the official schema, validation succeeds.

Steps to reproduce

# Clone specification repo
git clone https://github.com/CycloneDX/specification cdx-spec

# Validate all supposedly valid BOMs
for file in cdx-spec/tools/src/test/resources/1.4/valid-*.json; do echo "\n#### $file:" && cyclonedx validate --input-version v1_4 --input-file $file; done

This yields 3 failing validations:

#### tools/src/test/resources/1.4/valid-bom-1.4.json:
Validating JSON BOM...
Validation failed: 
#
BOM is not valid.

#### tools/src/test/resources/1.4/valid-release-notes-1.4.json:
Validating JSON BOM...
Validation failed: 
#
BOM is not valid.

#### tools/src/test/resources/1.4/valid-service-1.4.json:
Validating JSON BOM...
Validation failed: 
#
BOM is not valid.

The same happens when validating files within tools/src/test/resources/1.4/valid-*.json using --input-version v1_3, albeit only for valid-bom-1.3.json. I did not observe this behavior with XML BOMs.

[nscuro]

Oh, I see this is a known issue... 😅

https://github.com/CycloneDX/cyclonedx-dotnet-library/blob/main/tests/CycloneDX.Core.Tests/Json/v1.4/ValidationTests.cs#L53-L54

The schemas do not differ in a way that could explain this.

$ diff cyclonedx-specification/schema/bom-1.4.schema.json cyclonedx-dotnet-library/src/CycloneDX.Core/Schemas/bom-1.4.schema.json 
614c614
<           "$ref": "spdx.schema.json",
---
>           "$ref": "file://spdx.schema.json",
1692c1692
<       "$ref": "jsf-0.82.schema.json#/definitions/signature",
---
>       "$ref": "file://jsf-0.82.schema.json#/definitions/signature",

Could this be an issue with the JSON schema library used?

[nscuro]

I was able to debug this by lifting these restrictions of adding validation results to the output message.

Looks like the BOMs are indeed not valid and the JSON schema validator does its job as expected.
The test files are invalid, because the email fields within them do not contain valid email addresses...

The JSON schema validator used in cyclonedx-dotnet-library appears to be too strict WRT email addresses (idn-email):

File	Relevant ValidationResult	Offending Field Line
valid-bom-1.4.json	#/components/0/pedigree/commits/0/author/email: Value does not match format 'idn-email'	"email": ""
valid-release-notes-1.4.json	#/services/0/provider/contact/0/email: Value does not match format 'idn-email'	"email": "support@partner",
valid-service-1.4.json	#/services/0/provider/contact/0/email: Value does not match format 'idn-email'	"email": "support@partner",

In all other files, addresses are either valid (as in, have a TLD) or are simply not present at all. When adding a TLD, validation succeeds.

However, AFAICT, the RFCs behind idn-email do not require "dotted" domain names. A single host name should be fine as well, see for example https://datatracker.ietf.org/doc/html/rfc5321#section-2.3.5.

Is this a bug in the schema library then? Their implementation of idn-email validation is borrowed directly from Microsoft...

[haf-tech]

probably an other case

• BOM generated
• afterwards validate

and the generated BOM is not valid, without any modification

/cyclonedx add files --no-input --output-format json --output-file sbom.json --exclude /.git/**
Processing base path /workspace/source/src
Processing include pattern **/**
Processing exclude pattern /.git/**
Adding file .classpath
Adding file .project
Adding ...

/cyclonedx validate --input-file sbom.json --input-format json --input-version v1_4 --fail-on-errors
Validating JSON BOM...
Validation failed: Required properties [version] were not present
#/required
BOM is not valid.

[rseddon]

Another way to reproduce this is to use a BOM that has invalid licenses in it. This one did it for me, the validation fails with no message:

"licenses": [ { "license": { "id": "NOASSERTION", "url": "https://github.com/Humanizr/Humanizer/blob/main/LICENSE" } } ],

As a test, I changed to MIT and then the BOM validated.