Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [eclipse.org-architecture-council] Request for advice: should the EF Security Policy require coordinated vulnerability disclosure?
Two things reading the replies. First, my message seems to have landed as a proposal in the making. It isn't: there is no draft text and no planned change. I noticed a gap while reviewing the policy and wanted the TAC's view before deciding whether it even deserves attention. "Leave it to projects" is a perfectly acceptable answer.

Second, and more important, I think we're not talking about the same thing when we say CVD. The reference I have in mind is the OpenSSF maintainer guide [1], which our own security handbook [2] and training also point to.

CVD is not an embargo on everything. In particular it does not mean:
- hiding the fix. The EF Security Team does encourage projects to develop fixes in private when they can, because it closes the window a bit further, and the handbook [2] describes how. But that is encouragement for tighter security, not a requirement, and it is not what this question is about. Plenty of CVD-practising projects develop the fix on a public branch, open a PR, merge it, and simply don’t label the commit as a security fix. Ed, your datatools PR fits that pattern; “a fix that doesn’t say it’s a fix” is standard practice, not obscurity.
- a separate build, a private fork, or an embargoed test bed. Nothing I'm asking about requires infrastructure beyond what GitHub and GitLab already provide for private reports.
- delaying the fix. Shelley, to your first question: a project can fix as fast as it wants and publish as soon as the fix is out. Nothing here slows that down.

What CVD does mean is narrow: the incoming *report* (description, reproduction steps, affected versions) is not published before the project has looked at it and before a fix or mitigation exists. In practice: reports land in a private place, get triaged there, then the project fixes and releases as usual, and the advisory goes out with the release. The glass house stays a glass house, except for the window between "report received" and "fix available".

The policy today lets a project skip that window entirely and publish every report on arrival, including a valid, severe, unverified one. That's the only question: should the policy say something about that window, or not?

On the "everything is discoverable anyway" point, which Jesse raised in August [3] and Shelley picks up here: I think it narrows the question rather than removes it. If an AI can read a one-line PR and produce an exploit outline, protecting the fix buys little, and that's part of why I'm not asking about the fix. But it also means publishing the report on arrival, with reproduction steps and affected versions, is worse than a merged commit: it removes even the step of asking. The August discussion (Martin's compromise of open development with security fixes handled privately before merge, Wayne's note that the policy tolerates private mitigation within a reasonable time frame) was about what happens after a report is validated. This thread is about the step before: whether a project may publish a report before anyone has looked at it. And in August I argued for faster release cadences; I still do. The two are compatible: fast releases shorten the window, private triage covers whatever window is left.

Ed, good idea on the GitLab issue; I've opened https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/work_items/8042.

[1] https://github.com/ossf/oss-vulnerability-guide/blob/main/maintainer-guide.md (short version: https://github.com/ossf/oss-vulnerability-guide/blob/main/runbook.md)
[2] https://eclipse-csi.github.io/security-handbook/vulnerabilities/embargoes.html
[3] https://gitlab.eclipse.org/groups/eclipsefdn-ac/-/wikis/Meetings/Meeting_Notes#august-2026

Mikaël Barbero 
Head of Security | Eclipse Foundation
Eclipse Foundation: The Community for Open Collaboration and Innovation



On 4 Nov 2026 at 15:01:28, Shelley Lambert via eclipse.org-architecture-council <eclipse.org-architecture-council@xxxxxxxxxxx> wrote:
That is why I asked 'can projects expedite a fix without publicly stating it relates to a CVE?' and I know a fix can be reverse engineered and expose that it patches a security issue, but also, a patch is fixing a vulnerability in the public code as it stands, that people can also find for themselves instead of reverse engineering a patch, so... waiting on coordinated response in the age of AI may be an arcane notion...

On Wed, Nov 4, 2026 at 8:44 AM Ed Merks via eclipse.org-architecture-council <eclipse.org-architecture-council@xxxxxxxxxxx> wrote:

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?

https://github.com/eclipse-datatools/datatools/pull/36/changes#diff-f0b8675ecb080f533bac246299ed523eb0071e4e2a8e23ef6c308c779668d0fb

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

--
jesse mcconnell
jesse.mcconnell@xxxxxxxxx


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 Barbero 
Head of Security | Eclipse Foundation
Eclipse 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
_______________________________________________
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

Back to the top