feat(cdx): Update to CycloneDX 1.6

[heubeck]

Depends on interlynk-io/sbomqs#267

[technolinator-sbom-as-a-service]

⚠ Vulnerability Report

Please consider this as a tentative appraisal, consult Dependency-Track for reliable results.

Artifact	Vulnerability	Severity (CVSS v3)	Recommendation
pkg:maven/org.bouncycastle/bcprov-jdk15on@1.70?type=jar	CVE-2024-30171 # Bouncy Castle affected by timing side-channel for RSA key exchange ('The Marvin Attack') An issue was discovered in Bouncy Castle Java TLS API and JSSE Provider before 1.78. Timing-based leakage may occur in RSA based handshakes because of exception processing. ## Related CVE(s) CGA-9727-f845-q3xw, CGA-j49x-3x3f-7v84, CVE-2024-30171	🟡 Medium (5.9)	Update to 1.78 or later
pkg:maven/org.bouncycastle/bcprov-jdk15on@1.70?type=jar	CVE-2023-33201 # Bouncy Castle For Java LDAP injection vulnerability Bouncy Castle provides the X509LDAPCertStoreSpi.java class which can be used in conjunction with the CertPath API for validating certificate paths. Pre-1.73 the implementation did not check the X.500 name of any certificate, subject, or issuer being passed in for LDAP wild cards, meaning the presence of a wild car may lead to Information Disclosure. A potential attack would be to generate a self-signed certificate with a subject name that contains special characters, e.g: CN=Subject*)(objectclass=. This will be included into the filter and provides the attacker ability to specify additional attributes in the search query. This can be exploited as a blind LDAP injection: an attacker can enumerate valid attribute values using the boolean blind injection technique. The exploitation depends on the structure of the target LDAP directory, as well as what kind of errors are exposed to the user. Changes to the X509LDAPCertStoreSpi.java class add the additional checking of any X.500 name used to correctly escape wild card characters.	🟡 Medium (5.3)	Update to 1.78 or later
pkg:maven/org.xmlunit/xmlunit-core@2.9.0?type=jar	CVE-2024-31573 # XMLUnit for Java has Insecure Defaults when Processing XSLT Stylesheets ### Impact When performing XSLT transformations XMLUnit for Java did not disable XSLT extension functions by default. Depending on the XSLT processor being used this could allow arbitrary code to be executed when XMLUnit is used to transform data with a stylesheet who's source can not be trusted. If the stylesheet can be provided externally this may even lead to a remote code execution. ## Patches Users are advised to upgrade to XMLUnit for Java 2.10.0 where the default has been changed by means of xmlunit/xmlunit@b81d48b ### Workarounds XMLUnit's main use-case is performing tests on code that generates or processes XML. Most users will not use it to perform arbitrary XSLT transformations. Users running XSLT transformations with untrusted stylesheets should explicitly use XMLUnit's APIs to pass in a pre-configured TraX TransformerFactory with extension functions disabled via features and attributes. The required setFactory or setTransformerFactory methods have been available since XMLUnit for Java 2.0.0. ### References Bug Report JAXP Security Guide	🔵 Low (2.0)	Update to 2.10.0 or later
pkg:maven/org.bouncycastle/bcprov-jdk15on@1.70?type=jar	CVE-2024-29857 # Bouncy Castle certificate parsing issues cause high CPU usage during parameter evaluation. An issue was discovered in ECCurve.java and ECCurve.cs in Bouncy Castle Java (BC Java) before 1.78, BC Java LTS before 2.73.6, BC-FJA before 1.0.2.5, and BC C# .Net before 2.3.1. Importing an EC certificate with crafted F2m parameters can lead to excessive CPU consumption during the evaluation of the curve parameters. ## Related CVE(s) CGA-p93x-49fc-v5m3, CGA-xx3m-cg2g-f46r, CVE-2024-29857	🟡 Medium (5.3)	Update to 1.78 or later
pkg:maven/org.bouncycastle/bcprov-jdk15on@1.70?type=jar	CVE-2024-30172 # Bouncy Castle crafted signature and public key can be used to trigger an infinite loop An issue was discovered in Bouncy Castle Java Cryptography APIs before 1.78. An Ed25519 verification code infinite loop can occur via a crafted signature and public key. ## Related CVE(s) CGA-9j68-hcjr-5xfx, CGA-vxwq-f5f4-5vmj, CVE-2024-30172	🟡 Medium (5.3)	Update to 1.78 or later
pkg:maven/net.minidev/json-smart@2.4.7?type=jar	CVE-2023-1370 # json-smart Uncontrolled Recursion vulnerabilty ### Impact Affected versions of net.minidev:json-smart are vulnerable to Denial of Service (DoS) due to a StackOverflowError when parsing a deeply nested JSON array or object. When reaching a ‘[‘ or ‘{‘ character in the JSON input, the code parses an array or an object respectively. It was discovered that the 3PP does not have any limit to the nesting of such arrays or objects. Since the parsing of nested arrays and objects is done recursively, nesting too many of them can cause stack exhaustion (stack overflow) and crash the software. ### Patches This vulnerability was fixed in json-smart version 2.4.9, but the maintainer recommends upgrading to 2.4.10, due to a remaining bug. ### Workarounds N/A ### References - https://www.cve.org/CVERecord?id=CVE-2023-1370 - https://nvd.nist.gov/vuln/detail/CVE-2023-1370 - https://security.snyk.io/vuln/SNYK-JAVA-NETMINIDEV-3369748	🟠 High (7.5)	Update to 2.4.9 or later
pkg:maven/com.jayway.jsonpath/json-path@2.7.0?type=jar	CVE-2023-51074 # json-path Out-of-bounds Write vulnerability json-path v2.8.0 was discovered to contain a stack overflow via the Criteria.parse() method.	🟡 Medium (5.0)	Update to 2.9.0 or later

[tollercode]

@heubeck as upstream dependency is resolved, any chance to get this merged?