| Re: [eclipse.org-architecture-council] Request for advice: should the EF Security Policy require coordinated vulnerability disclosure? |
_______________________________________________I think it would be really awesome if there were a GitLab issue in which the detailed content from this email would be captured. That would be a great place where associated comments, questions, and answers could be recorded, all in one place, for future reference.
Silly, ignorant me had to Google "coordinated vulnerability disclosure"; okay, found some answers. That makes me wonder about what it means to "handle a report in public"? Specifically, when I created the following PR, I wonder if that is an example of handling the associated CVE in public?
https://github.com/eclipse-datatools/datatools/pull/36
Note that I didn't call out the following specific change as a CVE fix, but is that privacy through obscurity?
If the above is an example of handling a report in public, I do immediately wonder what specifically is being proposed as the alternative. I ask because my normal build process are driven from PRs on the repository and I'm significantly averse to tailoring additional/alternative build processes. And of course at some point the PR needs to be merged into the public repository...
All this is a long way of suggesting that I think it's super important to understand what is being proposed concretely for maintaining or ensuring privacy. Where is the handling boundary? After all, we live in a glass house and that has always been a virtue up until now...
On 11/4/2026 1:36 PM, Jesse McConnell via eclipse.org-architecture-council wrote:
I am a fan of sane security policy, but also of allowing projects the freedom to do things the way they want.
Having said that, at a high level, wouldn't the guiding hand for this largely be the CRA and its requirements, along with any other similar government policies? IMO, the best thing the EF can do is help projects adhere to the requirements that governments are setting for developers and open-source projects, in both letter and spirit. The EF is on the hook for reporting issues such as active exploits in project releases, so requirements should flow down to projects based on what the EF is either compelled to do or chooses to do on their behalf.
cheers,Jesse
On Wed, Nov 4, 2026 at 3:04 AM Eike Stepper via eclipse.org-architecture-council <eclipse.org-architecture-council@xxxxxxxxxxx> wrote:
_______________________________________________Hi Mikael, Colleagues,
With so many valid arguments for, as well as, against the proposal it could become hard to strictly force all projects into one or the other approach.
What about offering projects to carry a sepcial kind of badge on their project to indicate compliance with a process?
Cheers
Eike
Am 04.11.2026 um 09:47 schrieb Mikael Barbero via eclipse.org-architecture-council:
Dear TAC members,
I'd like your advice on a specific aspect of the Eclipse Foundation Security Policy.
As currently written, the policy does not require projects to practice coordinated vulnerability disclosure (CVD). A project may choose to make every incoming vulnerability report public from the outset, regardless of whether the finding has been validated or how severe it is. In practice, a reporter could submit a valid, high-severity issue and see it disclosed publicly before a fix is available, while the project remains fully compliant with the policy.
Should the Security Policy require projects to engage in CVD, at least for valid reports above a certain severity threshold? Or should projects retain the freedom to handle all reports in public?
To frame the discussion, here is how I see the trade-offs.
Arguments in favor of retaining this freedom:
- Transparency: some projects consider full openness a core value and see private handling of any issue as contrary to how they operate.
- Simplicity and low overhead: a public-by-default process requires no private channel, embargo coordination or separate security team.
- Faster community involvement: public reports can attract fixes and reviews from a wider pool of contributors.
- Project autonomy: the policy has so far left process choices to projects, consistent with the Foundation's general approach to project development process.
Arguments against retaining this freedom:
- Risk to users: making a confirmed, severe vulnerability public before a fix or mitigation is available leaves adopters exposed.
- Reporter expectations: many security researchers expect a private reporting channel and an embargo period. Immediate publication may discourage reporters or conflict with their disclosure practices and employer policies.
- Downstream and regulatory expectations: adopters, distributors and, increasingly, regulators expect open source producers to follow CVD practices. Allowing individual projects to opt out may be difficult to explain or defend.
- Inconsistency across the Foundation: reporters and users cannot rely on a common baseline for how Eclipse projects handle vulnerabilities, weakening the value of a Foundation-wide policy.
- Reputational risk: public disclosure of an unpatched, severe vulnerability by an Eclipse project reflects on the Foundation as a whole and every other projects, not only on the project.
If the TAC favors a requirement, the next questions would be what should trigger it (validity, severity or exploitability) and what a minimum acceptable CVD process would look like for small projects.
At this stage, I am asking for the TAC's view on whether the policy should mandate CVD and, if so, under what conditions, rather than for draft policy language. I suggest we already use this thread to discuss this matter and finalize TAC's opinion during the next meeting.
Cheers,
Mikaël BarberoHead of Security | Eclipse FoundationEclipse Foundation: The Community for Open Collaboration and Innovation
_______________________________________________ eclipse.org-architecture-council mailing list eclipse.org-architecture-council@xxxxxxxxxxx To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/eclipse.org-architecture-council
eclipse.org-architecture-council mailing list
eclipse.org-architecture-council@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/eclipse.org-architecture-council
_______________________________________________ eclipse.org-architecture-council mailing list eclipse.org-architecture-council@xxxxxxxxxxx To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/eclipse.org-architecture-council
eclipse.org-architecture-council mailing list
eclipse.org-architecture-council@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/eclipse.org-architecture-council