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,
