From eafa8049ea1143f3cc8e89331ef14bf7e1ac9db1 Mon Sep 17 00:00:00 2001 From: "markus.schu" Date: Mon, 16 Feb 2026 14:44:39 +0100 Subject: [PATCH 1/3] initial version for vulnerability management document vulnerability management in relation to security management and problem resolution Resolves: #https://github.com/eclipse-score/score/issues/1941 --- docs/platform_management_plan/index.rst | 1 + .../vulnerability_management.rst | 363 ++++++++++++++++++ 2 files changed, 364 insertions(+) create mode 100644 docs/platform_management_plan/vulnerability_management.rst diff --git a/docs/platform_management_plan/index.rst b/docs/platform_management_plan/index.rst index b75d3fdbc9..dd8a91f49b 100644 --- a/docs/platform_management_plan/index.rst +++ b/docs/platform_management_plan/index.rst @@ -37,6 +37,7 @@ Platform Management Plan tool_management release_management problem_resolution + vulnerability_management change_management software_verification documentation_management diff --git a/docs/platform_management_plan/vulnerability_management.rst b/docs/platform_management_plan/vulnerability_management.rst new file mode 100644 index 0000000000..9e6df6553b --- /dev/null +++ b/docs/platform_management_plan/vulnerability_management.rst @@ -0,0 +1,363 @@ +.. + # ******************************************************************************* + # Copyright (c) 2026 Contributors to the Eclipse Foundation + # + # See the NOTICE file(s) distributed with this work for additional + # information regarding copyright ownership. + # + # This program and the accompanying materials are made available under the + # terms of the Apache License Version 2.0 which is available at + # https://www.apache.org/licenses/LICENSE-2.0 + # + # SPDX-License-Identifier: Apache-2.0 + # ******************************************************************************* + +.. document:: Platform Vulnerability Management Plan + :id: doc__platform_vulnerability_mgt_plan + :status: draft + :safety: ASIL_B + :security: YES + :realizes: wp__platform_security_plan, wp__prm_plan + :tags: platform_management + +Vulnerability Management / Platform Vulnerability Management Plan +----------------------------------------------------------------- + +.. note:: + **Process Integration Summary** + + Vulnerability management in S-CORE is fully integrated with the :doc:`problem_resolution` process. + All vulnerabilities are tracked as **security** problems through GitHub Issues following the standardized + Problem Resolution workflow: **Create** → **Analyze** → **Implement** → **Close**. + + This integration provides: + + * Unified tracking for all project problems including vulnerabilities + * Consistent workflow with clear roles (:need:`rl__committer`, :need:`rl__contributor`) + * Standardized templates (:need:`gd_temp__problem_template`) and checklists (:need:`gd_chklst__problem_cr_review`) + * Traceability through GitHub Issues and linked Pull Requests + * Status visibility via GitHub Projects dashboard + + See :need:`doc__platform_problem_resolution_plan` for complete workflow details. + +Purpose ++++++++ + +The main purpose of the vulnerability management plan is to: + +* establish and maintain a systematic approach for managing vulnerabilities throughout the lifecycle of the S-CORE platform +* adhere to ISO SAE 21434 vulnerability management requirements where applicable +* ensure timely detection, analysis, and remediation of vulnerabilities + + +Objectives and Scope +++++++++++++++++++++ + +Vulnerability Management Goals +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Proactive identification and management of vulnerabilities in the S-CORE platform +* Rapid response to discovered vulnerabilities with appropriate remediation actions +* Transparency in vulnerability handling aligned with Eclipse Foundation policies + +Vulnerability Management Scope +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +There is no deviation from the scope presented in the `S-CORE project page `_. +The vulnerability management applies to: + +* All software components developed within the S-CORE platform +* Third-party dependencies and libraries integrated into the platform +* Build and development tools used in the platform development lifecycle +* Documentation and configuration artifacts that may have security implications + +The platform and its components are developed and integrated for an assumed technical system as platform and components Out of Context (OoC). +Vulnerability management follows the defined processes and integrates with the security management system. + +Regarding platform specifics: + +* Vulnerabilities are classified by severity (Critical, High, Medium, Low) based on CVSS scores and platform-specific impact +* Security-relevant components receive priority attention in vulnerability scanning and remediation +* Module-specific vulnerability management is coordinated through module security plans +* Dependencies are continuously monitored for known vulnerabilities using automated tools + +Tailoring +^^^^^^^^^ + +Tailoring of vulnerability management activities: + +* The tailoring is divided into project-wide and module-specific rules +* Project-wide tailoring is documented in this document based on platform OoC development +* Module OoC specific tailoring is documented in module development security plans +* Vulnerability management follows the Eclipse Foundation Security Policy and procedures + +The vulnerability management plan is aligned with ISO SAE 21434: + +* Clause 8.4 - Vulnerability management activities +* Clause 8.5 - Continuous cybersecurity activities including vulnerability monitoring + +Approach +++++++++ + +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. +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. + +We foster an environment where security researchers and contributors are acknowledged for their +responsible disclosure of vulnerabilities. The project commits to: + +* Acknowledging vulnerability reports promptly +* Providing timely updates on remediation progress +* Learning from each vulnerability to improve development practices + +As an Eclipse SDV project, S-CORE follows the `Eclipse CSI Security Handbook `_ +which provides security guidelines specifically designed for automotive and Software Defined Vehicle contexts. +This includes enhanced focus on supply chain security, automated dependency management via Dependabot, +and strict branch protection requirements to ensure integrity and traceability of all code changes. + +Vulnerability Management Organization +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +The vulnerability management organization aligns with the Eclipse Foundation structure and project roles defined in :doc:`security_management`. + +*Eclipse Foundation Integration* + +* `Eclipse Foundation Security Team `_ provides guidance and coordinates vulnerability disclosure +* The `Eclipse Foundation Security Policy `_ governs vulnerability handling procedures +* Vulnerabilities are reported through the `Eclipse general vulnerability tracker `_ +* Critical vulnerabilities follow the Eclipse Foundation's security advisory process + +*Project Roles* + +* :need:`rl__security_manager` - Overall responsibility for vulnerability management coordination +* :need:`rl__project_lead` - Escalation point and resource allocation for critical vulnerabilities +* Committers - Responsible for implementing vulnerability fixes within their areas +* Module Security Managers - Coordinate vulnerability management for specific modules + +*Vulnerability Response Team* + +A dedicated vulnerability response team is established consisting of: + +* Security Manager (lead) +* Affected module security managers +* Relevant committers with domain expertise +* Quality Manager for verification coordination +* Safety Manager for safety impact analysis (if applicable) + + +*Eclipse SDV Security Practices* + +The S-CORE project follows the Eclipse CSI Security Handbook for Eclipse Software Defined Vehicle (SDV) projects: + +* **Branch Protection** - All release and main branches have protection enabled +* **Security-First Development** - Security integrated throughout development lifecycle +* **Supply Chain Security** - SBOM generation for all releases per :need:`wp__sw_platform_sbom` + +Vulnerability Identification +^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Multiple channels are established for vulnerability identification: + +*Automated* + +* **GitHub Dependabot** - Automated dependency vulnerability detection and update pull requests +* **GitHub Advanced Security** - Code scanning and secret scanning capabilities where available (CodeQL) + + +*Manual* + +* Security code reviews as defined in :doc:`software_development` +* Security-focused verification activities per :doc:`software_verification` +* Architecture and design security reviews (security analysis) + +*External Reporting* + +* Vulnerability reports from security researchers through Eclipse channels +* CVE monitoring for dependencies and related technologies +* Security advisories from upstream projects and suppliers +* Community-reported issues through GitHub issue tracking + +Vulnerability Analysis +^^^^^^^^^^^^^^^^^^^^^^ + +All identified vulnerabilities undergo systematic analysis: + +*Initial* + +Upon discovery, vulnerabilities are triaged within T.B.D. working days: + +* Verification of the vulnerability (confirm exploitability and impact, if applicable) +* Initial severity assessment using CVSS v3.1 base metrics +* Affected module/component and version identification +* Assignment to vulnerability response team member + +*Detailed* + +For confirmed vulnerabilities, detailed analysis includes: + +* CVSS v3.1 scoring +* Platform-specific impact analysis considering safety implications +* Attack vector and exploitability analysis +* Affected feature/component and module identification +* Dependency chain analysis for third-party vulnerabilities + +*Severity Classification* + +Vulnerabilities are classified according to CVSS scores and platform impact: + +.. list-table:: Vulnerability Severity Classification + :header-rows: 1 + :widths: 20 20 60 + + * - Severity + - CVSS Score + - Characteristics + + * - Critical + - 9.0 - 10.0 + - Remote code execution, authentication bypass, or impacts safety-critical functionality + + * - High + - 7.0 - 8.9 + - Significant security impact, privilege escalation, or affects security mechanisms + + * - Medium + - 4.0 - 6.9 + - Moderate impact, requires specific conditions to exploit, limited scope + + * - Low + - 0.1 - 3.9 + - Minor impact, difficult to exploit, minimal security consequence + +*Safety Impact Analysis* + +For safety-relevant components (ASIL B), additional analysis addresses: + +* Potential for vulnerability to cause hazardous behavior +* Impact on safety mechanisms +* Interaction with functional safety requirements +* Need for safety-related remediation verification + +Vulnerability Remediation +^^^^^^^^^^^^^^^^^^^^^^^^^ + +Vulnerability remediation follows the Problem Resolution workflow as defined in +:need:`doc__platform_problem_resolution_plan` with security-specific adaptations. + +*Remediation Timelines* + +Remediation Time Lines are based on vulnerability severity (mapped to problem classification): + +.. list-table:: Vulnerability Remediation Timelines and Problem Classification + :header-rows: 1 + :widths: 15 15 20 25 25 + + * - Severity + - CVSS Score + - Problem Label + - Target Timeline + - Actions + + * - Critical + - 9.0 - 10.0 + - ``blocker`` + - 7 days (T.B.D.) + - Immediate response team activation, emergency patch, coordinated disclosure + + * - High + - 7.0 - 8.9 + - ``critical`` + - 30 days (T.B.D.) + - Prioritized fix development, regular status updates, planned release + + * - Medium + - 4.0 - 6.9 + - ``major`` + - 90 days (T.B.D.) + - Scheduled fix in upcoming release, documented workarounds if available + + * - Low + - 0.1 - 3.9 + - ``minor`` + - 180 days or next major release (T.B.D.) + - Addressed in regular development cycle, may be combined with other fixes + +*Workarounds and Mitigations* + +When immediate fixes are not feasible: + +* Document and communicate workarounds to affected users +* Implement temporary mitigations to reduce risk +* Update platform security manual with guidance +* Plan permanent fix for future release + +Vulnerability Tracking and Reporting +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Vulnerabilities are managed through the S-CORE :doc:`problem_resolution` process. +Each identified vulnerability is treated as a security problem and follows the established +Problem Resolution workflow defined in :need:`doc__platform_problem_resolution_plan`. + +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: + +* **GitHub Issues** - Primary tracking system: + + * Issue type: Problem Report with type ``Security Vulnerability`` + * Labels: T.B.D. ``security``, ``vulnerability``, plus severity labels (``critical``, ``blocker``, ``major``, ``minor``) + * Template: :need:`gd_temp__problem_template` extended with vulnerability-specific attributes + * Workflow: Problem Resolution workflow (open → in review → in implementation → closed/rejected) + * `Projects dashboard for visual tracking and status management `_ + * Linked PRs for remediation implementation tracking + + +*Reporting and Metrics* + +Regular reporting includes: + +* Weekly/Monthly (T.B.D.) vulnerability status in T.B.D. meetings + +*Key Metrics* + +* Number of vulnerabilities by severity and source + +Vulnerability Disclosure +^^^^^^^^^^^^^^^^^^^^^^^^ + +Responsible disclosure follows Eclipse Foundation policies. + + +References +++++++++++ + +Related Platform Management Plans: + +* :doc:`problem_resolution` - **PRIMARY**: Vulnerability tracking workflow through GitHub Issues +* :doc:`security_management` - Overall security management framework +* :doc:`safety_management` - Safety impact assessment for vulnerabilities +* :doc:`quality_management` - Quality integration and metrics +* :doc:`software_development` - Secure development practices +* :doc:`software_verification` - Security verification and testing +* :doc:`tool_management` - Vulnerability scanning tool qualification +* :doc:`release_management` - Security patch release coordination + +External References: + +* `Eclipse Foundation Security Policy `_ +* `Eclipse Foundation Security Team `_ +* `Eclipse Vulnerability Tracker `_ +* `Eclipse CSI Security Handbook `_ - Security best practices for Eclipse SDV projects +* `Eclipse CSI Security Handbook Branch Protection - Branch Protection `_ +* `GitHub Dependabot Quickstart Guide `_ +* `GitHub Dependabot Configuration `_ +* :need:`ISO SAE 21434 - Cybersecurity engineering ` +* `CVSS v3.1 - Common Vulnerability Scoring System `_ +* `CWE - Common Weakness Enumeration `_ +* `NVD - National Vulnerability Database `_ From 625c8c86704bd1e3b8691feb5c9f6638f1175dde Mon Sep 17 00:00:00 2001 From: "markus.schu" Date: Wed, 18 Feb 2026 14:53:48 +0100 Subject: [PATCH 2/3] incorporated review comments from pandoe --- .../vulnerability_management.rst | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/docs/platform_management_plan/vulnerability_management.rst b/docs/platform_management_plan/vulnerability_management.rst index 9e6df6553b..dd2d7829e0 100644 --- a/docs/platform_management_plan/vulnerability_management.rst +++ b/docs/platform_management_plan/vulnerability_management.rst @@ -78,6 +78,7 @@ Regarding platform specifics: * Vulnerabilities are classified by severity (Critical, High, Medium, Low) based on CVSS scores and platform-specific impact * Security-relevant components receive priority attention in vulnerability scanning and remediation +* Platform-specific vulnerability management is coordinated through platform security plan * Module-specific vulnerability management is coordinated through module security plans * Dependencies are continuously monitored for known vulnerabilities using automated tools @@ -89,7 +90,7 @@ Tailoring of vulnerability management activities: * The tailoring is divided into project-wide and module-specific rules * Project-wide tailoring is documented in this document based on platform OoC development * Module OoC specific tailoring is documented in module development security plans -* Vulnerability management follows the Eclipse Foundation Security Policy and procedures +* Vulnerability management follows the Eclipse Foundation Security Policy (`Eclipse Foundation Security Policy `_) and procedures The vulnerability management plan is aligned with ISO SAE 21434: @@ -172,7 +173,7 @@ Multiple channels are established for vulnerability identification: * Security code reviews as defined in :doc:`software_development` * Security-focused verification activities per :doc:`software_verification` -* Architecture and design security reviews (security analysis) +* Architecture and design security reviews (by performing security analysis) *External Reporting* @@ -188,7 +189,7 @@ All identified vulnerabilities undergo systematic analysis: *Initial* -Upon discovery, vulnerabilities are triaged within T.B.D. working days: +Upon identification, vulnerabilities are triaged within T.B.D. working days: * Verification of the vulnerability (confirm exploitability and impact, if applicable) * Initial severity assessment using CVSS v3.1 base metrics @@ -237,7 +238,7 @@ Vulnerabilities are classified according to CVSS scores and platform impact: For safety-relevant components (ASIL B), additional analysis addresses: -* Potential for vulnerability to cause hazardous behavior +* Potential for vulnerability to cause hazardous behaviors * Impact on safety mechanisms * Interaction with functional safety requirements * Need for safety-related remediation verification @@ -314,7 +315,7 @@ All vulnerabilities are tracked using GitHub Issues as the **ONLY** mechanism pe * Labels: T.B.D. ``security``, ``vulnerability``, plus severity labels (``critical``, ``blocker``, ``major``, ``minor``) * Template: :need:`gd_temp__problem_template` extended with vulnerability-specific attributes * Workflow: Problem Resolution workflow (open → in review → in implementation → closed/rejected) - * `Projects dashboard for visual tracking and status management `_ + * `Projects dashboard for visual tracking and status management `_ * Linked PRs for remediation implementation tracking From f5f558110c39b1fccef2c28cb7f1bbe5e0c128da Mon Sep 17 00:00:00 2001 From: "markus.schu" Date: Thu, 19 Feb 2026 07:53:40 +0100 Subject: [PATCH 3/3] conisder review commens from anmittag --- .../role_assignment/platform_quality_manager.rst | 4 ++++ .../role_assignment/platform_safety_manager.rst | 6 ++++++ .../role_assignment/platform_security_manager.rst | 6 ++++++ docs/platform_management_plan/vulnerability_management.rst | 6 +++--- 4 files changed, 19 insertions(+), 3 deletions(-) diff --git a/docs/platform_management_plan/role_assignment/platform_quality_manager.rst b/docs/platform_management_plan/role_assignment/platform_quality_manager.rst index c251798bc3..f15147860c 100644 --- a/docs/platform_management_plan/role_assignment/platform_quality_manager.rst +++ b/docs/platform_management_plan/role_assignment/platform_quality_manager.rst @@ -40,6 +40,10 @@ For the role :need:`rl__quality_manager` the required skills, knowledge and expe The evidences are not published openly due to personal data confidentiality, but will be checked in a dedicated review meeting and confirmed by the first reviewer of this document's pull requests. +For the election of Module Quality Managers, the pool of platform quality managers is considered. +The election of Module Quality Managers is performed by the platform quality managers and is +based on the required skills, knowledge and experience defined in :need:`rl__quality_manager` +and the evidences provided by the nominees. Evidences Markus Schu --------------------- diff --git a/docs/platform_management_plan/role_assignment/platform_safety_manager.rst b/docs/platform_management_plan/role_assignment/platform_safety_manager.rst index 7e02fa362b..90b20894fd 100644 --- a/docs/platform_management_plan/role_assignment/platform_safety_manager.rst +++ b/docs/platform_management_plan/role_assignment/platform_safety_manager.rst @@ -33,6 +33,12 @@ For the platform safety management a pool of safety managers is elected due to c `Volker Häussler `_ + +For the election of Module Safety Managers, the pool of platform safety managers is considered. +The election of Module Safety Managers is performed by the platform safety managers and is +based on the required skills, knowledge and experience defined in :need:`rl__safety_manager` +and the evidences provided by the nominees. + Election Reasoning ================== diff --git a/docs/platform_management_plan/role_assignment/platform_security_manager.rst b/docs/platform_management_plan/role_assignment/platform_security_manager.rst index a82a112278..7ac8fee408 100644 --- a/docs/platform_management_plan/role_assignment/platform_security_manager.rst +++ b/docs/platform_management_plan/role_assignment/platform_security_manager.rst @@ -31,6 +31,12 @@ For the platform security management a pool of security managers is elected due `Volker Häussler `_ + +For the election of Module Security Managers, the pool of platform security managers is considered. +The election of Module Security Managers is performed by the platform security managers and is +based on the required skills, knowledge and experience defined in :need:`rl__security_manager` +and the evidences provided by the nominees. + Election Reasoning ================== diff --git a/docs/platform_management_plan/vulnerability_management.rst b/docs/platform_management_plan/vulnerability_management.rst index dd2d7829e0..84626c938a 100644 --- a/docs/platform_management_plan/vulnerability_management.rst +++ b/docs/platform_management_plan/vulnerability_management.rst @@ -136,8 +136,8 @@ The vulnerability management organization aligns with the Eclipse Foundation str * :need:`rl__security_manager` - Overall responsibility for vulnerability management coordination * :need:`rl__project_lead` - Escalation point and resource allocation for critical vulnerabilities -* Committers - Responsible for implementing vulnerability fixes within their areas -* Module Security Managers - Coordinate vulnerability management for specific modules +* :need:`rl__committer` - Responsible for implementing vulnerability fixes within their areas +* :need:`Module Security Manager` - :need:`rl__security_manager` elected from the pool of platform security managers, responsible for vulnerability management coordination at the module level *Vulnerability Response Team* @@ -156,7 +156,7 @@ The S-CORE project follows the Eclipse CSI Security Handbook for Eclipse Softwar * **Branch Protection** - All release and main branches have protection enabled * **Security-First Development** - Security integrated throughout development lifecycle -* **Supply Chain Security** - SBOM generation for all releases per :need:`wp__sw_platform_sbom` +* **Supply Chain Security** - SBOM generation for all planned releases as defined in the :need:`doc__project_mgt_plan` per :need:`wp__sw_platform_sbom` Vulnerability Identification ^^^^^^^^^^^^^^^^^^^^^^^^^^^^