Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: Eclipse Foundation September 2024 update #427

Merged
merged 1 commit into from
Oct 13, 2024
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
41 changes: 41 additions & 0 deletions alpha/engagements/2024/Eclipse Foundation/update-2024-09.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,41 @@
# Eclipse Foundation Update — September 2024

## Identity and Access Management

We have completed our investigation into replacing our current identity provider with our in-house Keycloak setup. The investigation focused primarily on replicating the look and feel of the current login page and integrating a 2FA workflow. We designed a process for users to set up 2FA and for enforcing 2FA for all committers.

Additionally, we have begun investigating how to migrate TOTP-based 2FA from GitLab’s internal datastore at [gitlab.eclipse.org](https://gitlab.eclipse.org) to Keycloak. This is to avoid disabling 2FA for many users who already have it enabled and then requiring them to re-enable it in the new Keycloak-based system. Our goal is to make this process as seamless as possible to facilitate a smooth transition and minimize friction for our users.

We have also completed migrating all our authenticated APIs to use our Keycloak-based identity provider for authentication. This migration enhances security and provides a unified authentication experience across our services.

## Update on Security Policy

We have finalized an update to the [Eclipse Foundation Security Policy](https://www.eclipse.org/security/policy/), which has been approved by the Eclipse Foundation Architecture Council. This update can now be presented to the board for validation. The [changes](https://gitlab.eclipse.org/eclipsefdn/emo-team/policies/security-policy/-/commit/25f816a4809e1043256bacf9fff15e294b7eb43f) primarily revolve around the introduction of Project Security Teams—a concept introduced earlier this summer.

Project Security Teams are dedicated groups within each project responsible for handling security vulnerabilities and coordinating responses. Their introduction aims to improve our overall security posture by ensuring that security issues are addressed promptly and effectively at the project level.

## Communication

We have published a FAQ document in the [form of a blog post](https://blogs.eclipse.org/post/marta-rybczynska/project-security-teams-faq) regarding the Project Security Teams. This resource aims to provide clarity and answer common questions about the new security initiative.

Additionally, we held a [webinar](https://www.youtube.com/watch?v=7Z3WQJMQGIo) explaining the rules that a CNA, like the Eclipse Foundation, must follow. This was prompted by the fact that, as of August 2024, a [new set of rules](https://www.cve.org/Resources/Roles/Cnas/CNA_Rules_v4.0.pdf) for CNAs has come into effect. The webinar aimed to inform our community about these changes and how they impact our vulnerability reporting processes.

Finally, we Presented Eclipse OtterDog at the [Open Source Summit in Vienna](https://osseu2024.sched.com/event/1ej3f/policing-open-source-projects-at-scale-thomas-neidhart-eclipse-foundation).

## Vulnerability Management

The NIST's NVD has conducted an [audit](https://nvd.nist.gov/vuln/cvmap/report/16610) of the Eclipse Foundation's CVE submissions. The audit assessed the number of matching CWEs between what we reported and what NIST considered to be the correct CWEs.

Our acceptance level has risen to Contributor status, meaning that over 70% of the reported CWEs were deemed accurate over the past five years. This is a significant improvement and reflects our ongoing commitment to accurate vulnerability reporting. The report also shows a steady increase in accuracy since the beginning of the Alpha-Omega sponsorship.

## Public Policy

The following organizations have completed the necessary paperwork to join the [Open Regulatory Compliance Working Group](https://orcwg.org) over the past month:

- Siemens AG
- Lunatech B.V.
- Open Source Initiative
- Mercedes-Benz Tech Innovation GmbH
- Software Heritage

The Open Regulatory Compliance Working Group aims to help organizations navigate regulatory requirements related to open source software. By joining, these organizations are contributing to the development of tools and best practices for regulatory compliance in open source projects.
Loading