Thanks to financial support from the OpenSSF’s Alpha-Omega project, the Eclipse Foundation is glad to have made significant improvements in the last couple of months.
Eclipse Tycho, Eclipse m2e, and Eclipse RAP have all enforced 2FA for all their committers on GitHub:
Meanwhile, we’ve seen an increase of adoption of 2FA globally on all Eclipse Projects at Github, increasing from 63.7% to 67% since the begining of the year. We are now starting to actively enforce 2FA for projects with a dedicated GitHub organization.
We have successfully initiated the 3 security audits that will all be performed by Trail of Bits in collaboration with OSTIF. The projects that will be covered in these audits are:
Threat modeling for one out of the three audits have been completed. Code review is underway. The timeline has been locked in for threat modeling and code review for the second security audit. The schedule of the third one is still a work in progress, but will likely be delayed due to project’s constraint. This last one will likely complete in May.
We have build capacity since the beginning of the year, hiring 3 talented people:
We’re also in talks with a SecOps professional to improve the security of our infrastructure and introduce new tools and services, such as a self-hosted sigstore.
We have started gathering feedback from projects about Eclipse’s security processes. We are performing interviews with committers and project leads, starting with projects selected for the audit or having a recent security vulnerability. We have contacted six projects, conducted four interviews, and gathered helpful feedback.
The common outcome is a request for more detailed documentation and clarification of the process. Proposals for updated documentations are currently under review. More interviews are planned. We’ve extended the experimentation of GitHub security advisories. We have also worked on a SECURITY.md template for all Eclipse Foundation projects.
We have re-started the work on a custom tool to enforce and create security related configurations of organizations and their associated repositories on GitHub. The tool is codenamed OtterDog.
What is currently supported:
Some work has been done in order to improve the usability of the tool. The tool will output in a concise way what settings / resources will be changed / created prior to applying the configuration to GitHub by comparing the current live settings on GitHub to the intended configuration.
A credential provider for pass (in addition to existing one for Bitwarden) has been added to support using the tool for our first organization: Eclipse CBI which hosts various tools and projects for common build infrastructure at the Eclipse Foundation.
We started to work on slsa-tools which is a collection of tools written in Java to operate on SLSA provenance files. The idea behind this project is to have a rich set of tools to verify / generate provenance files for the Java ecosystem.
Existing SLSA tools are implemented in Go which make it somewhat cumbersome to use them in certain settings, e.g. to develop a Jenkins plugin to generate provenance files for builds.
The medium-term goal is to develop such a Jenkins plugin with features similar to the existing slsa-github-generator action for GitHub.