Replying to fearzzzz:
- most likely, someone will try to abuse these forms and this isn't only spam [...] So basically the security researcher needs to be registered @ wordpress.org to access the form, right? Does it make sense to introduce a «punishment» system for obvious fake reports?
Yes, reporters would need to be registered.
I would like to think that a 'punishment' system shouldn't be required. If a reporter was to consistently make false reports then that would be within reason to have their account permanently banned or reporting permission limited.
- it would be nice not to make all the input fields of the form obligatory and give the ability to upload .txt or .md files. [...] Such forms are mostly convenient for companies, but not for researchers.
Per-field or as the entire submission? Is there any "standardised" .txt/.md format that some use?
- what to do with the situation when the vendor doesn't understand what security/vulnerability is and what is required of him, and is anything required at all? Quite a common case.
This is unfortunately something that the plugin security team has to deal with often.
Quite often suggested fixes are ignored and insecure fixes are made, which requires further changes from the author.
Educating plugin authors can only be done through better documentation of the problem, and examples of how to resolve it.
In the case of WordPress.org plugins, if a author is not willing to fix something that the plugins team deems a security issue, then they can close the plugin. If the author wants their plugin, they need to work with everyone to ensure it's secure.
(It's not uncommon for some plugins that are intentionally "insecure" to get security reports either - for example, an admin console that lets any user execute PHP, or a plugin that allows users to access any file on the server filesystem, a report against one of those would not warrant the plugin being closed, unless it was something like an authentication bypass)
There's the scenario where the plugin security team can step in and fix the plugin too, although in that case, it would only be to make an update for end-users, the author would not retain access if they were not willing to support the plugin.
- does the term «security vendor» apply only to companies or to independent researchers as well?
Bad choice of words on my part. I meant in terms of researcher. This should be open to anyone, whether they're an employed security researcher, an individual researcher, or a vehicle mechanic who understand code.
I'm going to go edit the ticket to read security reporter to be more inclusive.
- if the plugin author doesn't agree with the discovered vulnerability (which sometimes happens, and such a position is biased), then the researcher can simply «bypass» this communication routine by uploading a report to any vulnerability aggregator, which in the end will still force either the plugin author and/or the WordPress Plugins team to turn attention to this problem. At this point it makes sense to listen a little less to the opinion of the authors I believe. What do you think?
I touched on this in the above answer, but this is a case where the security researcher would escalate it to the plugins team to intervene, and would result in the plugin being closed. That would ideally happen before the disclosure is made by a vulnerability aggregator.
Currently the plugins team take action in response to public disclosures mostly as the team was not made aware of the issue before hand (there are some deliberate 0day'ers) or due to being a volunteer team, did not get to the email in time (There have been cases where we're alerted a few days before the disclosure timeout happens, and some where the notification was misunderstood).
- additional question: what should motivate independent researchers to use this form?
That's something you can help greatly with! And why I'm open to discussion on this, rather than saying "This is what needs to be built and this is what everyone gets".
I suggested in the ticket a profile entry for reporting security issues, but I intentionally didn't suggest a threshold to get a badge of some form, or a count of submitted reports, to partially remove the desire to submit many reports for extreme-low-effort issues for an 'awesome badge'.
Perhaps down the line we'd be able to look at a Security Researcher badge for those who submit enough valid reports against WordPress Core / Plugins / Themes / etc, with a percentage-accepted criteria, to encourage reporters to only submit things that are actually valid and tested.
Other platforms have a Leader Board system, that works for them, but I don't think it'd work for us.
This is something that we'd probably only be able to identify the best solution for once we had enough reports / data collected.
- maybe it makes sense to implement some kind of rating that displays the average response time to an incident of the plugin author? It would be great to somehow reward the plugin author for a quick response to an incident with profile badge for example and highlight this information.
Interesting idea! This is probably not something we could do for the first iteration, again, due to lack of data points. But rewarding plugin authors who do things right is definitely worthwhile.
It would be great to somehow «force» plugin authors to write a honest changelog and not ignore/silence any discovered and confirmed security issues. Right now this isn't only disrespectful to security researchers and regular users/clients, but also creates confusion that could have been avoided.
I do agree, and in a way that is partly the reason for this ticket. The plugins team are often not aware of plugins that have significantly severe vulnerabilities until public disclosure and it being talked about widely, simply as they're never made aware of it.
Currently the only documentation we have on responding to a security report is not very direct on what they should do in this regard. Updating that page to strongly encourage changelog entries and crediting the reporter should be done. If you have any suggestions for wording changes to make to that page, come along to #pluginreview in Slack with them and we'll get it sorted.
Something that we could do here however, is forcibly prefix the Upgrade Notice for a security fix with information of that regard, or ensure the changelog mentions Security for such plugins.
This is one of those situations where we currently have limited ability to control the messaging from plugin authors, while we can encourage them to be transparent, we still have to rely upon them wanting to work with us.
I think this is something we'd have to look at as a follow up, once we see how plugin authors actually respond to it. With some well documented steps they should follow (perhaps a checklist) many are likely to be more willing to.