Announcement: Vulnerability reports no longer accepted by email

[iliescuioana]

We're writing to announce an update to how the Eclipse Foundation Security Team receives and handles vulnerability reports addressed to projects. Effective today, the team will no longer accept vulnerability reports submitted by email. The sections below describe the current process, what’s changing, and any actions you may need to take.

How vulnerability reporting works today
Until now, security researchers could report findings in three ways: through a project's GitHub Private Vulnerability Reporting (for projects who have it enabled), our vulnerability-reports GitLab issue tracker, or by emailing us directly.

What's changing
As of today, we will no longer accept vulnerability reports by email. Any report sent to our security email address on or after that date will not be processed. An auto responder will be created to warn vulnerability reporters about that change. The address itself remains open for all other correspondence.

Going forward, security researchers should report findings either through a project's GitHub Private Vulnerability Reporting or through our dedicated issue tracker: https://gitlab.eclipse.org/security/vulnerability-reports/-/work_items/new

Using the issue tracker requires an Eclipse account, which can be created here: https://accounts.eclipse.org/user/register/

We're also working to support anonymous reporting and will share more once it's available.

Actions needed
Because the reporting channels have changed, your project's SECURITY.md may now point to options that are no longer valid. We've prepared an updated template reflecting these changes, which can be found here: https://github.com/eclipse-csi/security-handbook/blob/main/templates/SECURITY.md

We kindly ask each project to update its SECURITY.md to list only supported channels.

Why we're making these changes
We've seen a significant increase in the volume of vulnerability reports, including a growing share of automated, AI-generated submissions. Concentrating intake on a single channel lets us triage genuine reports more reliably, improve response times, and ensure legitimate security issues receive the attention they require.

Other questions
For any non-vulnerability inquiry, you can still reach us at our usual address (security@eclipse-foundation.org).

This message has also been sent to the eclipse.org-committers mailing list https://www.eclipse.org/lists/eclipse.org-committers/msg01582.html

[merks]

I think it would be great if we could point our SECURITY.md to central common location for that rather than copy a template, which might possibly change again in the future.

Personally I will defer updating any of my projects until there is a central point of reference where we can direct the users.

---

For what it's worth, I'm glad reporters will be creating an issue directly. I personally question the needed for anonymity. We do all of our project work in a glass house, and normally project issues are reported via our public issue trackers, so why should security reports be special? I understand the need for keeping a security issue under wraps while mitigation steps are taken, but I just don't understand the compelling need for a reporter to be anonymous.

[mbarbero]

Thank you, Ed, for your request. I've created an issue (https://gitlab.eclipse.org/eclipsefdn/software-dev/websites/eclipse.org/-/work_items/1104) against the eclipse.org website to publish a baseline SECURITY.md file that projects can directly reference. Once the baseline is available, we'll update the template/stub with the baseline reference by default and provide recommendations on what specific SECURITY.md files for projects should contain, such as supported versions.