generated from ossf/project-template
-
Notifications
You must be signed in to change notification settings - Fork 51
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Merge pull request #418 from mbarbero/main
Add Eclipse Foundation July/August update
- Loading branch information
Showing
2 changed files
with
100 additions
and
0 deletions.
There are no files selected for viewing
54 changes: 54 additions & 0 deletions
54
alpha/engagements/2024/Eclipse Foundation/update-2024-07.md
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,54 @@ | ||
| # Eclipse Foundation Update — July 2024 | ||
|
|
||
| ## Security Hanbook for Eclipse Committers | ||
|
|
||
| We have started publishing a [Security Handbook for Eclipse Foundation Committers](https://eclipse-csi.github.io/security-handbook). The Eclipse Security Handbook provides best practices for securing development workflows within Eclipse Foundation projects. It covers topics such as securing developer accounts, machines, and environments. Additionally, the handbook includes guidelines for vulnerability management, including handling embargoes and issuing security advisories. The document also provides references to tools and other best practices to help maintain secure software development processes. | ||
|
|
||
| ## Management of GitHub Organizations and Repositories | ||
|
|
||
| All remaining GitHub organizations owned by the Eclipse Foundation are now incorporating Eclipse OtterDog. There are 172 GitHub organization managed by OtterDog, an increase of 65 since the end of June. OtterDog now manages the configuration of 1,764 repositories. | ||
|
|
||
| This month's updates include: | ||
|
|
||
| * Added support for configuring default code scanning setup of a repository. | ||
| * Added operation open-pr to automatically create a PR for local changes. | ||
| * Deprecated organization settings `dependabot_alerts_enabled_for_new_repositories`, | ||
| `dependabot_security_updates_enabled_for_new_repositories` and `dependency_graph_enabled_for_new_repositories`. | ||
| * Deprecated organization setting `has_repository_projects`. | ||
| * Fixed updating the configuration of a project when its base template changed. | ||
| * Fixed updating configuration when the `github_id` of a project changed | ||
|
|
||
| ## Public Policy | ||
|
|
||
| The [Open Regulatory Compliance Working Group](https://orcwg.org) has launched a new website along with a set of associated [repositories](https://gitlab.eclipse.org/eclipse-wg/open-regulatory-compliance-wg), which include early documentation, notably a [Markdown version](https://gitlab.eclipse.org/eclipse-wg/open-regulatory-compliance-wg/cra-topics/-/blob/main/cra.md?ref_type=heads) of the CRA text with anchors for easy linking. The organizations listed below have completed the necessary paperwork over the past month:: | ||
|
|
||
| * Open Elements GmbH | ||
| * Stichting NLnet Labs | ||
| * The Matrix.org Foundation | ||
| * OWASP | ||
| * SCANOSS | ||
| * The Document Foundation | ||
|
|
||
| Three webinars have been organized to demystify the CRA topics: | ||
|
|
||
| * [How to read the CRA: Identifying the key parts of the CRA for effective compliance](https://gitlab.eclipse.org/eclipse-wg/open-regulatory-compliance-wg/cra-topics/-/blob/main/webinars/README.md#session-1---how-to-read-the-cra-identifying-the-key-parts-of-the-cra-for-effective-compliance), Enzo Ribagnac, Associate Director for European Policy, Eclipse Foundation | ||
| * [The CRA Obligations: Identifying the Relevant Obligations for the OSS Community](https://gitlab.eclipse.org/eclipse-wg/open-regulatory-compliance-wg/cra-topics/-/blob/main/webinars/README.md#session-2---the-cra-obligation-identifying-the-relevant-obligations-for-the-oss-community), Benjamin Boegel, Head of Sector for Product Security and Certification Policy at the European Commission | ||
| * [CRA Standards making: Understanding key standards and their production timeline](https://gitlab.eclipse.org/eclipse-wg/open-regulatory-compliance-wg/cra-topics/-/blob/main/webinars/README.md#session-3---cra-standards-making-understanding-key-standards-and-their-production-timeline), Filipe Jones Mourão, Policy Officer, DG CNECT, European Commission | ||
|
|
||
| ## Infrastucture Security | ||
|
|
||
| Over the past few weeks, we encountered an issue with our code signing service (both JAR signing and Authenticode). The mandatory switch to a Hardware Security Module (HSM) for certificate storage has significantly impacted our performance and scalability. | ||
|
|
||
| In response, we explored various "as-a-service" solutions, aiming to turn this challenge into an opportunity to eliminate our in-house, self-hosted setup and free up some resources. Unfortunately, the market solutions we evaluated do not scale to our requirements, especially in terms of pricing. | ||
|
|
||
| At the same time, we investigated using Cloud HSM, which seemed to be a promising solution. We deployed a [new version](https://github.com/eclipse-cbi/org.eclipse.cbi/releases/tag/v1.5.0) of the signing service that leverages Google KMS as a backend. This approach is far more scalable and has restored build times to normal. We also took this opportunity to [adopt](https://github.com/eclipse-cbi/org.eclipse.cbi/pull/502) the Java-native [JSign](https://ebourg.github.io/jsign/) library for JAR signing and Windows Authenticode, rather than relying on subprocesses. | ||
|
|
||
| ## Communication | ||
|
|
||
| We discussed the recent changes in Code Signing and GitHub Configuration Self-Service during July's [committer office hours](https://www.eclipse.org/projects/calendar/#2024-07-11). | ||
|
|
||
| We published a [blog post](https://blogs.eclipse.org/post/marta-rybczynska/update-vulnerability-description-cvss-40) discussing the new `4.0` version of [CVSS](https://www.first.org/cvss/v4.0/specification-document). The blog post explains the differences introduced in the CVSS 4.0 scoring system compared to CVSS 3.1. The post also highlights how these changes affect vulnerability scoring for Eclipse Foundation projects and encourages using new fields like "Urgency" for a more nuanced assessment. | ||
|
|
||
| ## Hiring | ||
|
|
||
| We have completed our search for a new Security Software Engineer to join the team. The new member will begin mid-September. |
46 changes: 46 additions & 0 deletions
46
alpha/engagements/2024/Eclipse Foundation/update-2024-08.md
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,46 @@ | ||
| # Eclipse Foundation Update — August 2024 | ||
|
|
||
| ## Private Vulnerability Reporting at GitHub | ||
|
|
||
| Eclipse Foundation projects can now request access to [GitHub's Private Vulnerability Reporting feature](https://docs.github.com/en/code-security/security-advisories/guidance-on-reporting-and-writing-information-about-vulnerabilities/privately-reporting-a-security-vulnerability). 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](https://gitlab.eclipse.org/security/cve-assignement/-/issues/new?issuable_template=cve). | ||
|
|
||
| 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. | ||
|
|
||
| ## Per-Project Security Team | ||
|
|
||
| After discussions between the Eclipse Foundation Security Team and the Architecture Council, we have [announced](https://github.com/orgs/eclipse-csi/discussions/4) 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](https://docs.github.com/en/organizations/managing-peoples-access-to-your-organization-with-roles/managing-security-managers-in-your-organization). 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](https://www.eclipse.org/projects/handbook/#projects-security-team) with detailed documentation outlining the specific permissions granted to members of Project Security Teams. | ||
|
|
||
| ## Public Policy | ||
|
|
||
| The organizations listed below have completed the necessary paperwork to join The [Open Regulatory Compliance Working Group](https://orcwg.org) over the past month: | ||
|
|
||
| * Obeo | ||
|
|
||
| ## Infrastucture Security | ||
|
|
||
| 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. | ||
|
|
||
| ## Communication | ||
|
|
||
| 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](https://blogs.eclipse.org/post/marta-rybczynska/using-github-private-vulnerability-reporting-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](https://blogs.eclipse.org/post/marta-rybczynska/reviewing-cve-process-and-cna-rules-40) | ||
| *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](https://blogs.eclipse.org/post/marta-rybczynska/do-not-use-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.* |