Where should threat-model-specific context live in CycloneDX 2.0?

[P3tra-WP]

I am evaluating how an OWASP Threat Model Library document can be represented in CycloneDX 2.0 without losing threat-model-specific meaning.

The open PR #1034 contains an initial implementation proposal, but I would like architectural feedback before treating its field placement as final.

Use cases

A threat-model document may describe only part of a wider system.

For example, a team may model a new feature while its system diagram still includes authentication, shared infrastructure, or external services that are intentionally outside the threat-model scope. Consumers need to distinguish the modelled subject and boundary from surrounding context retained for architectural completeness.

The OWASP Threat Model Library also represents:

• model version, release, freeze, and review information
• a threat event that triggers or realizes a threat
• whether an actor is malicious and how applicable that actor is to the organization
• qualitative risk matrices, including matrix-specific result bands such as very_low and very_high

Existing CycloneDX Structures

CycloneDX 2.0 already provides strong reusable structures for components, blueprints, threats, scenarios, threat profiles, controls, risks, and generic score methodologies.

The questions are not whether these concepts should duplicate existing structures, but:

1. Where should document-level threat-model scope and lifecycle context live?
2. Should they be part of a threat-model-specific structure, a blueprint/behavior structure, or another existing domain?
3. Where should reusable qualitative risk matrices live and how should scores reference their matrix-specific result bands?
4. Is scenario-level placement appropriate for malicious intent and organization applicability, given that existing threat profiles are intended for durable actor characteristics?

I would appreciate guidance on the appropriate CycloneDX 2.0 architectural home for these concepts before continuing the implementation discussion in PR #1034.