initial version for vulnerability management by masc2023 · Pull Request #2604 · eclipse-score/score

masc2023 · 2026-02-16T13:52:23Z

document vulnerability management in relation to
security management and problem resolution

Resolves: ##1941

document vulnerability management in relation to security management and problem resolution Resolves: ##1941

github-actions · 2026-02-16T13:52:32Z

⚠️ Docs-as-Code version mismatch detected
Please check the CI build logs for details and align the documentation version with the Bazel dependency.

github-actions · 2026-02-16T13:56:04Z

The created documentation from the pull request is available at: docu-html

PandaeDo · 2026-02-18T06:24:10Z

docs/platform_management_plan/vulnerability_management.rst

+
+For safety-relevant components (ASIL B), additional analysis addresses:
+
+* Potential for vulnerability to cause hazardous behavior


Suggested change

* Potential for vulnerability to cause hazardous behavior

* Potential for vulnerability to cause hazardous behaviors

PandaeDo · 2026-02-18T06:41:59Z

docs/platform_management_plan/vulnerability_management.rst

+
+Regarding platform specifics:
+
+* Vulnerabilities are classified by severity (Critical, High, Medium, Low) based on CVSS scores and platform-specific impact


Is there a reason why we don't use none as severity?

That can be mapped to ISO 21434 feas. rating 1:1, there are only 4, low is more or less accepted

PandaeDo · 2026-02-18T06:48:53Z

docs/platform_management_plan/vulnerability_management.rst

+
+* 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


Vulnerability management isn't mentioned in the process description and also not in the template. We might give this as a input into the work of @sunildevda, @CryptoNutcase to make it a little bit clearer / easier to find for contributers.

Yes, correct, but this time we want to implement something faster the defined, will create ticket for them. As you can see in the top, should be not own process area, but part of Security Management, Problem Resolution, eclipse-score/process_description#575

PandaeDo · 2026-02-18T06:51:45Z

docs/platform_management_plan/vulnerability_management.rst

+* 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


Suggested change

* Vulnerability management follows the Eclipse Foundation Security Policy and procedures

* Vulnerability management follows the Eclipse Foundation Security Policy (`Eclipse Foundation Security Policy <https://www.eclipse.org/security/policy/>`_) and procedures

PandaeDo · 2026-02-18T06:54:12Z

docs/platform_management_plan/vulnerability_management.rst

+
+* 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


Suggested change

* Module-specific vulnerability management is coordinated through module security plans

* Platform-specific vulnerability management is coordinated through platform security plan

* Module-specific vulnerability management is coordinated through module security plans

PandaeDo · 2026-02-18T07:11:22Z

docs/platform_management_plan/vulnerability_management.rst

+
+*Manual*
+
+* Security code reviews as defined in :doc:`software_development`


To be honest. I think we (and you can address it to me if you agree on my thoughts) shall add this to the SDP

Sure, the idea is here, only to mentioned in in the draft version and you can move it after merging to the other documents and cross link, agreed? If yes, please make a ticket and we can add it here to the PR

PandaeDo · 2026-02-18T07:13:03Z

docs/platform_management_plan/vulnerability_management.rst

+*Manual*
+
+* Security code reviews as defined in :doc:`software_development`
+* Security-focused verification activities per :doc:`software_verification`


Also here. I think we can improve the description of security focused verification activities a little bit.

PandaeDo · 2026-02-18T07:15:40Z

docs/platform_management_plan/vulnerability_management.rst

+
+* Security code reviews as defined in :doc:`software_development`
+* Security-focused verification activities per :doc:`software_verification`
+* Architecture and design security reviews (security analysis)


Suggested change

* Architecture and design security reviews (security analysis)

* Architecture and design security reviews (by performing security analysis)

PandaeDo · 2026-02-18T07:22:35Z

docs/platform_management_plan/vulnerability_management.rst

+
+*Initial*
+
+Upon discovery, vulnerabilities are triaged within T.B.D. working days:


Isn't it defined in the following table under vulnerability remediation?

this is from the identification to the decision, that it is an vulnerability and needs remdiation, below table is after that, the remediation has to be implemented, another time

PandaeDo · 2026-02-18T07:25:12Z

docs/platform_management_plan/vulnerability_management.rst

+  * 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 <https://www.eclipse.org/security/policy/>`_


I guess the Link isn't correct

anmittag · 2026-02-18T15:47:08Z

docs/platform_management_plan/vulnerability_management.rst

+* :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
+


Where is the role Module Security Manager defined => shall be linked

anmittag · 2026-02-18T15:53:24Z

docs/platform_management_plan/vulnerability_management.rst

+* Relevant committers with domain expertise
+* Quality Manager for verification coordination
+* Safety Manager for safety impact analysis (if applicable)
+


add link to the roles

anmittag · 2026-02-18T15:57:42Z

General topic: unclear, which releases to be examined. Only latest? All releases? And which one shall be repaired? Is it sufficient to announce with a new release that older versions are replaced and not valid and have issues inside?

masc2023 · 2026-02-19T06:51:11Z

General topic: unclear, which releases to be examined. Only latest? All releases? And which one shall be repaired? Is it sufficient to announce with a new release that older versions are replaced and not valid and have issues inside?

Add link to Project Management Plan, as there are Milestones Roadmap defined, so for all planned Releases

sunildevda

@masc2023 added some points/questions from my side.

sunildevda · 2026-02-26T09:32:47Z

docs/platform_management_plan/vulnerability_management.rst

+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+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.


It is better to describe what is appropriate channels or just give a link for eclipse process and "say as explained in ... "

sunildevda · 2026-02-26T09:40:28Z

docs/platform_management_plan/vulnerability_management.rst

+
+For confirmed vulnerabilities, detailed analysis includes:
+
+* CVSS v3.1 scoring


why v3.1? latest version is 4.0.

Also, we can give a link to the page for faster access (or guide the user to see end of the document for links). example: https://www.first.org/cvss/calculator/4.0

sunildevda · 2026-02-26T10:10:21Z

docs/platform_management_plan/vulnerability_management.rst

+
+* **GitHub Issues** - Primary tracking system:
+
+  * Issue type: Problem Report with type ``Security Vulnerability``


We need to also include that "Category Security Related is set in the issue".
Additionally if the vulnerability affects safety then safety related has to be also set.

Example https://github.com/eclipse-score/process_description/blob/main/.github/ISSUE_TEMPLATE/1-bugfix.yml

sunildevda · 2026-02-26T10:20:26Z

docs/platform_management_plan/vulnerability_management.rst

+
+*Remediation Timelines*
+
+Remediation Time Lines are based on vulnerability severity (mapped to problem classification):


which version should be fixed? only the latest version?

sunildevda · 2026-02-26T10:32:27Z

docs/platform_management_plan/vulnerability_management.rst

@@ -0,0 +1,363 @@
+..


I have some generic points that we need to consider for vulnerability management process. Don't know which is the right place where this should be mentioned (preferred would be this document itself). or may be these points are already mentioned but i didn't find them (if this is the case, please guide me to where i can find this).

Vulnerabilities could be identified internally by SCORE community or externally. What is missing is the flow of how internally identified vulnerabilities be handled. I mean the general flow for internally identified defect would be a 1. defect is identified -> 2. then for each defect a question has to be answered, is this security relevant or not -> if yes, then all the additional steps mentioned here has to be followed. and we need to explain "when is a defect security relevant"

What is the flow for creating CVEs and who will do it?

Think we are missing the process of Lessons learnt at the end of the vulnerability handling. for each security vulnerability we should also do a lessons learnt and spread the lessons internally within the community so that we can build the culture of security.

If i get it right, all the known vulnerabilities will ultimately show up here: https://www.eclipse.org/security/known/ and there is no separate or dedicated page for SCORE vulnerability. or? Also, in this page i miss the information which software releases are the vulnerability fixed, is this documented anywhere?

sunildevda · 2026-02-26T10:35:40Z

docs/platform_management_plan/vulnerability_management.rst

+
+* **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`


how does notification work? will security manager get an email when new vulnerability shows up?

sunildevda · 2026-02-26T10:52:13Z

docs/platform_management_plan/vulnerability_management.rst

+
+*Automated*
+
+* **GitHub Dependabot** - Automated dependency vulnerability detection and update pull requests


Is there an example where Dependabot is already set up for other eclipse project? want to see how it looks, how the vulnerabilities are triaged in the tool, which sbom format (cdx or spdx) is used and so on..

We should talk with the eclipse security team: https://www.eclipse.org/security/policy/

Also take a look here: https://eclipse-csi.github.io/security-handbook/developer/branches.html

initial version for vulnerability management

eafa804

document vulnerability management in relation to security management and problem resolution Resolves: ##1941

masc2023 requested review from PandaeDo, aschemmel-tech and pahmann as code owners February 16, 2026 13:52

masc2023 requested review from FScholPer and anmittag February 16, 2026 13:52

masc2023 linked an issue Feb 16, 2026 that may be closed by this pull request

[Incident Management] General Incident Management #1941

Open

PandaeDo requested changes Feb 18, 2026

View reviewed changes

masc2023 mentioned this pull request Feb 18, 2026

Improvement: Consider Vulnerability Management Plan eclipse-score/process_description#575

Open

2 tasks

incorporated review comments from pandoe

625c8c8

anmittag reviewed Feb 18, 2026

View reviewed changes

conisder review commens from anmittag

f5f5581

sunildevda reviewed Feb 26, 2026

View reviewed changes


		For safety-relevant components (ASIL B), additional analysis addresses:

		* Potential for vulnerability to cause hazardous behavior


		Regarding platform specifics:

		* Vulnerabilities are classified by severity (Critical, High, Medium, Low) based on CVSS scores and platform-specific impact

	* Vulnerability management follows the Eclipse Foundation Security Policy and procedures
	* Vulnerability management follows the Eclipse Foundation Security Policy (`Eclipse Foundation Security Policy <https://www.eclipse.org/security/policy/>`_) and procedures

	* Module-specific vulnerability management is coordinated through module security plans
	* Platform-specific vulnerability management is coordinated through platform security plan
	* Module-specific vulnerability management is coordinated through module security plans


		Manual

		* Security code reviews as defined in :doc:`software_development`

	* Architecture and design security reviews (security analysis)
	* Architecture and design security reviews (by performing security analysis)


		Initial

		Upon discovery, vulnerabilities are triaged within T.B.D. working days:


		For confirmed vulnerabilities, detailed analysis includes:

		* CVSS v3.1 scoring


		* GitHub Issues - Primary tracking system:

		* Issue type: Problem Report with type ``Security Vulnerability``


		Remediation Timelines

		Remediation Time Lines are based on vulnerability severity (mapped to problem classification):


		Automated

		* GitHub Dependabot - Automated dependency vulnerability detection and update pull requests

Conversation

masc2023 commented Feb 16, 2026

Uh oh!

github-actions bot commented Feb 16, 2026

Uh oh!

github-actions bot commented Feb 16, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

anmittag commented Feb 18, 2026

Uh oh!

masc2023 commented Feb 19, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

sunildevda left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

masc2023 commented Feb 19, 2026 •

edited

Loading