The number of Eclipse Foundation projects incorporating OtterDog has reached 104, marking an increase of 5 since the end of April. OtterDog now manages the configuration of 1,265 repositories.
This month's updates include:
- Addition of dependabot charts and private vulnerability reporting to the dashboard (eclipse-csi/otterdog#238)
- Similar to the Eclipse Common Security Infrastructure Project, we now have a logo for Eclipse OtterDog to get a brand identity. All OtterDog artwork are available on GitHub at https://github.com/eclipse-csi/.github/tree/main/artwork/eclipse-otterdog.
We have completed 2FA enforcement on all GitHub organization owned by Eclipse Foundation as per our plan. This means that all committers on all Eclipse Foundation projects must now have 2FA enabled in order to be able to push to their repositories. A blog post to celebrate the completion of this project is scheduled for early June.
The security audit of Eclipse kuksa has been completed. The audit covered the databroker and the Python client; it consisted of static analysis, manual code review and dynamic analysis with fuzzing. See announcement and details on the findings at https://blogs.eclipse.org/post/marta-rybczynska/eclipse-kuksa-security-audit-has-been-completed
We also have released 2 CVEs for Eclipse Projects:
On May 21-22, we participated to Software and Supply Chain Assurance (SSCA) Forum at MITRE, in McLean, VA.
On May 24, we submitted a project proposal to the Sovereign Tech Fund, aiming to augment and expand our current activities funded by the Alpha-Omega grant.
We held our first interested parties call for the Open Regulatory Compliance Working Group. The minutes, presented slide deck, and recording are available online.
We developed a proof of concept for an internal dashboard to assist the infrastructure team in managing the patch levels of various machines and VMs used by the Eclipse Foundation. The solution is based on the open-source security platform Wazuh.
On a different topic, we encountered an issue with our code signing services. The Eclipse Foundation operates an on-premise JAR signing service and a Portable Executable (e.g., .exe, .dll) signing service to facilitate the use of the Eclipse Foundation EV Code Signing certificate by its projects.
In late May, we had to rotate the certificate as it was expiring. Since the last renewal, rules have changed, and the Certificate Authority now requires EV code signing certificates to be stored on a Hardware Security Module (HSM). We had to adapt the implementation and deployment of our services to accommodate the new certificate. However, the issue is not entirely resolved, as the switch to HSM has caused a significant loss in performance and scalability. We are still investigating.
We published a new job description that is now listed on the Eclipse Foundation Careers page.