Clear Signals: Updating the CVE Reservation and Publication Process

As the Eclipse Foundation Security Team, we're always looking for ways to make our processes smoother and more robust for project teams. Today, we're announcing a change to how projects request CVE reservation and publication through our cve-assignment issue tracker on GitLab.

Traditionally, the CVE assignment process at the Eclipse Foundation works like this: after confirming a vulnerability, a project requests a CVE ID. The Security Team reserves and assigns the CVE confidentially, to be used for internal communication only. Later, when a fix is ready and released, the project asks the Security Team to publish the CVE record and lift the embargo.

What's changing?

Previously, a project would open a cve-assignment issue to request reservation of a CVE ID, and then later add a comment to that same issue to signal that  they were ready to publish.

While this worked, it relied on the Security Team noticing and correctly interpreting a comment as a publication request — a low-intensity signal that stood a chance to be missed or misread, especially as volume grows.

The new process introduces two dedicated issue templates:

Each request is now its own issue, created from its own template, providing a clear and unambiguous signal for each step in the process. You can find the full details in the updated security section of the Eclipse Foundation Project Handbook.

Questions?

If you have questions or suggestions about the updated process, don't hesitate to reach out to the Eclipse Foundation Security Team at security@eclipse-foundation.org or https://github.com/orgs/eclipse-csi/discussions. 

We believe this small change will make the CVE process more reliable for everyone involved. As always, we appreciate the collaboration of our project communities in keeping the Eclipse ecosystem secure.