Eclipse Foundation Baseline Security Policy

This is the baseline security policy for projects hosted by the Eclipse Foundation. It is a single, canonical reference that individual projects can point to from their own SECURITY.md so they do not have to restate the common process. Unless a project’s own SECURITY.md says otherwise, the terms below apply.

This document is the operational companion to the Eclipse Foundation Security Policy, which defines the governing principles for how vulnerabilities are reported, managed, discussed, and disclosed across the Foundation. Where this document and the Security Policy differ, the Security Policy governs.

Reporting a Vulnerability

Please do not report security vulnerabilities through public GitHub issues, GitLab issues, pull/merge requests, discussions, mailing lists, or chat. Public disclosure before a fix is available puts users at risk.

Report privately through any one of the following channels:

Send your report as plain text, and do not attach files. To protect the people performing triage, the Eclipse Foundation Security Team does not accept or open attachments of any kind. Put everything — including logs, stack traces, and proof-of-concept or exploit code — inline in the body of your report as plain text. If a vulnerability can only be demonstrated with a non-text artifact (for example, a crafted input file or a packet capture), describe it in your report and the Security Team will arrange a separate, vetted channel to receive it. Do not attach the artifact to, or link it from, your initial report.

What to include in a report

A clear, reproducible report lets us triage and fix issues faster. Please include as much of the following as you can:

  • The type of issue (for example: buffer overflow, SQL injection, cross-site scripting, insecure deserialization, authentication bypass).
  • The name of the affected project, component, and the affected version(s).
  • The impact of the issue, including how an attacker might exploit it.
  • Step-by-step instructions to reproduce the issue.
  • The location of the affected source code (tag, branch, commit, or a direct URL) and the full path of the relevant source file(s).
  • Any special configuration required to reproduce the issue.
  • Relevant log output, pasted inline (redact any secrets or personal data).
  • Proof-of-concept or exploit code, inline as text, if you have it.

Our Process and What to Expect

Eclipse Foundation projects practice coordinated disclosure. After you report an issue:

  1. Triage and routing. The Eclipse Foundation Security Team is the first point of contact. They acknowledge the report, perform an initial triage, and route it to the relevant project’s security team. The Security Team does not fix vulnerabilities itself; issues are resolved by the project’s committers with guidance from the Security Team.
  2. Assessment. The project’s security team confirms the issue, determines severity and affected versions, and works with you on any clarifications. If there is a disagreement about whether an issue is a vulnerability, the Eclipse Foundation Security Team provides the final classification.
  3. Resolution. A fix or a documented workaround is prepared. In line with the Eclipse Foundation Security Policy, projects are expected to resolve a vulnerability within no more than three months (90 days); this period may be extended by the project leadership together with the Eclipse Foundation Security Team when appropriate.
  4. Release and disclosure. The fix is shipped through the project’s normal distribution channels. Public disclosure is strongly recommended as soon as a release containing the fix is available. A CVE may be assigned — the Eclipse Foundation is a CVE Numbering Authority (CNA) — and an advisory may be published. Disclosed vulnerabilities for Eclipse software are listed on the Eclipse Known Vulnerabilities page.

As a reporter, we ask that you give the project reasonable time to investigate and release a fix before any public disclosure. Our default expectation aligns with the 90-day resolution target above. If an issue is being actively exploited, or has already been made public, please tell us so we can respond on an accelerated timeline.

Scope

This baseline applies to vulnerabilities in the source code and released artifacts of Eclipse Foundation projects.

Vulnerabilities in Eclipse Foundation infrastructure and websites (for example eclipse.org, accounts, CI/CD systems, or other shared services) should also be reported to the Eclipse Foundation Security Team using the channels above; these are handled by the Foundation rather than by an individual project.

Individual projects may define additional in-scope and out-of-scope items in their own SECURITY.md.

Supported Versions

The set of versions that receive security fixes is project-specific. Each project states its supported versions in its own SECURITY.md and/or release documentation. If you are unsure whether a version is still supported, ask through one of the reporting channels above before assuming it is not.

Recognition

With your consent, projects are encouraged to credit reporters in security advisories and release notes. Let us know in your report how you would like to be acknowledged, or if you would prefer to remain anonymous.

How Projects Use This Document

Eclipse Foundation projects are encouraged to keep a short SECURITY.md in their own repository that:

  1. references this baseline as the document to read first; and
  2. adds only what is specific to that project — its supported versions, any additional reporting contact, and any project-specific scope notes.

Anything stated in a project’s own SECURITY.md extends or, where explicitly noted, overrides this baseline for that project — except that the Eclipse Foundation Security Policy always governs, and projects must always offer at least one confidential reporting channel.

Baseline version 1.0. Maintained by the Eclipse Foundation Security Team and the Eclipse Common Security Infrastructure (CSI) project. Operational companion to the Eclipse Foundation Security Policy, version 1.2 (2024-11-20).