Revise vulnerability reporting practices
Our current general practice is to have vulnerability reporters either open an issue against the Community/Vulnerability Reports component in Bugzilla or send a note to the security mailing list. Some projects provide other options.
The primary value of using Bugzilla is the ability to mark issues as confidential ("committers-only"), thereby giving a project team the opportunity to mitigate the issue before disclosing it responsibly. This practice started back when all projects used Bugzilla and so make some sense. Many projects have moved off of Bugzilla, so shunting requests there is just weird makes it yet-another-thing-to-think-have-to-think-about.
GitHub has no means to mark standard issues as confidential. Further investigation of options available to projects using GitHub Issues needs to be explored.
GitLab does have a means of marking issues as confidential. Using this feature should be pretty natural for projects operating on our GitLab instance.
We have a few challenges with the security mailing list. For one, it's configured so that one does not have to actually subscribe to send to it. This is by design: if we let just anybody subscribe, then it's not a particularly good vehicle for reporting or discussing security issues. Since subscription is not required, it's a spam target (over the past five days, it's received around 100 spam messages). The bigger challenge is that we need to decide what to do with the legitimate messages that we do receive. Typically, we (usually Wayne) creates a Bugzilla record with the project leads of the affected project in copy. One of the challenges with the Bugzilla record is that in order to add the reporting in copy, they need to have an Eclipse Foundation account and have used that account to log into Bugzilla at least once before we can add them. This makes it a bit of a time consuming dance to connect the various parties together.
Whatever means that projects use to track vulnerabilities, the security policy (and good community practices) requires that we disclose after three months. To help our projects make this work, we need some way of making disclosure automatic (that is, we need for the confidential flag to be automatically dropped after three months). Currently, this is done manually; that is, the EMO (ie., Wayne) periodically reviews designated vulnerability bugs in Bugzilla and removes the "committers-only" flag when the three month period has passed. This is not currently done consistently (which leaves us in violation of our policy).
If we end up not using Bugzilla to track some or all vulnerabilities, we'll need some other means so that the EMO/Security Team has the ability to publicly disclose and otherwise follow up.
So the TL;DR: is that we don't currently have a good consistent means of reporting vulnerabilities, connecting vulnerability reporters with project teams, and ensuring at least some form of follow through.
My current thinking is that we create a security mailing for each project. The list should have no archive. All project committers and leads are automatically subscribed (or maybe come up with a means for projects to designate a "security contact"). Simply opening this list to the world would make it another spam target. So instead, we create a web form. To use the web form, a responsible reporter would need to have an Eclipse Foundation account (and, perhaps have signed the ECA but we need to be careful about making the bar too high). The web form would then send an email to the appropriate project's security list. The security policy for the individual project would provide a pointer to the web form.
The web form could additionally log the receipt of the report in a database so that the security team and EMO can follow up as necessary to ensure that responsible disclosure occurs (and potentially make an independent decision to escalate by issuing a CVE).
There's some challenges with this. For starters, we'd need some strategy for forwarding reports sent to the wrong project.
/cc @cguindon /cc @mbarbero /cc @mdelgado624