From 8b9a56423991dea54bd013e27a4729601e890a25 Mon Sep 17 00:00:00 2001 From: "Schu, Markus" Date: Fri, 16 Oct 2026 09:49:39 +0200 Subject: [PATCH 1/3] fix audit findings --- .../problem_resolution.rst | 20 +++++++++++++++++++ 1 file changed, 20 insertions(+) diff --git a/docs/platform_management_plan/problem_resolution.rst b/docs/platform_management_plan/problem_resolution.rst index 31607ac0ac0..09524c5a2f3 100644 --- a/docs/platform_management_plan/problem_resolution.rst +++ b/docs/platform_management_plan/problem_resolution.rst @@ -127,6 +127,13 @@ 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. @@ -134,6 +141,10 @@ for that in the ISSUE. To identify, in which version the problem occurred, use the Affected Version part of the ISSUE. +:need:`[[title]] ` 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]] ` 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]] ` 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]] ` 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 From 85734cb8e227b7addbe7685fb0f1ca5b0d42a362 Mon Sep 17 00:00:00 2001 From: "Schu, Markus" Date: Fri, 16 Oct 2026 17:23:27 +0200 Subject: [PATCH 2/3] Align vulnerability reporting with SECURITY.md confidential channels --- .../security_management.rst | 7 +++++- .../vulnerability_management.rst | 22 ++++++++++++++----- 2 files changed, 23 insertions(+), 6 deletions(-) diff --git a/docs/platform_management_plan/security_management.rst b/docs/platform_management_plan/security_management.rst index 74195dca839..6b100b61d39 100644 --- a/docs/platform_management_plan/security_management.rst +++ b/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 `_ +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 `_. Security Management Communication diff --git a/docs/platform_management_plan/vulnerability_management.rst b/docs/platform_management_plan/vulnerability_management.rst index ec370595245..f816ea03204 100644 --- a/docs/platform_management_plan/vulnerability_management.rst +++ b/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 `_ -* 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 `_, +initial reports shall use one of the following confidential channels: + +* A `confidential issue `_ in the Eclipse Foundation Vulnerability Reporting Tracker +* `GitHub private vulnerability reporting `_ * 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 `_ 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 `_ 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 `_ - Authoritative vulnerability reporting channels * `Eclipse Foundation Security Policy `_ * `Eclipse Foundation Security Team `_ * `Eclipse Vulnerability Tracker `_ +* `GitHub private vulnerability reporting `_ * `Eclipse CSI Security Handbook `_ - Security best practices for Eclipse SDV projects * `Eclipse CSI Security Handbook Branch Protection - Branch Protection `_ * `GitHub Dependabot Quickstart Guide `_ From 79829ef0add353693631536093b6be4d8ecc5752 Mon Sep 17 00:00:00 2001 From: "Schu, Markus" Date: Wed, 21 Oct 2026 16:11:35 +0200 Subject: [PATCH 3/3] update MODULE --- MODULE.bazel | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/MODULE.bazel b/MODULE.bazel index 27a907d4f0b..fce323eabf6 100644 --- a/MODULE.bazel +++ b/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)