In response to requests from various projects and after discussions between the Eclipse Foundation Security Team and the Architecture Council, we announced the creation of Project Security Teams (see the discussion at https://github.com/orgs/eclipse-csi/discussions/4)
This blog post gives an overview of various questions that we have received in the last week. We think that responses will be a handful for multiple projects.
Q: Who was responsible before for my Project security and responding to vulnerability reports?
Nothing changes here, this was always the responsibility of the Project!
If all Committers in your project are involved in addressing security issues, nothing will change for you. All Committers will automatically be considered part of your Project Security Team, and no further action is required on your part.
However, if your project has a more complex structure with only a limited number of individuals managing vulnerability reports, Project Leads can establish a dedicated Project Security Team.
The Foundation's policy of openness remains unchanged: all security issues will continue to be eventually disclosed, and the Eclipse Foundation Security Team will ensure that this practice continues.
Q: Who is in the Project’s Security Team?
By default, all Committers are in the Security Team and are together responsible for applying the Security policies.
Each project might decide to name a separate set of individuals (usually a subset of Committers). If you want to nominate a separate team, discuss with your PMC.
Q: Who decides to add/remove someone from the Security Team?
The Project Leads and Committers decide together on the rules to follow. We recommend elections similar to Committer elections.
Q: Wait! We have some inactive Committers. What to do?
This might be a great moment to retire inactive committers! Review the list on the PMI and you can follow what others do like https://github.com/eclipse-platform/.eclipsefdn/issues/7
Q: What if we are not confident about handling security issues and need help?
Typically, handling security issues doesn’t differ much from handling typical bugs. The only difference is that they stay confidential until fixed. You can read about the recommended process in the handbook: https://www.eclipse.org/projects/handbook/#vulnerability
When you receive a vulnerability report, you can also ask the Eclipse Foundation Security Team (security@eclipse-foundation.org) for assistance in communicating with researchers, writing your advisories and CVE entries and so on. The Eclipse Foundation Security Team will not write the fix or tests for you.
The Eclipse Foundation will be also launching training sessions for Committers and Contributors about security-related subjects, stay tuned!
Q: We are a small project, and we do not have additional people to deal with security. What to do?
See the question above. If your project needs additional developers, discuss in your working group about funding related work.
Q: What about the Security Manager role at GitHub?
The Security Manager role at GitHub allows you to access additional security options like notifications on security issues, access to additional testing tools and so on.
In early September, all members of Project Security Teams for projects hosted on GitHub (in an organization other than https://github.com/eclipse) will be granted the Security Manager role. If your project does not make any changes in PMI by then, and in line with the default setting where the Project Security Team equals all Committers, all Committers will be granted the Security Manager role in their respective organization on GitHub.
Q: I have a different question.
If you have additional questions, ask them in the discussion post https://github.com/orgs/eclipse-csi/discussions/6
