Fix audit findings pmp prm + process update

MODULE.bazel

@@ -61,7 +61,7 @@ bazel_dep(name = "rules_java", version = "8.15.1")
 ###############################################################################
 bazel_dep(name = "score_tooling", version = "1.1.2")
 bazel_dep(name = "score_docs_as_code", version = "8.5.0")
-bazel_dep(name = "score_process_description", version = "2.1.2")
+bazel_dep(name = "score_process_description", version = "2.2.1")
 
 # Provide the tools from the devcontainer to Bazel
 bazel_dep(name = "score_devcontainer", version = "1.11.2", dev_dependency = True)

docs/platform_management_plan/problem_resolution.rst

@@ -127,13 +127,24 @@ and the state in the Projects dashboard view. The PR status is also used, if app
 part of the ISSUE. Add here the root cause and impact of the problem. Optionally state, who
 has to be informed or notified, if applicable, e.g. Safety Manager of a feature.
 
+Record whether notification is needed and why, including if not needed, in the Problem
+notifications part of the ISSUE. Identify affected parties. If notification is needed,
+record who was notified, when and how, e.g. a link to an issue comment with an explicit
+mention or another communication reference. Listing a recipient alone does not record a
+performed notification. For suspected vulnerabilities, follow the project's confidential
+reporting policy.
+
 Further information can be provided in the Supporting Information part of the ISSUE. Especially
 "How to reproduce" and "Error occurrence Rate" shall be documented, thus extra parts are provided
 for that in the ISSUE.
 
 To identify, in which version the problem occurred, use the Affected Version
 part of the ISSUE.
 
+:need:`[[title]] <gd_req__problem_attr_affected_versions>` additionally requires the first and
+last affected versions, including versions derived from the faulty version, to be documented.
+Record unknown affected versions as "under investigation" and update them during analysis.
+
 To provide solutions, use the Solution part of the ISSUE.
 
 :need:`[[title]] <gd_req__problem_attr_analysis_results>` is provided in the analysis
@@ -247,6 +258,9 @@ Notifications will be done for Feature Teams (:ref:`pmp_pm_feature_teams`) by
 - adding optionally the Module Safety Manager and/or Security Manager and/or Quality Manager, if applicable, to the assignees of the ISSUE and by
 - adding the Feature Team label to the ISSUE
 
+In addition, whether notification was needed and, if so, who was notified, when and how must be
+recorded in the Problem notifications part of the ISSUE.
+
 Otherwise, if no Problem Resolution is planned, the problem is rejected. To reject the Problem
 Report: Problem status: ``rejected`` set the ISSUE status to ``Closed as not planned``.
 
@@ -278,6 +292,12 @@ this case all linked ISSUEs or PRs are closed or merged, respectively.
 Especially the solution measures must be checked for their effectiveness and the argumentation
 is convincing.
 
+Where safety is affected, :need:`[[title]] <gd_req__problem_check_safety_closure>` requires a
+rationale supporting either an implemented safety measure with verified effectiveness, or an
+evaluation that the problem does not constitute an unreasonable risk. Per
+:need:`[[title]] <gd_req__problem_check_safety_rationale>` this rationale and its review result
+must be documented.
+
 :need:`gd_chklst__problem_cr_review` can help to verify whether it can be closed.
 
 If this is the case the ISSUE status is set to ``Closed``, otherwise the Projects status is set

docs/platform_management_plan/security_management.rst

@@ -177,10 +177,15 @@ Resource and milestone planning is done as defined in the :doc:`project_manageme
 *Tools*
 
 The whole development and thus all work products are located in Github. The development is automated as much as possible and follows the defined processes.
-Github issues are used as planning tool as well as security information (weakness, vulnerability) reporting and managing tool.
+Github issues are used as planning tool as well as security information (weakness, vulnerability) managing tool.
 The issue types and issue types workflows are described in the platform management plan.
 For security relevant issues types a "security" label is used.
 
+Suspected vulnerabilities shall not be reported through public Github issues. Initial vulnerability
+reporting follows the project's `Security Policy <https://github.com/eclipse-score/.github/blob/main/SECURITY.md>`_
+and is only tracked via Github issues once triaged and, where applicable, coordinated for disclosure
+(see :need:`doc__platform_vulnerability_mgt_plan`).
+
 Reporting of vulnerabilities is supported here: `Eclipse general vulnerability tracker <https://gitlab.eclipse.org/security>`_.
 
 Security Management Communication

docs/platform_management_plan/vulnerability_management.rst

@@ -106,12 +106,18 @@ Vulnerability Management Culture
 
 The S-CORE project embraces a culture of proactive vulnerability management and responsible disclosure.
 Every contributor and committer is encouraged to report potential vulnerabilities through appropriate channels.
-Channels for reporting include:
 
-* `Security at the Eclipse Foundation - Report a vulnerability <https://www.eclipse.org/security/>`_
-* GitHub issue tracking with appropriate labels (``security``, ``vulnerability``) following S-CORE Problem Resolution process (:need:`doc__platform_problem_resolution_plan`)
+Suspected vulnerabilities shall **not** be reported through public GitHub issues, discussions, or
+pull requests. Per the project's `Security Policy <https://github.com/eclipse-score/.github/blob/main/SECURITY.md>`_,
+initial reports shall use one of the following confidential channels:
+
+* A `confidential issue <https://gitlab.eclipse.org/security/vulnerability-reports/-/issues/new?issuable_template=new_vulnerability>`_ in the Eclipse Foundation Vulnerability Reporting Tracker
+* `GitHub private vulnerability reporting <https://docs.github.com/en/code-security/how-tos/report-and-fix-vulnerabilities/report-privately>`_
 * Direct communication with the project security manager or relevant module security manager of S-CORE
 
+Once triaged and, where applicable, coordinated for disclosure, a confirmed vulnerability is tracked
+as a security problem using GitHub issue tracking with appropriate labels (``security``, ``vulnerability``)
+following the S-CORE Problem Resolution process (:need:`doc__platform_problem_resolution_plan`).
 
 The project recognizes that vulnerabilities are an inherent aspect of software development and that transparent,
 efficient handling builds trust with users and the broader community.
@@ -188,7 +194,7 @@ Multiple channels are established for vulnerability identification:
 * Vulnerability reports from security researchers through Eclipse channels
 * :term:`CVE` monitoring for dependencies and related technologies
 * Security advisories from upstream projects and suppliers
-* Community-reported issues through GitHub issue tracking
+* Community-reported issues, submitted confidentially per the project's `Security Policy <https://github.com/eclipse-score/.github/blob/main/SECURITY.md>`_ and, once triaged, tracked through GitHub issue tracking
 
 SBOM Requirements
 ^^^^^^^^^^^^^^^^^
@@ -361,7 +367,11 @@ This ensures the integration with the existing project management infrastructure
 
 *Tracking System*
 
-All vulnerabilities are tracked using GitHub Issues as the **ONLY** mechanism per Problem Resolution process:
+Initial vulnerability reports are received confidentially per the project's
+`Security Policy <https://github.com/eclipse-score/.github/blob/main/SECURITY.md>`_ and are not
+tracked as public GitHub Issues until triaged and, where applicable, coordinated for disclosure.
+From that point, GitHub Issues are used as the **ONLY** mechanism per Problem Resolution process
+to track a confirmed vulnerability to closure:
 
 * **GitHub Issues** - Primary tracking system:
 
@@ -405,9 +415,11 @@ Related Platform Management Plans:
 
 External References:
 
+* `S-CORE Security Policy <https://github.com/eclipse-score/.github/blob/main/SECURITY.md>`_ - Authoritative vulnerability reporting channels
 * `Eclipse Foundation Security Policy <https://www.eclipse.org/security/policy/>`_
 * `Eclipse Foundation Security Team <https://www.eclipse.org/projects/handbook/#vulnerability-team>`_
 * `Eclipse Vulnerability Tracker <https://gitlab.eclipse.org/security>`_
+* `GitHub private vulnerability reporting <https://docs.github.com/en/code-security/how-tos/report-and-fix-vulnerabilities/report-privately>`_
 * `Eclipse CSI Security Handbook <https://eclipse-csi.github.io/security-handbook/>`_ - Security best practices for Eclipse SDV projects
 * `Eclipse CSI Security Handbook Branch Protection - Branch Protection <https://eclipse-csi.github.io/security-handbook/developer/branches.html>`_
 * `GitHub Dependabot Quickstart Guide <https://docs.github.com/en/code-security/tutorials/secure-your-dependencies/dependabot-quickstart-guide>`_