Skip to content

CycloneDX 2.0 - Constrain Properties to Applicable Types #638

Description

@stevespringett

Problem

In CycloneDX 1.x, several properties are loosely defined and may appear on types where they are semantically invalid. For example:

  • cryptoProperties is intended only for cryptographic assets (e.g. cryptographic libraries, keys, algorithms), but is currently allowed on any component.
  • modelCard, evaluationMeasures, and other AI/ML-specific metadata may appear on non-AI components.

This flexibility was useful during schema evolution, but introduces:

  • Semantic ambiguity
  • Inconsistent SBOM usage
  • Misleading tool or ecosystem behavior

Goal for 2.0

Enforce contextual constraints on properties by:

  • Restricting cryptoProperties to cryptographic asset types (e.g. library, firmware, machine-learning-model, etc.)
  • Limiting AI/ML-specific fields (modelCard, evaluationMeasures, datasets, etc.) to components of type: machine-learning-model
  • This ticket is not limited to cryptoProperties or modelCard and may be applicable to other properties in v1.6 or which will be introduced in v1.7.

Proposal

Update the CycloneDX 2.0 schema to:

  1. Apply oneOf or if/then/else constraints where schema logic permits
  2. Scope optional fields to valid component.type or service.category values

As written, this is not a breaking change and the documentation in the current specification clearly states the purpose and when to use these properties. This ticket is for the enforcement of that behavior through minor changes in schema structure.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Labels

Type

Projects

No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions