Skip to content

[EPIC] Upgrade CBOM output from CycloneDX 1.6 to 1.7 #505

Description

@n1ckl0sk0rtge

Epic: Upgrade CBOM output from CycloneDX 1.6 to 1.7

Why?

CycloneDX 1.7 was released on 2025-10-21 and ratified as ECMA-424 2nd Edition in December 2025. It significantly matures the CBOM part of the specification and deprecates several fields the plugin currently emits. While our 1.6 output remains valid under 1.7, all deprecated fields are flagged for removal in a future spec version, so migrating now keeps generated CBOMs future-proof and interoperable with 1.7-aware consumers (e.g. Dependency-Track, CBOMkit).

Key 1.7 changes affecting this plugin:

  • Cryptography Registry (cryptography-defs.schema.json): a new algorithmFamily enum (93 standardized family identifiers such as AES, ECDSA, ML-KEM) and a new ellipticCurve enum (246 namespaced curve identifiers such as nist/P-256). The free-text curve field is deprecated.
  • relatedCryptographicAssets: a generic {type, ref} relationship list replacing the ad-hoc bom-ref fields, which are all deprecated: certificateProperties.signatureAlgorithmRef, certificateProperties.subjectPublicKeyRef, relatedCryptoMaterialProperties.algorithmRef, protocolProperties.cryptoRefArray.
  • algorithmProperties: new key-wrap primitive.
  • certificateProperties: lifecycle timestamps and state, serialNumber, fingerprint, structured certificateExtensions; certificateExtension (file extension) is deprecated in favor of certificateFileExtension.
  • protocolProperties: new protocol types dtls, quic, eap-aka, eap-aka-prime, prins, 5g-aka; IKEv2 transform types now take typed enum values instead of crypto-ref arrays.

No dependency bump is required: the output module already uses cyclonedx-core-java 12.2.0, which supports 1.7 serialization and validation.

Tasks

  • Switch the emitted schema version from Version.VERSION_16 to Version.VERSION_17 in output/.../CBOMOutputFile.java and verify all existing output tests still pass
  • Map the mapper/enricher algorithm model onto the 1.7 algorithmFamily enum and emit it in algorithmProperties (likely in the enricher, where algorithm knowledge lives)
  • Emit the new namespaced ellipticCurve enum values instead of the deprecated free-text curve field (keep curve during a transition period if consumers need it)
  • Replace deprecated bom-ref fields (signatureAlgorithmRef, subjectPublicKeyRef, algorithmRef, protocolProperties.cryptoRefArray) with relatedCryptographicAssets
  • Use the new key-wrap primitive for key-wrap algorithms currently mapped to a fallback primitive
  • Rename emitted certificateExtension to certificateFileExtension; evaluate populating new certificateProperties fields (serialNumber, fingerprint, certificateExtensions) where detection provides the data
  • Review protocol translation for the new protocol types (dtls, quic, …) and map detections currently bucketed as other/unknown
  • Update schema validation in tests to validate against bom-1.7.schema.json, and refresh reference CBOMs in test resources
  • Update README.md and docs that state the produced CBOM version

Acceptance Criteria

  • Generated CBOMs declare "specVersion": "1.7" and validate against bom-1.7.schema.json
  • No deprecated 1.7 fields (curve, signatureAlgorithmRef, subjectPublicKeyRef, algorithmRef, protocolProperties.cryptoRefArray, certificateExtension) are emitted
  • Elliptic curves are emitted as registry identifiers from the ellipticCurvesEnum (e.g. nist/P-256)
  • Algorithms carry an algorithmFamily from the registry enum where a mapping exists
  • All existing detection and output tests pass across the java, python, go, mapper, enricher, and output modules

References

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Projects

    Status
    No status

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions