Eclipse Foundation projects can now request access to GitHub's Private Vulnerability Reporting feature. This enables project committers to receive potential vulnerability reports confidentially. However, projects cannot use the Request CVE button within these reports. Instead, they should request a CVE from the Eclipse Foundation Security Team.
This is due to a current limitation in GitHub, which does not include all the information that the Eclipse Foundation Security Team adds to CVE entries, such as the correct project name. Additionally, when GitHub assigns CVEs, they are allocated by a different CVE Numbering Authority (CNA) than the one designated for Eclipse Foundation projects.
We are actively working with GitHub on a more streamlined process and hope to offer a more developer-friendly solution in the near future.
After discussions between the Eclipse Foundation Security Team and the Architecture Council, we have announced the creation of a new role for Project Members: Project Security Teams. These teams allow projects to designate specific individuals responsible for handling vulnerability reports. Project Leads can manage membership within their Project Management space.
This initiative marks a significant step forward in improving visibility and communication regarding security issues within the Eclipse Foundation community.
If all Committers in a project are already involved in addressing security issues, nothing will change—Committers will automatically be considered part of the Project Security Team, and no further action is required by the project.
However, for projects with a more complex structure where only a select few handle vulnerability reports, Project Leads can establish a dedicated Project Security Team.
Starting in early September, all members of Project Security Teams for projects hosted on GitHub will be granted the Security Manager role. If a project makes no changes in the Project Management Infrastructure (PMI) by then, and in line with the default setting where all Committers are considered part of the Project Security Team, all Committers will receive the Security Manager role in their respective GitHub organizations.
The Foundation's policy of openness remains unchanged: all security issues will continue to be disclosed eventually, and the Eclipse Foundation Security Team will ensure that this practice is upheld.
We have updated the Eclipse Foundation Project Handbook with detailed documentation outlining the specific permissions granted to members of Project Security Teams.
The organizations listed below have completed the necessary paperwork to join The Open Regulatory Compliance Working Group over the past month:
- Obeo
We have enhanced our email security measures to prevent malicious actors from impersonating the sender of email messages sent from one of our domains. We use an external service to monitor our security posture, and our score increased from 796 to 872 (+76) over the course of the month. These measures address long-standing technical debt by properly configuring DMARC and SPF across dozens of domains.
We have published three blog posts to raise awareness about recent updates and changes in the security ecosystem:
- Using GitHub Private Vulnerability Reporting by Eclipse Foundation Projects
This post explains how Eclipse Foundation projects can use GitHub's Private Vulnerability Reporting feature to confidentially receive and handle vulnerability reports. - Reviewing the CVE Process and the CNA Rules 4.0
A detailed review of the new 4.0 rules for CNAs (CVE Numbering Authorities) and how they affect Eclipse Foundation's role in assigning CVEs. - DO NOT USE IN PRODUCTION
This post advises developers to clearly label and communicate when code or features are not ready for production use, often for demos or experimental purposes.