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,
