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.
Merge request reports
Activity
In both Jakarta EE and MicroProfile, there were some week-long arguments regarding whether to do a patch release for both Jakarta EE 10 and MicroProfile 6.0 just because some build or test dependencies used were not up to date or contain vulnerabilities. These discussions used up a lot of meeting time while producing no results. This further impacted the project from making fast progress towards achieving the next major releases Jakarta EE 11 and MicroProfile 7.0. I suggested not to continue the discussion but seek some advice from Eclipse Foundation. At EclipseCon, I had this issue discussed in the Architecture meeting with @wbeaton and @mbarbero and reached some conclusion. For future reference, Wayne suggested to put the conclusion into the handbook.
@wbeaton can you review and merge if you are happy with the content?
I'm not entirely happy with the proposal. From a quick review:
The Eclipse Foundation notifies the project teams, typically by including the project leads in copy, when a vulnerability (e.g. log4j CVE-2021-44228, CVE-2021-4104 and CVE-2021-45046) is reported
This is inaccurate until the security team establishes a method to track the dependencies of all projects. However, we do inform projects whenever we receive a security report at security@eclipse-foundation.org.
It is the responsibility of the project team to decide whether or not to fix a vulnerability
That's incorrect. 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
/cc @mrybczyn
@mbarbero I have addressed your comments to reflect the current process. Please take a look to see whether you are happy with the changes. Please feel free to suggest alternative texts.
- Resolved by Emily Jiang
@ejiang it would be good to squash those commits, so that we discuss the last version only.
My comments:
- The text is missing information that every reported vulnerability must be disclosed. Here is the relevant fragment from https://www.eclipse.org/security/policy/
All Vulnerabilities must be disclosed, regardless of the resolution. Users and administrators of Eclipse software must be made aware that a Vulnerability exists so they may assess risk, and take the appropriate action to protect their users, servers and systems from potential exploit.As a consequence, projects may face reputation damage if such an non-fixed vulnerability is disclosed. It might also have impact on their users, for example when a corporate policy disallows components with unfixed security issues.
- When we are discussing the subject, it is good to mention that the default disclosure policy for EF is 90 days.
- Last reply by Emily Jiang
18 18 19 19 The {securityPolicyUrl}[Eclipse Foundation Vulnerability Reporting Policy] contains information regarding obligations and specific practices regarding the reporting and disclosure of vulnerabilities. 20 20 21 [[vulnerability-resolution-guidelines]] 22 == Vulnerability Resolution Guidelines 23 24 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). 18 18 19 19 The {securityPolicyUrl}[Eclipse Foundation Vulnerability Reporting Policy] contains information regarding obligations and specific practices regarding the reporting and disclosure of vulnerabilities. 20 20 21 [[vulnerability-resolution-guidelines]] 22 == Vulnerability Resolution Guidelines 23 24 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). 25 26 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. 27 28 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 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"
18 18 19 19 The {securityPolicyUrl}[Eclipse Foundation Vulnerability Reporting Policy] contains information regarding obligations and specific practices regarding the reporting and disclosure of vulnerabilities. 20 20 21 [[vulnerability-resolution-guidelines]] 22 == Vulnerability Resolution Guidelines 23 24 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). 25 26 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. 27 28 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 29 30 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. 31 32 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. 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.
