Motivation
REQUIREMENTS.md requires linkage to SBOM and HBOM data for supply-chain traceability, but the current schema offers only a single top-level bomRefRef string plus a few hashes. A vehicle/system TARA realistically needs references to SBOM, HBOM, SaaSBOM, VEX, VDR, test reports, architecture models, and CSMS evidence — and each link must be component-scoped, version-scoped, and identify the supplier. This is the foundation for CRA, R155, and ISO 21434 distributed-cybersecurity workflows.
Note: this is complementary to #44 (VEX/CSAF reachability) — that issue adds VEX statements and reachability semantics; this issue adds the generic typed-link substrate that VEX statements (and many other artifact types) can sit on.
Proposed change
- New top-level
linkedArtifacts[] in riskSet (JSON + XSD). Each entry:
{ id, type, format, uri, bomLink, hashes[], supplier, version, versionRange,
componentRefs[], notes }
type enum: sbom | hbom | saasbom | vex | vdr | testReport | securityCase | csmsEvidence | vulnerabilityAdvisory | architectureModel | regulatoryEvidence | cdxAttestation.
- BOM-Link semantics: accept full CycloneDX BOM-Link URNs in
bomLink and in componentRefs[].bomRef so cross-document refs are deterministic.
- Per-component linkage:
component.linkedArtifactRefs[] and control.linkedArtifactRefs[] so risks/controls can attach to specific BOM components, not just the whole document.
- Supplier / manufacturer identity:
linkedArtifact.supplier and component.supplier with optional cscrmIdentifier (DUNS, GLEIF LEI, internal supplier id).
- Version applicability:
versionRange supports SemVer ranges, NVD configuration-style match expressions, or a free applicabilityExpression.
- Examples: a new
examples/rdx-linked-artifacts-example.json showing SBOM + HBOM + VEX + test report + architecture model all linked from one RDX document, with component-scoped refs.
References
Acceptance criteria
Surfaced by external AI peer review; see chat transcript for full review text.
Motivation
REQUIREMENTS.mdrequires linkage to SBOM and HBOM data for supply-chain traceability, but the current schema offers only a single top-levelbomRefRefstring plus a few hashes. A vehicle/system TARA realistically needs references to SBOM, HBOM, SaaSBOM, VEX, VDR, test reports, architecture models, and CSMS evidence — and each link must be component-scoped, version-scoped, and identify the supplier. This is the foundation for CRA, R155, and ISO 21434 distributed-cybersecurity workflows.Note: this is complementary to #44 (VEX/CSAF reachability) — that issue adds VEX statements and reachability semantics; this issue adds the generic typed-link substrate that VEX statements (and many other artifact types) can sit on.
Proposed change
linkedArtifacts[]inriskSet(JSON + XSD). Each entry:typeenum:sbom|hbom|saasbom|vex|vdr|testReport|securityCase|csmsEvidence|vulnerabilityAdvisory|architectureModel|regulatoryEvidence|cdxAttestation.bomLinkand incomponentRefs[].bomRefso cross-document refs are deterministic.component.linkedArtifactRefs[]andcontrol.linkedArtifactRefs[]so risks/controls can attach to specific BOM components, not just the whole document.linkedArtifact.supplierandcomponent.supplierwith optionalcscrmIdentifier(DUNS, GLEIF LEI, internal supplier id).versionRangesupports SemVer ranges, NVD configuration-style match expressions, or a freeapplicabilityExpression.examples/rdx-linked-artifacts-example.jsonshowing SBOM + HBOM + VEX + test report + architecture model all linked from one RDX document, with component-scoped refs.References
REQUIREMENTS.md— SBOM/HBOM linkage requirementAcceptance criteria
linkedArtifacts[]added in JSON Schema and XSD with the type enum abovebomLinkaccepts and validates CycloneDX BOM-Link URNsbomRefRefcontinues to validate; methodology docs mark it secondary tolinkedArtifacts[]Surfaced by external AI peer review; see chat transcript for full review text.