Proposal: correlate SRAC safety-relevance assertions with generated SBOMs #5339

What would you like to be added:

An optional experimental workflow for correlating a Safety Relevance Assertion Capability (SRAC) sidecar with components cataloged by Syft.

SRAC is a format-neutral, externally authored record containing component safety relevance, evidence and review state, plus optional change-impact analysis. Syft would validate and transport the record; it would not infer safety relevance or approve a safety decision.

One possible CLI shape is:

syft <target> -o cyclonedx-json=sbom.json \
  --srac assertions.srac.json \
  --srac-report srac-enrichment.json

The exact interface is only illustrative. A minimal experiment would:

1. validate the SRAC schema, integrity metadata, and internal references;
2. correlate assertions deterministically with cataloged packages using package URL, SBOM reference, version, or artifact digest;
3. produce a companion report with matched, unmatched, ambiguous, invalid, and stale assertions;
4. preserve assertion provenance and externally authored lifecycle/decision fields without changing their meaning; and
5. optionally add a resolvable, integrity-protected external reference to the companion sidecar in supported SBOM output formats.

Suggested acceptance criteria:

• The same sidecar can be used with SPDX and CycloneDX JSON output.
• Each match records the identifier and rule used.
• Invalid, unmatched, ambiguous, and stale records are explicit and fail closed.
• The original assertion and digest remain available for audit.
• Syft never creates or changes a safety classification, impact decision, or approval.
• A synthetic example and tests cover successful and negative cases.

Why is this needed:

Syft accurately answers which software components are present, but downstream users of safety-relevant systems also need portable, reviewable context describing whether an authorized engineering process classified a component as safety-relevant. Today that context typically stays in lifecycle tools and does not travel with the SBOM.

Keeping SRAC as a linked companion artifact avoids inventing non-standard fields in current SPDX or CycloneDX documents while making the record reproducible and available to vulnerability scanners, policy engines, integrators, and auditors.

Additional context:

An Eclipse S-CORE prototype demonstrates schema validation, SPDX/CycloneDX correlation, integrity checks, enrichment reports, change-impact records, and fail-closed behavior:

• Eclipse tracking issue: Proposal: Define a minimum SRAC profile for an S-CORE pilot eclipse-score/score#3282
• CycloneDX discussion: Proposal: CycloneDX Safety Perspective for SRAC and safety impact workflows CycloneDX/specification#1122

The mapping follows current SPDX 3.1-development FunctionalSafety concepts and explores a CycloneDX-compatible external assertion carrier. These are development/proposal references, not claims of released normative support.