we have not discussed yet, how to identify security relevance, for me it is security relevant, if it is safety (asset for us), a security function/control or part of communication

There are baselibs that are used in communication (lib/memory), so yes, security relevance must be mentioned somehow.

I'm wondering if it's the right way to set :security: YES to this stakeholder requirement.
E.g. REQ_07_02 from https://eclipse-score.github.io/score/main/process/process_areas/requirements_engineering/guidance/requirements_inspection_checklist.html#gd_chklst__req__inspection implies that all downstream requirements inherit YES. Currently, all baselibs feature requirements satisfy stkh_req__functional_req__base_libraries, but the :security: YES make sense not for all of them.

@masc2023, I need some guidance how to structure this.

I am not sure if we need a stakeholder requirements for this. Do the stakeholders care? I think it is a mere design decision and could be linked to existing stkh_req__quality__assumptions_and_dd.

I was not sure about this one. I added this stakeholder requirement for two reasons:

• Some of the base libs could be exposed to S-CORE users, e.g. a JSON lib could be used by applications.
• It's in interests of the user to limit code duplication and reduce effort for safety qualification. The base libs have even gotten an own swimlane in the S-CORE architecture diagram.

I'm also fine with removing stkh_req__functional_req__base_libraries and relinking the feature requirements to the stkh_req__quality__assumptions_and_dd. Will tracing of safety and security flags work fine? In the stkh_req__quality__assumptions_and_dd, these are QM and NO.