## Context The [Eclipse Foundation Security Policy](https://www.eclipse.org/security/policy/) currently does not require projects to practice coordinated vulnerability disclosure. A project may publish every incoming vulnerability report on arrival, before it has been validated, regardless of severity, and before any fix or mitigation exists, while remaining fully compliant with the policy. This issue captures the discussion started on the ETAC mailing list on 2026-11-04 ([thread](https://www.eclipse.org/lists/eclipse.org-architecture-council/msg04957.html)) for further discussion. It is a request for advice, not a proposal: no policy text is drafted, and "leave it to projects" is an acceptable outcome. ## The question Should the policy say anything about the window between "report received" and "fix or mitigation available"? Specifically: should projects be required to handle valid reports privately during that window, at least above some severity threshold, or should they keep the freedom to handle all reports in public? If the answer is yes, follow-up questions (not for this issue to settle) are what should trigger the requirement (validity, severity, exploitability) and what a minimum acceptable process looks like for small projects. ## Scope clarification Part of the thread showed that "CVD" was being read as an embargo on everything, including the fix. That is not what this question is about. For the purposes of this discussion: - **In scope:** whether the *report* (description, reproduction steps, affected versions) may be published before triage and before a fix or mitigation exists. - **Out of scope**: how the *fix* is developed. The EF Security Team encourages projects to develop fixes in private when possible, as described in the EF Security Handbook, because it further narrows the exposure window. This is encouragement for tighter security, not enforcement, and this issue does not propose changing that. Fixing on a public branch, opening and merging a PR, and not labelling a commit as a security fix are all compatible with CVD. No separate build, private fork, or embargoed test bed is implied. - **Out of scope:** the speed of fixes. Nothing here delays a fix or a release. The handling of the fix was discussed at the [August 27 ETAC meeting](https://gitlab.eclipse.org/groups/eclipsefdn-ac/-/wikis/Meetings/Meeting_Notes), including Martin's suggestion of open development with security fixes handled privately before merge, and Wayne's note that the policy already tolerates private mitigation within a reasonable time frame. That remains a separate topic. References: [OpenSSF maintainer guide to CVD](https://github.com/ossf/oss-vulnerability-guide/blob/main/maintainer-guide.md), [EF Security Handbook on embargoes](https://eclipse-csi.github.io/security-handbook/vulnerabilities/embargoes.html). ## Trade-offs as initially framed **For keeping the freedom to handle all reports in public** - Transparency: some projects treat full openness as a core value. - Low overhead: no private channel, embargo coordination or security team needed. - Community involvement: public reports can attract fixes and reviews from more contributors. - Project autonomy: the policy has so far left process choices to projects. **Against** - User risk: a confirmed, severe vulnerability published before a fix leaves adopters exposed. - Reporter expectations: many researchers expect a private channel and an embargo period; immediate publication may conflict with their practices. - Downstream and regulatory expectations: adopters, distributors and regulators increasingly expect CVD; project-level opt-out may be hard to defend. - Inconsistency: no common baseline across Foundation projects. - Reputational risk to the Foundation and to other projects. ## Points raised on the thread - **Badge instead of mandate** (Eike): let projects signal compliance with a CVD process rather than forcing one approach. Counter-point (Shelley): a badge fits poorly with projects that decide case by case. - **CRA as the guiding hand** (Jesse): requirements on projects should flow from what the Foundation is compelled or chooses to do under the CRA and similar regulation, rather than be invented on top. - **Practical questions** (Shelley): does CVD delay fixes reaching public repos; can a project fix without tying the fix to a disclosure; who decides on embargo and time frame; what infrastructure is needed and who pays for it. - **Committer load** (Shelley): projects already report being flooded with large AI-generated vulnerability reports. Adding process without adding support risks burnout. Any requirement to triage privately would need to come with help on triage. - **"Everything is discoverable anyway"** (Jesse in August, Shelley here): AI makes reverse-engineering a fix trivial, so coordinated response may buy little. Counter-point: that argues against protecting the fix, not against protecting the report; a published report with reproduction steps removes even the step of asking. - **What does "handle in public" mean concretely** (Ed): a public PR with an unlabelled security fix should not count as "handling in public" under this question. Ed also asked where the handling boundary sits in practice, which the scope clarification above tries to answer. - **Faster release cadences** (Mikaël, August): shorten the exposure window; compatible with private triage, which covers whatever window remains. Jesse noted that accelerating releases is hard for projects with heavy integration testing, e.g. Jetty.