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/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 new file mode 100644 index 0000000000..84626c938a --- /dev/null +++ b/docs/platform_management_plan/vulnerability_management.rst @@ -0,0 +1,364 @@ +.. + # ******************************************************************************* + # 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 +* 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 + +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 (`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 +* :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* + +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 planned releases as defined in the :need:`doc__project_mgt_plan` 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 (by performing 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 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 +* 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 behaviors +* 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 `_