Eclipse Foundation Baseline Security Policy | The Eclipse Foundation

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.
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.
A clear, reproducible report lets us triage and fix issues faster. Please include as much of the following as you can:
Eclipse Foundation projects practice coordinated disclosure. After you report an issue:
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.
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.
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.
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.
Eclipse Foundation projects are encouraged to keep a short SECURITY.md in their own repository that:
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).
See what we're up to
Copyright © Eclipse Foundation AISBL. All rights reserved.