Add safety integrity level schema support

[devashridatta-dotcom]

Summary

Adds the small first-class safety-integrity classification discussed in #954 for the CycloneDX 2.0 schema line.

This PR is intentionally narrow. It does not try to move the full SRAP vocabulary into CycloneDX core. Instead, it implements the piece that appears to be missing from the existing 2.0 model: a standards-aligned, machine-readable way to express safety integrity classification in context.

What changes

• Adds a shared safetyIntegrityLevel schema definition with scheme-gated levels for ISO-26262, IEC-61508, DO-178C, IEC-62304, and EN-50128, plus a custom scheme option.
• Allows safetyIntegrityLevels on blueprint asset classifications and requirements, keeping the assertion scoped to a system/context carrier rather than treating it as an intrinsic component property.
• Adds hazard-analysis and safety-case external reference types for supporting safety evidence.
• Adds EPSS as a vulnerability score method.
• Adds safety as a requirement type so safety requirements can be identified without relying only on free text.

Why this is the narrow CycloneDX-native path

The discussion in #954 clarified that CycloneDX 2.0 already has first-class structures for most SRAP needs:

• risks for safety impact and risk linkage.
• perspectives and blueprints for system/context views.
• criticality for contextual asset importance.
• vulnerabilities and VEX analysis for vulnerability impact.
• declarations, claims, attestations, and evidence for assertion and evidence chains.
• definitions.requirements for safety requirements.

The remaining core gap is safety integrity classification: ASIL, SIL, DAL, IEC 62304 software safety class, and similar scheme-specific levels. This PR focuses on that gap.

Relationship to SRAP

SRAP-style concepts such as SafetyContextRelationship, ChangeTrigger, ChangeImpactAnalysis, RequirementVerification, and EvidenceRelationship can be represented today using existing CycloneDX structures and, where needed, profile-owned terms such as srap:* properties or structured ext:* extensions.

Those broader SRAP terms should remain in the profile layer unless TC54 decides that any of them belong in CycloneDX core. This PR keeps the CycloneDX schema change small while preserving alignment with SPDX safety work.

Automotive/Product Security and Risk context

This also aligns with the emerging Product Security and Risk Working Group direction. Automotive is a good first use case because ISO 26262 and ASIL are common safety integrity concepts, and ASRG's move toward CycloneDX for automotive risk representation makes a consistent safety integrity vocabulary useful for downstream tooling and policy engines.

Validation

• Parsed all touched JSON schema files successfully.
• pnpm run test:v2.0:t2-json-schema-semantic passes.
• Targeted AJV checks for safetyIntegrityLevel pass:
  • ISO-26262 + asil-d accepted.
  • ISO-26262 + sil-3 rejected.
  • IEC-62304 + class-c accepted.
  • Custom scheme object accepted.

Note: pnpm run test:v2.0:t1-json-schema-validate and the functional test currently fail on a clean upstream 2.0-dev checkout with the same unresolved reference:

model/cyclonedx-common-2.0.schema.json#/$defs/extensibleProperties

So that failure appears inherited from the current 2.0-dev test wiring rather than introduced by this change.

RFC question

Is this narrow safetyIntegrityLevels[] change the right candidate to take through the 30-day RFC period, with the broader SRAP vocabulary handled as profile guidance or a companion schema?