search

CycloneDX / specification

OWASP CycloneDX is a full-stack Bill of Materials (BOM) standard that provides advanced supply chain capabilities for cyber risk reduction. SBOM, SaaSBOM, HBOM, AI/ML-BOM, CBOM, OBOM, MBOM, VDR, and VEX
https://cyclonedx.org/
Apache License 2.0
337 stars 57 forks source link

xml/json 1.5 spec differences? #456

Open divagant-martian opened 1 month ago

divagant-martian commented 1 month ago

Comparing the two specification I've found a couple differences.

json definitions

Last one is about Dependency in json it is defined as having two properties: ref and dependsOn, the first a refLinkType, second one a list of refLinkType

where refLinkType is defined in terms of refType. Both definitions are here: https://github.com/CycloneDX/specification/blob/8e131b1688ccfe41e1bfdd4b3280f33dcc06d04c/schema/bom-1.5.schema.json#L123-L132

https://github.com/CycloneDX/specification/blob/8e131b1688ccfe41e1bfdd4b3280f33dcc06d04c/schema/bom-1.5.schema.json#L1224-L1248

so dependsOn, in simple terms is a list of String

xml definitions

Here are the same definitions in xml:

refLinkType and refType look the same to me: https://github.com/CycloneDX/specification/blob/8e131b1688ccfe41e1bfdd4b3280f33dcc06d04c/schema/bom-1.5.xsd#L38-L55

but dependencies is defined as a sequence of dependencyType elements:

https://github.com/CycloneDX/specification/blob/8e131b1688ccfe41e1bfdd4b3280f33dcc06d04c/schema/bom-1.5.xsd#L1783-L1798

so it's a recursive type, in comparison to a list of Strings in json. Beside the simplification of String vs reftype etc, this makes it so that a dependency tree of multiple levels, say 3, it's invalid in json but valid in xml.

valid dependencies according to the test resources

Here there is a "valid xml dependency" according to the test resources: https://github.com/CycloneDX/specification/blob/8e131b1688ccfe41e1bfdd4b3280f33dcc06d04c/tools/src/test/resources/1.5/valid-compositions-1.5.xml#L28-L33

Note that the top dependency's children both are declared as dependency and have a ref attribute.

On the other side, the "valid json dependency" here https://github.com/CycloneDX/specification/blob/8e131b1688ccfe41e1bfdd4b3280f33dcc06d04c/tools/src/test/resources/1.5/valid-dependency-1.5.json#L26-L37

contains a dependsOn element "library-c" which clearly is not a dependency highlighted by the lack the required ref property. Taking into account that json schema supports recursion in arrays it looks to me like this could have been modeled the same way as the xml counterpart. Just to be sure, I tried an online json schema validator using what I would expect to get here

I've encountered multiple discrepancies between the specifications, fields that are attachment in one and textattachments in other, types that have one single field in one but two in other, etc.

This leaves me wondering.. are they not supposed to match? If not, should this be documented somewhere? What are the consequences of having a same bom that serialized in json and xml convey different information?

jkowalleck commented 1 month ago

Comparing the two specification I've found a couple differences.

JSON and XML do have different scopes and capabilities - technical wise. They are not the same, and therefore they have different capabilities and different solutions to the same problem. Therefore, the CycloneDX schema for JSON and XML are not the same, but they are a practical representation of the CycloneDX specification. The data models are more than just some types and structures, they have meaning/semantics stated in the element descriptions/annotations.

I tried to understand your concerns, but was not able to process your remarks and find any entry-point. Do you need further documentation? Do you want to propose an improvement? I don't understand. Sorry, could you condense your remarks to concrete questions?

divagant-martian commented 1 month ago

Thanks, as stated:

should this be documented somewhere? What are the consequences of having a same bom that serialized in json and xml convey different information?

The simple answer of "yes they are different" is worrisome from the perspective of an implementer since we were under the impression this is one standard but from a technical point of view this requires the modeling and validation of two different ones without any apparent reason. This is even more unexpected when what's modeled in XML is clearly achievable in Json as well but it's simply not done this way.

Let's begin with this specific discrepancy. Why is the dependency modeled differently in XML and Json when there is no limitation coming from the Json schema requiring this. Is this decision documented somewhere?

jkowalleck commented 1 month ago

we were under the impression this is one standard

This is still true.

CycloneDX is a standard. The standard is implemented in several target formats: XML/XSD, JSON/JsonSchema, ProtoBuff.