Update security.adoc with some guidelines on dealing with vulnerability

After some offline discussion with @wbeaton, we coauthored some guidelines, which result into this PR. Please take a look to see whether you have any comments.

source/chapters/security.adoc

@@ -18,6 +18,19 @@
 
 The {securityPolicyUrl}[Eclipse Foundation Vulnerability Reporting Policy] contains information regarding obligations and specific practices regarding the reporting and disclosure of vulnerabilities.
 
+[[vulnerability-resolution-guidelines]]
+== Vulnerability Resolution Guidelines
+
+There are three kinds of vulnerabilities: vulnerabilities in Eclipse projects content, vulnerabilities in the third party dependencies (e.g. org.glassfish:jakarta.json:2.0.0), and vulnerabilities in tools used to develop and build (e.g., asciidoctor-pdf or testng maven plugin). 
+
+Eclipse Foundation informs projects whenever a security report is recieved by security@eclipse-foundation.org. Affected projects are encouraged to mitigate vulnerabilities as soon as possible.
+
+It is the responsibility of the project team to decide whether or not to fix a vulnerability that is not mandatd to fix by the Foundation and in the case where the vulnerability is detected in the Eclipse project code whether or not to report that vulnerability (that is, whether or not to assign a CVE for the vulnerability). In the case of a vulnerability being detected on the third party dependencies or in tools, the project team should assess the impact of the vulnerability and decide the nature of the mitigation is required, and document the decision. In cases where a project has a critical vulnerability and chooses not to address it, EF can determine that the project is dysfunctional and take appropriate action accordingly. See section 3.1 of the EFDP: https://www.eclipse.org/projects/dev_process/#edp-emo-responsibility
+
+All decisions regarding whether or not, and how vulnerabilities are addressed should be based on the impact. If the project cannot reach consensus, they should reach out to the Security Team in Eclipse Foundation. Contact information for the Security Team, along with additional help regarding vulnerability management, including the assignment of CVEs, is in this handbook.
+
+It should be noted that vulnerabilities have different severities and not all of them need a reaction. Some vulnerabilities might not need a fix at all. It is acceptable to deal with vulnerabilities by upgrading the dependencies for your next project release; in extreme cases, the project team may opt to issue an emergency service release. If your project needs to do a service release to mitigate a vulnerability, the project team does not need to engage in  the review process.
+
 [[vulnerability-team]]
 == Eclipse Foundation Security Team
 

[Marta Rybczynska]

There are way more: vulnerabilities in the hardware the software or build is running on, vulnerabilities in 3rd party services (which are not dependencies) and so on. I also do not understand what this introduction is leading to. This classification does not seem to be used below.

[Marta Rybczynska]

This sentence is quite long. I would recommend to spit it in a number of sentences to keep a clear flow.

First part: this is up to the project to decide if they fix or not, but the researcher might disagree with them. Not fixing might have high impact on the reputation of the project, as at the end all vulnerabilities to Eclipse projects are disclosed. This is not possible for a project to keep an unfixed vulnerability not known to the public. The researcher might disclose the vulnerability on their side, they can also apply for a CVE on their own.

There are also expressions I do not understand: what does it mean "mandated by the Foundation" here?

Second part: you probably mean "vulnerability detected IN the third party dependencies"

[Marta Rybczynska]

Those are separate ideas so would be good to put them in separate paragraphs. For example (with editing), see below. I've updated the vocabulary to be in sync with the rest of the document. If you mean a release review process as 'review process', the new process is different and projects go by the review once per year only. There is no impact on bugfix releases. @wbeaton could you confirm.

And here's my proposal of the rewrite.

It should be noted that vulnerabilities have different severities and not all of them need the same reaction. Some (low severity) vulnerabilities might not need a fix at all if documented or if a viable workaround exists.

In case of a critical vulnerability, the project might decide to perform an emergency bugfix release.

It is a common practice to resolve vulnerabilities by upgrading the dependencies for your next project release.