Skip to content

Proposal: Define a minimum SRAC profile for an S-CORE pilot #3282

Open
eclipse-score/reference_integration
#370
Open
Proposal: Define a minimum SRAC profile for an S-CORE pilot#3282
eclipse-score/reference_integration
#370
Assignees
FScholPer

Description

@devashridatta-dotcom
devashridatta-dotcom
opened on Sep 23, 2026

Summary

This issue proposes the first step of a pilot for integrating the Safety Relevance Assertion Capability (SRAC) with Eclipse S-CORE.

SRAC provides a machine-readable way to associate a software component with:

  • its safety relevance and classification;
  • the rationale behind that classification;
  • applicable safety requirements;
  • supporting evidence and verification results;
  • review and approval information.

The intention is to complement—not replace—the existing S-CORE safety lifecycle and safety case.

Motivation

Safety information is normally distributed across requirements, analyses, test results, reviews, and release artifacts. A portable assertion could make the safety relevance of a component easier to exchange and review alongside software supply-chain information.

Related standardization work:

Proposed Step 1: Alignment

Before implementing tooling, jointly define a small pilot scope:

  1. Select one public S-CORE component or example component.
  2. Identify the minimum SRAC assertion fields required for that component.
  3. Map those fields to existing S-CORE lifecycle and safety artifacts.
  4. Identify the owners and reviewers for the resulting assertion.
  5. Record open semantic or governance questions.

Candidate minimum fields include:

  • component identifier and version;
  • safety relevance or classification;
  • classification rationale;
  • applicable safety requirements;
  • links to evidence and verification results;
  • assertion author, reviewer, status, and timestamp.

Expected output

A short, reviewed mapping document containing:

  • the selected pilot component;
  • the agreed minimum SRAC profile;
  • the corresponding S-CORE source artifacts;
  • ownership and review responsibilities;
  • follow-up issues for implementation and validation.

Out of scope for this first step

  • Changing the existing S-CORE safety process.
  • Implementing a complete SRAC toolchain.
  • Duplicating the safety case inside an SBOM.
  • Committing S-CORE to a new standard before the pilot is evaluated.

Acceptance criteria

  • One S-CORE pilot component is selected.
  • Minimum assertion fields are agreed.
  • Each field is mapped to an authoritative S-CORE artifact or identified as a gap.
  • A safety reviewer and technical owner are identified.
  • Implementation and validation follow-up issues are created.

Questions for the S-CORE community

  • Which component would be most suitable for the pilot?
  • Should this work be coordinated through the main S-CORE repository, process-description work, or another repository?
  • Who should participate in the initial alignment review?

Activity

  1. FScholPer commented on Sep 23, 2026

    @FScholPer
    FScholPer
    on Sep 23, 2026
    Contributor

    @devashridatta-dotcom Thanks for you proposal. Tomorrow we have our Process Community Meeting. If you want you can present the proposal there as there are our safety managers. Just take a look in the eclipse calendar(09:30-10:30am CET)

  2. devashridatta-dotcom commented on Sep 23, 2026

    @devashridatta-dotcom
    devashridatta-dotcom
    on Sep 23, 2026
    Author

    Yes, I would be happy to present the proposal tomorrow during the Process Community Meeting from 09:30 to 10:30 am CET. Thank you for the invitation. I will check the Eclipse calendar for the meeting details and look forward to the discussion with the safety managers.

  3. devashridatta-dotcom commented on Sep 24, 2026

    @devashridatta-dotcom
    devashridatta-dotcom
    on Sep 24, 2026
    Author

    Thank you for the discussion and support during the Process Community Meeting. I would like to proceed with SRAC through the formal Feature & Enhancement Proposal process and continue as the proposal author.

    Can this issue be used as the FEP tracking issue and updated to the Feature Request type with the fep and fep:needs-shepherd labels?

    @FScholPer, would you be willing to act as the formal Shepherd for this FEP, or could you recommend an appropriate Architecture Community Shepherd?

    Once confirmed, I will prepare the FEP draft and associated pull request following the S-CORE template.

  4. devashridatta-dotcom commented on Sep 24, 2026

    @devashridatta-dotcom
    devashridatta-dotcom
    on Sep 24, 2026
    Author

    Draft minimum SRAC profile — v0.1

    To progress the proposed pilot while the FEP route and Shepherd are being confirmed, I have prepared the following initial minimum SRAC profile for community review.

    This is a discussion draft. It is not an approved S-CORE specification.

    Proposed minimum fields

    Field Purpose Required
    Component identifier Uniquely identifies the component Yes
    Component version Identifies the assessed version Yes
    Safety relevance Records whether and how the component is safety-relevant Yes
    Classification Records the applicable safety classification, where available Conditional
    Classification rationale Explains the basis for the safety-relevance decision Yes
    Applicable safety requirements Links the assertion to relevant requirements Conditional
    Evidence references Links to analyses, tests, reviews or other supporting evidence Yes
    Verification status Records the current verification state Yes
    Assertion author Identifies who created the assertion Yes
    Reviewer or approver Identifies the responsible reviewer Conditional
    Assertion status Draft, reviewed, approved, superseded or withdrawn Yes
    Timestamp Records when the assertion was issued or updated Yes

    Proposed pilot principles

    • SRAC complements rather than replaces the S-CORE safety lifecycle and safety case.
    • The assertion communicates context-specific safety relevance and evidence; it does not certify or independently qualify a component.
    • Evidence should be referenced rather than duplicated inside the assertion.
    • The first pilot should use one public S-CORE component.
    • A versioned sidecar representation can be evaluated first, with linkage from SPDX or CycloneDX where applicable.
    • The profile should remain small enough to implement and review without significant effort from the S-CORE team.

    Questions for review

    1. Are any fields missing from the minimum profile?
    2. Which fields should be mandatory for the first pilot?
    3. Which S-CORE artifacts should be authoritative for each field?
    4. Which public S-CORE component would be most suitable for the pilot?
    5. Who should serve as the component owner and safety reviewer?

    Once a Shepherd and pilot component are confirmed, I can convert this into the formal FEP format and prepare the field-to-artifact mapping.

  5. devashridatta-dotcom commented on Sep 25, 2026

    @devashridatta-dotcom
    devashridatta-dotcom
    on Sep 25, 2026
    Author

    Progress update:

    The initial SRAC sidecar proof of concept is now available as a draft integration PR:

    The PoC includes:

    • A minimum experimental SRAC profile and JSON schema
    • A non-authoritative Persistency KVS example
    • SPDX and CycloneDX semantic mappings
    • Matching and validation tooling
    • Tests and integration documentation

    All CI checks have passed, including code quality, documentation, QNX build and integration testing, and the Eclipse ECA check.

    The remaining decisions are:

    1. Whether SRAC should remain a TSF-style sidecar or requires a new development requirement.
    2. Selection of the component owner and safety reviewer for the Persistency KVS pilot.
    3. Confirmation of the pilot acceptance criteria and when the draft PR should move to formal review.

    Once these points are confirmed, the next step will be to run the pilot against an actual SBOM produced by eclipse-score/sbom-tool.

  6. devashridatta-dotcom commented on Sep 25, 2026

    @devashridatta-dotcom
    devashridatta-dotcom
    on Sep 25, 2026
    Author

    Pilot finding from real sbom-tool output:

    The SRAC sidecar PoC has now been exercised against an actual product SBOM generated by the current S-CORE //:sbom flow.

    Findings:

    • The generated SBOM contains 162 packages.
    • Persistency is present in the SBOM as SPDXRef-score-persistency-unknown.
    • The emitted package URL is currently pkg:github/eclipse-score/score_persistency@unknown.
    • The SRAC enrichment result for the Persistency KVS pilot is matched.
    • Because the SBOM version is currently unknown, the pilot uses an explicit known_good.json binding for this first evaluation.
    • The matcher only accepts the assertion when the module name, repository identity and pinned Persistency commit resolve together. It does not accept an unknown version by component name alone.

    Interpretation:

    This confirms that SRAC can initially be evaluated as a sidecar on top of the existing sbom-tool output without requiring sbom-tool changes first. It also identifies one concrete integration gap: for stronger native SBOM binding, the generated SBOM should eventually carry a concrete component version, commit or other stable identity for Persistency instead of unknown.

    Current artifacts:

    The next review decisions remain:

    1. Whether this should continue as a TSF-style sidecar or become a new development requirement.
    2. Who should be the component owner and safety reviewer for the Persistency KVS pilot.
    3. Whether the pilot acceptance criteria should include improving the SBOM identity emitted by sbom-tool for this component.
  7. FScholPer
    linked a pull request that will close this issuefeat: add SRAC sidecar proof of concept #370on Oct 5, 2026
  8. FScholPer
    self-assigned this
    on Oct 5, 2026

  9. devashridatta-dotcom commented on Oct 8, 2026

    @devashridatta-dotcom
    devashridatta-dotcom
    on Oct 8, 2026
    Author

    Policy-aware safety traceability use cases

    Following the discussion about keeping traceability rules in one place and defining concrete problems before extending the model, I opened a documentation PR with an initial use-case matrix:

    • Tier 1 to OEM to independent-assessment handover;
    • incremental traceability during internal feature development;
    • responsibility transfers between teams and legal entities;
    • jurisdiction and regulatory-policy checkpoints;
    • OSS component intake and OEM/integrator responsibility;
    • incremental checks, periodic full evaluation, and tool-confidence considerations; and
    • an end-to-end demonstrator with objective acceptance criteria.

    Documentation PR: eclipse-score/reference_integration#393

    The document separates automated validation and candidate-policy detection from human safety, legal, compliance, assessment, and approval decisions. It is an initial discussion document, not an adopted S-CORE process or metamodel.

    For the traceability-tooling workshop, the proposed review questions are:

    1. Are the use cases and responsibility boundaries correct?
    2. Which scenarios should S-CORE support?
    3. What minimum node, relationship, provenance, policy, and constraint model is common to Sphinx-Needs, Dependable Elements, and TRLC/Lobster?
    4. Which checks are incremental, which require a complete evaluation, and which require a human checkpoint?
    5. Where should the canonical metamodel, mappings, and validation policies be maintained?
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions