Add ML/AI model artifact (ML-BOM) support to RDX riskSet

[github-actions]

Motivation

CycloneDX v1.5+ formalized Machine-Learning / AI Bill-of-Materials (ML‑BOM / AI‑BOM) concepts (model provenance, dataset refs, model hashes, model cards) and multiple cloud vendors and OSS projects are shipping ML BOMs as first‑class artifacts. Automotive systems increasingly embed ML (perception, ADAS, infotainment, voice) and TARA must carry model provenance, dataset lineage, model-specific threats (poisoning/evasion), and lifecycle signals (model version, retraining date) so RDX consumers (safety, SOC, PSIRT, OEM suppliers) can reason about ML-specific attack vectors and assurance (CAL) for models.

Proposed change

Add a new optional top-level array riskSet.models[] (JSON + mirrored XSD) to capture ML/AI artefacts and link them to existing RDX objects. Keep this backward-compatible and optional (no existing documents break).

Schema-level changes (concrete):

• Add riskSet.models: array of model objects.
• Model object fields (recommended JSON Schema excerpts):
  • id (string, required)
  • title (string, required)
  • version (string)
  • modelType (enum: ["neural-network","decision-tree","svm","ensemble","transformer","other"])
  • modelCardRef (uri) — reference to human-readable model card (MD/HTML) or CycloneDX component/file entry
  • trainingDatasetRefs (array of uri or externalId) — links to dataset artifacts or dataset datasheets
  • inferenceEnvironment (object) — {os, runtime, libs[], hardwareConstraints}
  • hashes (array) — [{alg: "sha256"|"sha512"|..., value: string}] (align with CycloneDX hashes)
  • provenance (array) — content-addressable evidence references (see existing evidenceStore/attestations patterns or spec link) with fields {type, ref, created, signer}
  • modelRiskProfile (object) — {adversarialRisk: ["low"|"medium"|"high"], poisoningExposure: ["low"|"medium"|"high"], explainabilityScore: number (0-1), knownBiases: []}
  • associatedAttackScenarioIds (array of rdx threat/attackPath ids) — link model-specific attacks (e.g., evasion) into TARA
  • requiredCalLevel (string) and achievedCalLevel (string) — permit CAL mapping for models (reuses CAL fields defined in project)
  • lastRetrained (date-time), trainingDataVersion (string), deploymentId (string)
  • curation (array) — dataset datasheet or model card summary entries (small structured fields: intendedUse, limitations, performanceMetrics[])

Integration notes:

• Use CycloneDX ML‑BOM semantics for model/package linking (store model artifact as a CycloneDX component and reference it from riskSet.models[].modelCardRef or trainingDatasetRefs). This keeps non-invasive CycloneDX embedding (RDX-036 / RDX-002).
• Add example: examples/rdx-ml-model-example.json and cyclonedx-embedded variant showing a model component in the BOM and RDX models[] referencing the component via bomRefRef/componentRef.
• Update JSON Schema (spec/json/rdx.schema.json) and XSD (spec/xml/rdx.xsd) to include new model type with annotations and controlled vocabularies for modelType and adversarialRisk bands.
• Update methodology docs to include model threat patterns (poisoning, evasion, model extraction), mapping to TAF attacker profiles and CAL assessments.

Compatibility/backwards-compatibility:

• models[] is optional; documents without it remain valid.
• Ensure additionalProperties: true remains for extensions where required (per project policy), or add explicit extension points on model object.

Mapping to RDX requirements:

• RDX-002: Interoperate with SBOM/BOM ecosystems (extends CycloneDX integration for ML‑BOM)
• RDX-036: Support JSON encoding / CycloneDX embedding (extension of embedding patterns)
• RDX-052: JSON validation (schema must validate new items)
• RDX-021 / RDX-023 (indirect): AFR/Impact workflows will be able to reference models (relates)
• RDX-116 (new requirement): "RDX MUST support ML/AI model artifact metadata (models[]) including provenance, dataset references, model hashes, modelCardRef, inference environment, and model-specific attack linkage."

References

• CycloneDX ML/AI-BOM capability and guide (ML-BOM / AI-BOM): https://www.cyclonedx.org/capabilities/mlbom/ and CycloneDX v1.5 release notes. (see CycloneDX ML-BOM guide).
• CycloneDX Authoritative Guide to AI/ML-BOM (community guide). https://cyclonedx.org/guides/OWASP_CycloneDX-Authoritative-Guide-to-AI-ML-BOM-en.pdf
• Examples of ML-BOM adoption: Google Cloud / k8s AIBOM controller announcement. https://cloud.google.com/blog/products/identity-security/introducing-k8s-aibom-on-gke-for-automated-ai-bills-of-materials

Acceptance criteria

1. JSON Schema: spec/json/rdx.schema.json contains a new optional riskSet.models definition matching fields above and validates with ajv (include at least one example file examples/rdx-ml-model-example.json).
2. XSD: spec/xml/rdx.xsd contains equivalent model element definitions and the examples/rdx-ml-model-example.xml (or cyclonedx-embedded variant) validate against the XSD and are included in tools/validate.sh test set.
3. Examples: Add CycloneDX-embedded examples that show a CycloneDX component for model artifact and RDX models[] referencing the component via bomRefRef or equivalent.
4. Methodology: Update methodology/Methodology.md and add methodology/ML-Model-Integration.md describing mapping to CAL/TAF and attacker patterns for models.
5. Tests: CI run passes; new example files are added to templates/ and examples/ and included in tools/validate.sh so that ajv/xmllint validation passes.
6. Documentation: REQUIREMENTS.md updated with RDX-116 (new requirement) and a short rationale.

---

Generated by tools/ai_idea_scout.py via the AI Idea Scout workflow.
Review the proposal, refine the title/body/labels, and close if not desired.